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.

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 ! :)

I have fond memories with this game. It was a revolution back 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).

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,

By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more


Automatic Capping Machine, Bottle Filling Machine - Shengguan,