Sonic Engine Demo

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

1. 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!

 

I simply wrote a list off the top of my head. I actually honestly don't know much about either than the fact that they are used as Sonic engine implementations. I didn't even know you were involved with one until Quexinos told me last night. Understand I've only recently "re-appeared" on this scene so I didn't have time to see these projects form.


Re: To all sound problems --

My sister also had a laptop that for all intents and purposes SHOULD have been able to run this, and graphically it ran at full speed but sound-wise was stuttering. That's what I believe is a few possibilities, but overall probably Allegro. I should probably make this run under SDL or something to cut out the fat.

Also, for any sound quality complaints on PC side, yes, I'm still using the ancient YM2612 core. Something to-be-upgraded.

 

Well, it's a simple attempt at "getting it out there." The reason being that it's a lonely world doing this solo, and I do wish to seek the knowledge of those who have gone before me and have a much greater understanding of the Sonic engine. This only works as well as it does by learning as I go, which is a tough road to take. I could hole up for a year and complete it and perfect it before anyone sees anything, but by that time maybe someone with a quicker wit who lives with their parents as a couch potato and can work on it 16 hours a day may have beat me out ten-fold.

Thanks to Krigo, Polygon Jim, Delta, Sintendo, roxahris, muteKi for the enthusiasm.

Tweaker we'll work on :P

 

It's okay, I realized some overreaction on my part, and I'm attempting to reduce it. I just know it has problems and I'd prefer if you replied with something better than "the physics are wonky and I think you should continue hiding it for a while." I'd prefer it if you used something more descriptive than "wonky"; list me problems. They might all be related. I think there's problems in the traction function for example, which would explain some strange abilities to accelerate up hills. Yes, it does have problems. Work with me here, though. I played Sonic games but never really analyzed Sonic games the way you guys have. I'm asking for help, not being told it's not time for me to be publicizing. Can we kind of meet in the middle here? :P

The bell has been rung, and you generally can't un-ring it. So maybe this wasn't the best way to go. But I can meet half-way and say that I don't release anymore until it's been more heavily reviewed. If I can have a support system I'll perform private demos to work towards public release.

 

I do want an honest assessment about the E02 issue thing. I thought those were simply implementations of the physics only, idealized for a PC runtime. If that's NOT what they are... someone please rundown what these are, because apparently they're bigger than I imagined.