Short version: Attempt at "perfect port" of Sonic the Hedgehog 2 as C source that can compile to any capable platform, including the original Genesis itself. This release is fairly premature, so maybe it shouldn't have been shown off yet. I think it's an interesting idea and not necessarily redundant against E02 / ProSonic or whatever since it focuses on being a purist portable version, not just an engine implementation. --- Download --- http://www.el-hazardonline.net/downloads/S2EngineDemo.zip Binary updates for above link; download both, but overwrite the binaries with this one ------------------- Long version: Okay, guyz. Here's the gist of what I've been doing. Since I first heard of the disassemblies, I instantly had visions of porting the code to C and creating a native executable on another platform. Then Stealth did his wonderful Sonic 1 single zone demo, but after he decided not to release any source and such, I decided to finally get in gear. Quexinos actually leaked a little bit early about part of it, which is what actually resulted in this thread at the beginning of the month. The truth of it is, I didn't initially intend for the sound engine to be a solo item, but it can and obviously has use in that form. But enough about that. So, inspired by Stealth though not living up to his same objectives, 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 8x8 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. A few magic C macros turn a label such as: Code (Text): static resource ArtUnc_Sonic = RES_SPRITE_UNC(Obj01_Sonic); ... into a filename string on a disk-based system (in this example, "sprites/Obj01_Sonic.art") and a ROM based system will turn it into an externally defined label (in this example, "ArtUnc_Obj01_Sonic".) Code is currently compiled under Microsoft Visual Studio 2003 for Win32 and GNU GCC 3.4.5 cross-compiled for 68K for the Genesis/Megadrive binary. I would hope and assume that the code could also be compiled under GCC for Win32. Why: I always felt that assembler was a very tedious way to go, and making a portable C version enables not only easier coding but use of common debug tools to facilitate a shorter, easier development cycle for those who just want to employ the engine but not get bogged down in 68K asm. This opens the doors to a wider audience. And also just plain makes it easier for the rest of us! There are currently posts made about "exciting" developments such as having more than 16 zones or adding "Act 2" music in Sonic 2 ... wouldn't it be great if the former was as simple as increasing the array size in your C source, which it currently is in this case? ) Limits: The library is constructed to be opaque, meaning that some limits are in place, but these ease the porting of a greater PC platform to a lesser platform such as Genesis/Megadrive. E.g. it still uses an object list (which YOU supply) of a max 256 objects, so each object ID remains only one byte. The zone size is set at Sonic 2's sizing, so it cannot arbitrarily be made larger from the end-user's position. Memory is probably the largest concern. Currently when compiled on Genesis/Megadrive, the final binary reports using 57,496 (out of 65,536) bytes, and really you can't use every last byte anyway due to needs of stack space and whatnot. The good news is that I don't expect that figure to get much larger, so the end-user may have a few kilobytes. But don't panic -- this current figure includes the maximum supported number of in-game "active" objects, each of which has a default RAM space just like you see in the disassembly. The amount of memory you are likely to actually use in a typical application of the Sonic Engine will probably amount to only a few hundred bytes at the most!