Curious about past computer architectures? Software engineer [Fabien Sanglard] has been experimenting with porting Another World, an action-adventure platformer, to different machines and comparing the results in his “Polygons of Another World” project.
The results are pretty interesting. Due to the game’s polygon-based graphics, optimizations vary widely across different architectures, with tricks allowing the software to run on hardware released five years before the game’s publication. The consoles explored are primarily from the early ’90s, ranging from the Amiga 500, Atari ST, IBM PC, and Super Nintendo to the Sega Genesis.
The actual game contains very little code, with the original version at 6000 lines of assembly and the PC DOS executable only containing 20 KiB. The executable simply exists as a virtual machine host that reads and executes uint8_t opcodes, with most of the business logic implemented with bytecode. The graphics use 16 palette-based colors, despite the Amiga 500 supporting up to 32 colors. However, the aesthetics still fit the game nicely, with some very pleasant pixel art.
There’s a plethora of cool tricks that emerge in each of the ports, starting with the original Amiga 500 execution. Prior to the existence of the CPU/GPU architecture, microprocessors had blitters – logic blocks that rapidly modified data within the memory, capable of copying large swathes of data in parallel with the CPU, freeing up the CPU for other operations.
To display the visuals, a framebuffer containing a bitmap drives the display. There are three framebuffers used, two for double buffering and one for saving the background composition to avoid redrawing static polygons. Within the framebuffer, several tricks are used to improve the graphical experience. For scenes with translucent hues, special values are interpreted from the framebuffer index by “reading the framebuffer index, adding 0x8 and writing back”.
Challenges also come when manipulating pixels given each machine’s CPU and bus bandwidth limitations. For filling in bits, the blitter uses a feature called “Area Fill Mode” that scans left to right to find edges, rendering the bit arrays with spaces between lines filled in. Since the framebuffer is stored in five separate areas of memory – or bitplanes – this requires drawing the lines and filling in areas four times, multiplying by the hundreds of polygons rendered by the engine. The solution was to set up a temporary “scratchpad” buffer and rendering a polygon into the clean space. The polygon can then get copied to the screen area with a masked blit operation since the blitter can render anywhere in memory.
Intrigued? The series continues with deep dives into Atari ST, IBM PC, and upcoming writeups on SEGA Genesis/MegaDrive.
I’ve never heard of the game, but it sounds very interesting. The virtual machine reminds me of a more graphically-oriented version of the Infocom Z-Machine.
One quibble I have about the article is the paragraph about the Amiga blitter. The consumer microprocessors of that era did not have built-in blitting “logic blocks”. On the Amiga the blitter was a coprocessor (one of several coprocessors) that could be configured perform many different memory operations including copying, line drawing, and area filling. As for CPU/GPU architectures coming later, I would say the Amiga’s coprocessor architecture is essentially the same as a CPU/GPU using shared memory.
The blitter was a separate IC on the Atari ST as well, with all (I think) ST models not having one unless it was installed after purchase (STe models had one). It isn’t required for the Atari ST version of the game and I doubt that the game would use it if one were present in the machine.
“the Amiga’s coprocessor architecture is essentially the same as a CPU/GPU using shared memory”
Well, sort of. It’s more similar to modern consoles than modern PCs, which tend to have separate main RAM and video RAM. The Xbox One and PS4 both use the same CPU/GPU combination chip, with a single pool of memory.
That said, the Amiga had “Chip RAM” and “Fast RAM”, chip RAM could be used by the entire chipset, including the custom chips, whereas fast RAM (typically added by the end user), was only addressable by the CPU, and could not be shared. Because fast RAM was typically not part of the base specification, it wasn’t much used in games.
Part of the magic of the Amiga is that the main graphics chip (Agnus), had a clock speed directly tied to the beam speed of whatever TV it was plugged into. This allowed talented programmers to pull off a lot of clever tricks.
This game left quite an impression on the younger version of myself. It’s great to see a write-up on how it was implemented across systems. Great read!
I did wonder at a time how this game worked, yes after reading the very nice article, I still have a couple of questions, I think one can guess the answers, the animations are actually sequences of bytecodes. Very impressive.
Now I’d like to know how Zool worked ! :)
Funny thing the “making of” is bigger than the game.
fabiensanglard.net … yayyyyyy!
The world needs more eye friendly web pages like these!
The background: http://fabiensanglard.net/bloated/index.html
Can you please run the entire internet?
Please.
*he. Whomever.
I have fond memories with this game. It was a revolution back then..no score, nothing else than the scene on the screen. And pardon me but: what a cinematic introduction for that time !!!! Nothing short of a classic. All kudos to Eric Chahi
“The graphics use 16 palette-based colors, despite the Amiga 500 supporting up to 32 colors.”
“For scenes with translucent hues, special values are interpreted from the framebuffer index by “reading the framebuffer index, adding 0x8 and writing back”.”
..thus explaining why they only used 16 colors – they were saving the other 16 for this “alternate mode”.
Not really. There was also the fact that other systems were limited to 16 colours (ex: EGA graphics on PC).
This game was way ahead of its time in a graphical sense. 2D vectors <3
However I found the gameplay super annoying… Never managed to progress far into it. I'm just not a fan of platform games.
It was certainly a very difficult platformer. I found it took a lot of patience and split second timing. At least the game was rewarding in the spectacles it revealed as things progressed. It took me quite some time to beat.
The tricks used for the SNES port of Another World (which were only necessary because the publisher was a bastard and only allowed the developer to use the absolute cheapest cartridge Nintendo offered) are pretty interesting,
I kid you not…..I am currently wearing my Another World T-Shirt while reading this.
If there are five bitplanes used how is it drawing areas in only four bitplanes? What’s the fifth bitplane doing? Especially if it’s only a 16 colour screen?
You ignore it leaving it cleared as all zeros so the colors are only 0 to 15 inclusive.
So it is stored in 5 areas, you’re just not touching the 5th one. Drawing to only 4 planes.
The post is correct, maybe just worded a bit confusingly.
It is confusing as it says the framebuffer is made of five bitplanes. That would imply a 5 bit screen. But the screen itself is only 4 bit. So that would mean in total the game uses 5 bitplanes to process graphic data while displaying it on a 16 colour 4 bitplane screen. Back buffers aside. I find the use of the term framebuffer slightly anachronistic as well as that term was not used on the Amiga. On the Amiga the graphic display is called a bitmap. Especially as it is split into separate planes and is a true bitmap.
This is kind of a confusing article. Wasn’t this game originally designed on the Amiga? If so, why would you port a DOS version to the Amiga?