The Polygons of Éric's Chahi Another World | Hacker News Reader

The Polygons of Éric's Chahi Another World

fabiensanglard.net

161 pointszaiste33 comments

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.

[1] https://github.com/cyxx/another_js

[2] https://www.youtube.com/watch?v=dv00LlmFq0o

[3] https://twitter.com/mcurrie/status/1451460454530764800

That looks pretty cool. It reminded me of the GBC version of Alone in the Dark[1] and the unreleased Resident Evil port[2]. Keep up the good work!

[1]: https://www.youtube.com/watch?v=B3JYj6nY5Ys

[2]: https://www.youtube.com/watch?v=L73vkt3p71A

Looks awesome! Way better than I expected from the GBC! Better looking than any GBC game I ever remember playing. Great job!

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.

The website has a page covering the SNES port : https://fabiensanglard.net/another_world_polygons_SNES/index...

I like the comments about how they had to keep optimising because management wanted to save money on the cartridge hardware!

FWIW the linked article is just the introduction on an entire series on the game. The SNES port is covered at https://fabiensanglard.net/another_world_polygons_SNES/index...

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 bit about putting code in the DMA registers because they weren't used is such an insane trick :)

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:

https://www.youtube.com/watch?v=utrxk5_PeEY

I can't believe this was done in 1991. It looks perfectly modern and is incredibly gorgeous to look at.

the atmosphere of the game was incredible

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 :(

This was one of the first games I actually finished! lol.

I do remember some parts being challenging to time right, but it’s a game… if it was easy it would get boring

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.

[1] https://max-m.github.io/aworld/index.html [2] https://max-m.github.io/yaw/index.html

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 also assume that the people (like me) who did play these games are older and busy with other things in life?

I did play these games when they were released. And I still find the time to reverse-engineer them :)

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.

Kids, eh? ;)

(2020)

Previous discussion: https://news.ycombinator.com/item?id=21937607

Great series, but one assertion jumped out at me:

   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.

It was 7.14MHz m68000 vs 66MHz i486. CPU speed was no contest, but graphics performance was only just getting decent.

Even if the CPU was fast enough to do all the graphics work, getting those pixels to the framebuffer could be a bottleneck. See benchmarks on p287 of the same authors' Doom book at https://fabiensanglard.net/gebbdoom.pdf (https://fabiensanglard.net/gebbdoom/ if you'd like to pay for it):

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.

The game doesn't run on an 8088. It came out in the early 90s and targeted 286's.

Just watched a great video on this topic.

https://youtu.be/0iz9PJbs5rE

Wonderful blog, I'm in awe of people who can consistently write quality posts like this year after year.

Is there a book or blog or video series that “holds my hand” and walks me through the Doom code base in detail?

Yes! From the very same author as the above article: https://fabiensanglard.net/gebbdoom/

He makes $0.77 in profit from each $54 book sold. Jeeze, remind me to not get into writing books.

Reply on news.ycombinator.com