This series of articles, together with another_js[1], inspired my port of Another World for the Game Boy Color that I'm slowly working on[2][3].
Getting the basic game running in shades of gray was relatively little work due to the game being bytecode based (and the great single file example VM implementation from another_js!), but getting the game's 16 colour palette to work with the CGB's 4 colour palettes and still look good is unfortunately a very manual process to work around the limitations of the platform.
Anyway, it is a lot of fun to work on. I'd highly recommend as a hobby project porting it to some other (less constrained) system, or implementing the game's VM in whichever new language you're interested in trying.
A programmer at Interplay, Rebecca Heineman, ported Out of This World to Super Nintendo around ... 1992 or so?
It was an amazing accomplishment because the SNES only had a 3.58 MHz (yes, you read that right) processor, and wasn't afforded the luxury of drawing into a traditional pixel-oriented bitmap (e.g. one byte per pixel).
The code that Rebecca wrote rendered triangles into SNES "chunky planar" format on the fly. The chunks are 8x8 pixel tiles, where the bits of each pixel are spread out across four planes (https://sneslab.net/wiki/Graphics_Format). And all this at 20 FPS, a feat which still boggles me, 30 years on.
I’ve no doubt it either has already been reposted or will soon be, as apparently ‘tis the season (this is the 2nd or 3rd repost I’ve seen for the series)
The article is wonderfully technical and full of meaty details, but the stills just don't do the art justice. Here's a long play that gets right into the action:
So one thing to remember - the game looks great. But it is quite frustrating to play, me and a friend fiddled with it for a while and got bored pretty quickly. Watching those playthrough videos will probably leave you with a much higher opinion than actually playing through it yourself.
That was not my experience. I LOVED this game when it came out. It was so different from everything else and the smooth motion was just something I hadn't seen before.
You have much better patience than me, or maybe this just isn't my sort of game. I felt like it was just an exercise in memorizing the right sequence of steps, and found the controls to be a bit fiddly and unforgiving. It's undeniably gorgeous and I wanted to like it because I'd read the various Fabien Sanglard articles, I just couldn't :(
It was a lot like practicing on a piano, just with less keys. Learn the correct sequence, play it back keeping the correct timing, voila. I agree it's a specific mindset, yes.
It's kind of a Dragon's Lair style platformer, really. Twenty minutes of work down the drain because you forgot to push left on time. Pretty standard for its day.
The game might look great now, but when it came out it was mind blowing. We'd watch the intro at parties.
Precisely that. Repeating all the steps to get up to a certain point, trying something different, failing and having to do them all again until you beat that section. Then you get to the next bit, fail and start over.
It reminds me a little of the final(?) map on Super Mario Odyssey: https://www.youtube.com/watch?v=3nyFu1kud-s. It's probably 5x longer than any other map and any time you "die" you have to start from the very beginning. It took me dozens of attempts to beat it, but for some reason I stuck with it. I didn't fancy doing this with Another World sadly :(
While working on my own implementation of the bytecode interpreter / VM, I built a little tool [1] to render the polygons outside of the game.
It can load unpacked resource files of the game (the GOG version comes with uncompressed resource files for example, other versions need an external tool to extract them).
It helped me to debug some issues with my renderer.
Currently it's hosted in my private GitHub Pages repository, but the source code isn't obfuscated :)
There's also a demo of my (private) Another World interpreter compiled to WASM [2].
It bundles the game files of the DOS demo, which means the intro cannot be skipped.
My native desktop version supports loading of files from multiple versions of the game (some, like the unofficial GBA version lack support for their music files).
Some time in the future I'd like to add support for "uploaded" game files to the WASM version as well.
That was a very interesting article, I was surprised at how dense the byte code was. Seeing what people can do on platforms like that and DOS reminds me that we should always try to make things simpler.
I wonder who takes interest in reverse-engineering these old games.
As a professional programmer, there's so much to learn nowadays that I wonder how they find the time to invest in time-consuming niche projects which don't lead to directly transferable experience. I also assume that the people (like me) who did play these games are older and busy with other things in life?
Anyway, I think this is awesome that people do that, and it's the spirit of HN. I just wish I had the time...
I think a lot is transferable. It depends on what your daily job is. Retro-gaming and emulation is low-level. So if your job is low-level like systems, OS, embedded, etc, then it's transferable experience/knowledge.
In terms of processing power a PC was
far superior to the Amiga and Atari ST
we visited last times. The problem for
gaming was the video which was
extremely slow.
I was going to say, "On what planet was a 4.77 MHz 8088 'far superior' to an 8 MHz 68000?", but then looked up the MIPS-per-MHz figures, and the 8088 was indeed faster. I sure don't remember it that way.
(Edit: looks like I was reading the table wrong. The 68000 Dhrystone MIPS score is indeed better by a factor of almost 2x.)
The game is originally from 1991, and the PC port in 1992 targeted graphics adapters introduced in 1984 and later. So it's reasonable to assume that the statement about CPU performance isn't about the original 1981 PC but about what was more typical of PCs in the late 80s, well into the Turbo button era.
A 33Mhz 486 ran Doom at 7, 11, and 15 fps respectively on three graphics cards.
A 66MHz 486 ran Doom at 8, 13, and 24 fps respectively on the same three cards.
The cards would've been attached with the same bus: 8-bit AT bus at ~10MHz, 16-bit AT bus, and 33MHz VESA local bus. (The 66MHz CPU is "clock doubled" so same equivalence for accessing memory, cache beyond L1, etc).
tl;dr if you had an older graphics card in your PC, it would be the bottleneck and having the CPU run faster may not have helped.
Getting the basic game running in shades of gray was relatively little work due to the game being bytecode based (and the great single file example VM implementation from another_js!), but getting the game's 16 colour palette to work with the CGB's 4 colour palettes and still look good is unfortunately a very manual process to work around the limitations of the platform.
Anyway, it is a lot of fun to work on. I'd highly recommend as a hobby project porting it to some other (less constrained) system, or implementing the game's VM in whichever new language you're interested in trying.
[1] https://github.com/cyxx/another_js
[2] https://www.youtube.com/watch?v=dv00LlmFq0o
[3] https://twitter.com/mcurrie/status/1451460454530764800