Sonic Engine Demo

This is truly a "to each his own" type of argument. I can work with assembler just the same as I could clean oil out of cement floors for a living. I've done both but prefer neither, if I have a choice. This provides a choice. I find assembler something I can handle, but it requires a lot more brain power and imagination, and it's all too easy to screw up the stack or modify the wrong register and get unpredictable results, which was one of the problems I constantly ran into. And on your next point...

This is true. However, of all higher level languages I could use, I know of no greater controllable language than C. The memory you allocate is very specific based on types you use. I have so far recreated all of the major arrays used by the system and require exactly the same amount of memory they originally took, I ensured that with tests before committing. If you use GCC cross-compiling for 68K the RAM will be the same. Yes, there is always the trouble of the code not being as efficient. This is a fact of life with any higher level language. The best thing I can say is, observe the same healthy practices you use in assembler in C. Don't make unnecessary function calls (inlines are supported even in C with GCC), perform shifts / logical operations as appropriate, avoid straight up multiplication and division as much as possible. And, of course, turn on optimizations. I also do post-compile audits of code to see if they've become "ridiculous." However, GCC has time and again shown me some amazing generation that I personally would never have thought of doing if doing assembler by hand. Obviously that's not ALWAYS the case, so mind critical loops. It's a programming game. If I get further along and see that the performance will never be adequate (it will almost certainly be less, but I wouldn't write it off yet) then I'll see the futility of it.

Good ol' endianness. Right now there are #if/#else preprocessor blocks that change endian-specific accesses, and I leave big endian as the "main" format so that Genesis is doing zero conversions yet the PC is doing a few minor load-time-only conversions. And technically my "resource packer" in use on the Genesis is also setup to later post-convert resources automatically for a little-endian based ROM system (I.e. GBA) since it ties into the loader code and thus will pre-convert resources as necessary.

Yes, that will depend on that. My first goal is to make it work. But keep it abstracted enough that the graphics system can be pulled later and replaced with something better.

Well, first of all, the "final" version of this, since it uses the same data in the same format as Sonic 2, can and likely will be distributed without data. I only did it this time for a quick "get up and go" demo. We didn't get into how my system works in detail. The "resource packer" program gathers up resources into a ".s" file and produces a header file that gets compiled with GNU as and externalizes labels. This is linked with compiled source. Thus there is no reliance on data actually being present in your code. So there's no reason I should have to distribute it either. (Just source and the freeware compiler.) And because I put the main code in a library and game specific code outside of it, making a whole new game is as easy as throwing away the other half.

Believe me, I did consider that venue. However, I have no evidence to support this, but I have heard from two different people with completely different associations that say that Sega has "lost" their original source and they actually are interested in what goes on with these works, rather than against them. I don't know if that's true, but I can see the possibility in the situation. Obviously if I got a cease and desist notice I would quit. But yes, the future would be a source/binary distribution sans data, and someone will have to use the existing tools on their own ROM with the split and whatnot OR obviously use their own data and forgo some of that legality. I don't know what can be said other than there's probably no practical difference to distributing assembler and data versus distributing C and data. All of us being in this association are treading foreign waters and that's just the name of the game.

As for your hope of professional work, I have no comment. Maybe it will happen, maybe it won't. I would say there's a far greater chance they're waiting for one of me so they can get it free than waiting to pay you. They are likely more interested in developing based on resources available to them, especially with some abysmal Sonic titles ruining the name and putting them in deep water. Sure I would love to do it for the same reasons you have, waiting for a paycheck for a hard earned porting job, but I'm not holding my breath. I'd rather do it and talk about having experience working with 68K assembler and making C ports of functions (non-specifically) than waiting for a contract that may never come. (Although seriously, if you're contracted tomorrow, I'd probably quit out of respect.)

Okay, I "sales pitched" that a little bit. It is instruction by instruction, but my guess is I made a few misinterpretations, based on the problems I do have reading assembly. It's darn close with subtle errors. I've gone through it before casually and found conditionals that get reversed or forgetting to pay attention to byte access and thus not wrapping an addition value in C correctly (which likes to convert up to integers if you're not explicit.) It just means it's time to audit the source function-by-function and clean up errors. Which I will certainly do.

 

For those playing along at home, here's a new Win32 executable and Genesis/Megadrive ROM entailing various cosmetic and gameplay fixes I made to Sonic. Can now run fast enough to break the screen update a bit. :P They were all "stupid" fixes that were actually simple logic errors...


The ZIP is binaries only; you still need the data from the original download in the first post.
http://www.el-hazardonline.net/downloads/S2EngineDemoUpd.zip


Shouldn't be any other releases for a while, just wanted to get the majority of crappy physics/cosmetic bugs out of the way...

 

Right now I'm just kludging the camera movement. I'll need to go back and do it proper. There was just a lot more pressing problems I wanted to deal with first.

I'm basically planning on swapping out Allegro for SDL. I just wanted to get all my base functionality in place first.

I can't seem to replicate this one. There are limiters in place that shouldn't let that happen and seem to be working from my end.

Both are part of the plan, actually.