Fan Flash: Sonic in C

Attempt to Port Sonic 2, Engine to Code

A very interesting and well received demo has been released, and it represents the beginning of one Sonic fan’s effort to port an entire classic Sonic title to C.

In the end, Rob Jinnai’s undertaking will hopefully mean the ability to compile the whole of Genesis Sonic the Hedgehog 2 to multiple platforms, including the classic console.  Ideally, that will include the original Sonic engine in whole.

Rob hopes that if this effort is successful, projects can include other classic Sonic games:

…here’s what my project is about: get all of Sonic 2 into 99% portable C code. The dangling 1% is platform-specific wrapper code that obviously must exist. I chose Sonic 2 because it’s obviously popular among the hackers plus I figure it easily goes backward to Sonic 1 and, with some love and more research, I believe can be forward adapted to Sonic 3, eventually.

My work so far has been the tedious task of recreating the game engine code instruction by instruction, which obviously includes the SMPS demo previously seen, which was created by understanding the Z80 engine. So far I’ve been working on the actual display and detection of zone data. I have an incomplete and currently non-functional beginning of object detection. The demo included at the end of this post contains a current proof-of-concept prototype — a demo containing all zones from Sonic 2 (some more or less browseable) that runs almost equally on both PC and a Sega Genesis/Megadrive emulator. (Untested on real hardware, not a priority yet, though eventually I’d like to get it 100% hardware compatible as well.)

Features:

• PC edition imitates the 8×8 64KB VRAM character graphics, palettes, scrolling layers, VDP DMA, sprites so that it is a very decent approximation of how it will display on native Genesis/Megadrive (or other character graphics based)
• C source automagically switches resources between being constant pointers in ROM or delayed-load pointers on disk-based systems. So if you’re building a ROM edition, resources are automatically labeled and linked. If you’re building a disk-based edition, resources are automatically given filenames to be loaded when queued.
• Except for system-level calls, there are no “tricks” in the source. There’s no “assembly optimized” versions of the physics or zone “rendering” code at this time. The same exact code is compiled straight-up on both sides!
• The actual engine code is tucked in a library; this means that the typical end user just utilizes the library and codes “externally.” They never muck with the system-specific stuff. The end-user programmer’s job is to code objects and handle their own resources on their side. The actual decompression routines, memory management, disk management, detection, and all the rest is handled by the library. This also helps keep the system “under control” to ease the portability concept.

You can grab the demo as well as get a tally of the project’s progress over on the established Sonic Retro thread.