‘Megaroids’ – My All-Time Favorite ‘Asteroids’ Clone

In my opinion, Asteroids is one of the very best videogames of all time. I guess that’s probably obvious. Lately I’ve been playing a related series of Asteroids-inspired games that are old enough to be considered retro, themselves. They were pretty popular back in the day, and you’ll hear about that in a post, here, soon enough. But my favorite Asteroids remake of all time is a game far fewer will have heard of. It’s a game I spent a lot of time with this past Christmas, as well as during the Christmas of 1986, 25 years ago.

That game is Megaroids, by Mike Bunnell, with audio by his brother Mitch.

Megaroids was released in 1984 for the Macintosh by Mike Bunnell, then of Megamax. It was bundled with the Megamax C compiler, as an example of what the system could do. (The source code was available for a small fee.) When the compiler was released for the Atari ST in 1985, Megaroids was ported and bundled with it, as well. And, for a while, Atari included the game as a pack-in title with the early Atari ST systems, which is how I first came to know it.

I’ve played the Mac version a few times — I’ve got it on my Mac Plus right now. But it was the Atari ST version I fell in love with. The game was unusual in that, on color ST systems, it was rendered in the “Medium Res” mode, at 640×200 pixels in four colors. But, interestingly, the developer employed some manner of frame swapping that sought to increase the apparent resolution by rapid color switching, while introducing some flicker. It made the game look pretty outstanding on a color Atari ST. The 640×400 “High Res” monochrome mode was also supported on the ST, for those with an SM-124 display.

A few months back I captured some video of the game running under an emulator on my Windows 7 box (though I prefer playing it on the real thing). Have a look.

Knowing I’m close to posting my other Asteroids-related story, I wanted to go ahead and share this one, to prime the pump, so to speak. Shortly after capturing the above video, I located Mike Bunnell, who’s presently CEO of Fantasy Lab, and shared the piece with him. He seemed pleased for the stroll down memory lane.

UPDATE (7/2011): In my email back-and-forth with author Mike Bunnell, he spoke to the effect he used in the ST’s medium res mode to increase the apparent screen resolution. Most interesting.

“BTW I see you mentioned my technique for increasing the apparent resolution of the medium res mode on the atari st. I made use of the fact that the monitor really had 400 lines of resolution, but the scanning was interlaced (like a tv), first displaying the even lines of a frame and then the odd lines. In 640×200 mode the Atari scans from the same frame buffer location for the even and odd lines, effectively halving the top resolution of the monitor in order to provide a better looking (non-blinking) GUI. Megaroids made use of the full resolution of the monitor by rendering a different image for the even lines and the odd lines.”

UPDATE (08/2011): I’ve been playing with DOSBox on the PC, looking for EGA games and ran across EGA-roids, a ‘286 EGA conversion of Megaroids! See the game in action.

UPDATE (10/2015): I’ve been making custom watch face images for my 42mm Apple Watch running watchOS 2.0 and one of the faces I made is a tribute to Megaroids. Whaddaya think?

megaroids_apple_watch

This entry was posted in Atari, Macintosh. Bookmark the permalink.

16 Responses to ‘Megaroids’ – My All-Time Favorite ‘Asteroids’ Clone

  1. Blake Patterson says:

    Hm, I just discovered there’s apparently an Amiga Asteroids-like game called Megaroids. It does not look nearly as fine. I believe it is unrelated.

    https://www.youtube.com/watch?v=rbf2-hdP-HU

  2. ThorN says:

    Second you. Megaroids is one of the gratest Asteroids clones ever. Bought the PD Disk at the local Atari Dealer back in 87 or 88. Had so much fun with the game. The graphics were really nice, cause you was used to 320×200 at that time, so double the size in the horizontal was new. Interesting to know that it was a conversion from the Mac.
    Reply

  3. gnome says:

    It’s the black and white Mac graphics that always do it for me. Such elegant beauty…

  4. wood_jl says:

    Indeed, in the early days of the ST, when you were a kid who spent your last dime to get the system, this game was one of “the greats” because it was definitely commercial quality, and you didn’t have any money left to buy games anyway. As a matter of fact, there weren’t many games in those earliest ST days, and even if you DID have money, you could hardly find a fun, quality title that would best Megaroids.

  5. Blake Patterson says:

    I sent Megaroids author Mike Bunnell the link to this write-up, to which he sent the following reply. I don’t think he’d mind my sharing it, and it may be interesting to those who enjoyed this post.

    “BTW I see you mentioned my technique for increasing the apparent resolution of the medium res mode on the atari st. I made use of the fact that the monitor really had 400 lines of resolution, but the scanning was interlaced (like a tv), first displaying the even lines of a frame and then the odd lines. In 640×200 mode the Atari scans from the same frame buffer location for the even and odd lines, effectively halving the top resolution of the monitor in order to provide a better looking (non-blinking) GUI. Megaroids made use of the full resolution of the monitor by rendering a different image for the even lines and the odd lines.”

  6. I agree that this is one of the better clones. It was free and ran on the ST, regardless of the monitor.
    In the 1992 timeframe when I was young, I only had the monochrome SM124 monitor and Megaroids was one of the great PD titles for that one.

    I still enjoy playing this at times :)

    Thanks for remembering!

    Like Thorn I was not aware of the Macintosh version before.

  7. 8bitjeff says:

    You are right, Megaroids was certainly one of my favorite Asteroids versions of all time. It was perfectly crafted and the I remember the ST keyboard being a very good one to play this game. Plus, you could re-configure the keys to make the 4-button style mode of the Arcade game rather than using the arrow keys as is common with Flash versions today. I also remember playing an EGA version in DOS in the 90’s but it just was not nearly as good as the ST version.

    • Blake Patterson says:

      Indeed, the EGA version is distorted because it renders on the 640×350 resolution EGA screen using the same bitmaps from the game that was written to target 640×400 screen res.

  8. Andrew Hunn says:

    If I recall correctly, the Atari version has a larger playing area and consequently a more reasonable (more fun) difficulty level.

  9. Blake Patterson says:

    Andrew: The Mac original was designed for the Mac’s 512×342 display, while the Atari ST version runs at either 640×200 or 640×400, depending on the screen mode used.

  10. Jay says:

    EGA-Roids. Wow, have been looking for that title forever.

    I played EGA-Roids a LOT in my younger days.

  11. Pingback: The Year that ‘Starglider’ and the Atari ST Saved Halloween | Byte Cellar

  12. Pingback: Four Colors Into Sixteen: Terminal Innovation on the Atari ST | Byte Cellar

  13. MarkP says:

    Hmm, I played a lot of Megaroids back on the ST… and I don’t really recall it flickering particularly. But the youtube video definitely has interlace-type flicker…

    At the same time, as far as I know, the ST can’t do interlace, certainly not the early models anyway; that’s something pretty much limited to the Amiga, amongst all mid-80s computers. The video chip simply doesn’t create, or have the ability to create, a full-*frame* interlaced picture, but like all other old 15khz-monitor machines (including the Amiga in its normal modes) simply repeatedly scans the same half-resolution *field* to reduce flicker at the expense of vertical resolution (and, at least with NTSC/60Hz modes, the characteristic “scanlined” effect). Creating interlace demands the ability to trigger vsync halfway through the last line of every other field, but the ST’s hardware only ever produces whole lines. And it’s not just a case of doubling up the 200 lines to 400 interlaced ones because the image would appear to dance up and down by a “half” (logical, one physical) line height at a rate of 25 or 30 times per second instead of making 50 or 60 steady scans.

    So I wonder where the truth lies? Does it in fact interlace or not? Maybe some very early ST models did indeed produce an interlaced display, but with doubled lines in order to give it a steadier appearance with Atari still toying with the idea of maybe having a high-rez interlaced mode (either 640×400 monochrome or 320×400 4-colour, which is all its 32kb screen memory – sized to be suitable for an intended but eventually scrapped 128kb RAM base model, as well as being a neat fit for the available memory bandwidth with the final modes – would allow), before they realised that interlacing in mono and thus not having any hope of inter-line smoothing would be hopelessly flickery, and that 320×400 is a not particularly useful mode (and indeed hasn’t ever been popular on any of the other machines where it’s been available), and so fell back to the simpler half-vertical-rez non-interlaced modes familiar from the 8-bits just with better colour depth after the first one or two revisions? Anyone writing first-gen software for the machine, especially anything that ended up as a pack-in, must have had access to a preproduction development machine or at least one of the very first production models, so there could have been all kinds of weird differences vs the more familiar, later machines. Certainly some promotional press images Atari released showed a somewhat higher resolution/higher colour display than what was eventually built, but could have been achieved in much the same way the Amiga can offer a 16-colour display at the same resolution as the Atari mono monitor; by interlacing (flicker isn’t visible on the printed page…), and by allowing the video system to monopolise the memory bus at the expense of CPU speed (again, not obvious in a still photo), both things they might have eventually considered unacceptable for general purpose long-term use vs the modes we actually got.

    Or it could be that Mike’s monitor was one of the TV derived types that are supposed to exist that run interlaced even with non-interlaced input and only use the vsync pulses to decide which field (upper or lower) to show on each individual scan, and free-running in an arbitrary arrangement if the interlace-specific pulse patterns are missing or malformed (as they are with most non-interlaced computers). In which case flickering between two different screen buffers would indeed create an interlaced display… but, if so, how would you be sure which set of lines would display as 1, 3, 5, etc and which as 2, 4, 6? Get it right and you have a smooth-edged, if somewhat flickery double-resolution display. Get it wrong, and it becomes a combtoothed mess that looks more like a horrible vidchip glitch.

    Other parts of what Mike says in that reminiscence make me wonder if he’s not misremembering the events and fine technical details of 30+ years ago. And whether in fact the intent was instead to make use of an additional fifth colour (50% grey) that the normal medium rez couldn’t quite stretch to, as it’s only the white sprites (ship and UFOs) that flicker and nothing else – not the asteroids, or indeed the score and life counter – where that sorta-flickery grey would act as more of an antialiasing touch, smoothing things out in lieu and illusory simulation of the original hi-rez graphics, without having to draw a different set of graphics for each resolution, and more particularly only needing to update a single bitplane to move them around at a nice smooth 50 or 60fps without stressing the hardware. But then why bother colouring the asteroids with two colours plus transparent (still needing two bitplanes the same way 3+trans or 4 without transparency would) when the original monochrome graphics would have done just as well, either flickered to full rez or even just straight decimated (the dithering on them seems to be only in the horizontal direction, so halving the resolution wouldn’t break that), with a simple tint job ultimately looking barely any different, and then being able to use a proper grey on half-rez ship/UFO sprites – especially as the roids are much larger and more diverse than the other objects? Not to mention that the ship and UFOs are quite small things to move around and should have been doable at 60fps even in four bitplanes at that resolution, and two bitplanes at half vertical rez doesn’t take any more power than one bitplane at high rez (or two lots of half rez being alternated between)… after all, if the machine can shove a full rez ship around in mono at 71fps, half the pixels but with twice the bitdepth at 60fps should be easier. Mistakes happen and memory can go fuzzy after all.

    At the same time, I don’t really want to secondguess the guy too much or overly doubt him. He put together a really solid, good looking game that’s great to play, and presumably knows quite a bit about what he’s doing. So a particular seed of uncertainty remains… I’m gonna have to get the old ST fixed up, find the magazine coverdisc the game was featured on, hook it up to my last working RGB CRT monitor (it totally doesn’t work with LCDs… not sure if it’s a timing thing, or an incorrectly made SCART cable… the screens in question are just fine with an Amiga in both progressive and interlace modes – which can be easily told the difference between on a CRT, even when you just force a low-rez image to display laced) and see what happens.

    (Another sidenote – the same technique was commonly used for increasing the apparent depth of the overall colour palette, and ultimately increasing the number of colours that can be displayed on a line beyond the simple rapid-palette-updating 48 possible with software like Spectrum512, by flickering rapidly between two generally very closely related shades with the phosphors and the eye smoothing out the difference; a particular example in commercial software being the title and loading screen graphics of Leavin’ Teramis which claims a 22,000 colour palette on an STe and something like 3000 on a regular ST as a result… and *those* certainly don’t give an interlaced appearance. But more recent demos using evolutions of the same technique – and in fact running in medrez – claim not only improved colours but an up to 704 x 440 “interlaced” resolution. Something which I’ve figured to be potentially possible, on a CRT only, by careful manipulation of the timing of individual scanlines within each frame (mono lines are much shorter than colour ones, timewise, and NTSC/60hz ones are just slightly shorter than PAL/50hz; within the space of the top border you might just be able to cause a vertical timing drift equal to half a line, and so *maybe* produce true interlace by alternating between those timings and the normal unadulterated ones… which is possibly also why the horizontal rez is “only” 704, as ensuring the timing during non-border scanlines is undisturbed means you can’t make full use of the overscan techniques that would otherwise push that out to 800 or more. So it’s a very open question. I’m pretty sure that the ST doesn’t actually produce interlaced video in the normal modes, and that simply flicking between two different screenbuffers won’t automatically produce it… but whether it’s possible to produce what is essentially a glitch mode that happens to look just like it remains to be seen, as well as whether the early models – or some early monitors – actually produced the effect inadvertently and that’s what Megaroids was written for/on, or even how convincing an illusion it created on non-interlacing computers and screens… which if they were derived from TVs probably weren’t able to display full interlaced rez clearly anyway, especially in 12 or 13 inch tube form, as they’d be designed for some line overlap to reduce flicker and scanlining, perform “physical” colour blending/correction especially in PAL regions, and overall just make the image a lot smoother, and particularly in the 80-column certified models would have dotmask arrangements biased to give better horizontal rez than vertical because that’s what most older CGA-like video standards would have benefitted from… So the difference between true 640×400, and 640×200 with temporal blurring that produced a quasi-antialias effect would have been quite subtle and if you never actually saw the former you could easily convince yourself that you were seeing it when actually it was the latter… much like with some “mono emulator” programs that gave a choice of either simply smoothing/antialiasing the image (essentially, translating the image through a buffer where every odd line of the mono screen painted by the main software into a fake video memory area was spliced with every even one into the real one such that they formed alternate words, and thus represented individual bitplanes in medrez; both of them being black, 00, was a black colour in the medrez palette, both white, 11, was white, and one black plus one white in either arrangement, 01 or 10, both formed a medium grey… which somewhat ironically was by far the slower mode unless you had a blitter, and even then it wasn’t super fast), or “interlacing” it (the fake writes were redirected to one or other buffer area depending on whether they were to odd or even lines, but performed twice to double up the bitplanes and make every pixel either 00 or 11, and the vidchip simply directed to read 640×200 pixels from one buffer or the other on each scan… flickery, but rather faster and still giving some impression of antialiasing and higher than normal resolution), in both cases making a picture on a colour monitor that the user might be able to convince themselves was higher rez than it actually was. Though it would still be rather preferable to just run the program in medrez if it supported that natively and in a sensible manner, and save the emulation for those which either absolutely demanded mono mode or were really badly converted to colour and thus still looked better and were more usable via emulation.)

Leave a Reply

Your email address will not be published. Required fields are marked *