I'm a big Sonic fan since the first game came out (not such a big fan of the newest ones, though), and 'till this day the Mega Drive/Genesis Sonic games are still my all time favorites. Since I started programming, my dream was to code a decent Sonic game from scratch.
Since I'm a big fan of the NES, I learned how to program for it a few years back. I happen to really like the idea of pushing the system to it's limits, so I just decided to code my sonic game for the NES. I wanted to do better than the pirates that exist for the NES (Somari and Jurassic Boy), because those are pure crap (the physics, more than anything). I also wanted to do better than what was done for the SMS/GG, which are nice but have a few problems, such less-than-smooth movement, repetitive graphics, small levels... I wanted the opposite of all that, becuse I really believe we can achieve more with 8-bit hardware. So the goal is to go beyond all other 8-bit games, getting as close to the 16-bit series as much as possible.
Everything is comming along pretty nicely: The scrolling engine works perfectly (it's able to scroll 16 pixels per frame in either direction, both if necessary), in levels that can be really large (built with 256x256-pixel "blocks" - like in Sonic 1 - each indexed by a byte in a level map of up to 1024 or 2048 bytes, depending on how much RAM I have left in the end), larger than anything I've seen on the NES. The sprite engine works well too (although I feel it could be optimized a bit). Anyway, there is still a lot of free processor time that will be used to process the active objects, as well as Sonic (or another character I'm not revealing yet), and I suppose that will be the most intensive task to perform, so the rest of the engine must be very efficient.
I often come here and read about all the things you guys have discovered about the original engines, and I usually try to have the things in my game work in a simiolar fashion, as much as the hardware constraints permit. It's not unnusual having to rething something so that it behaves the same but is implemented in a way that requires less resources.
I hardly go look at the disassembly of the games directly, because I don't want to copy that much. Plus, I'm not fluent in 68000 assembly (as I am with 6502 which is what the NES uses), but even when I'm able to follow the program flow with the aid of some documentation, there are a lot of details about the engine (and the Mega Drive hardware) that prevent me from fully understand the logic.
Here's the actual question:
Thing is that I haven't found much info about how the original engine goes about loading the objects
and this is the first real problem I'm facing. I have thought about a few different solutions, and although all of them could've worked, they all seem to have flaws. One of them is too slow, another one imposes limitation on object placement, another needs too much RAM, and so on.
What I'd like to know is if you guy could give me a description of how the main game engine finds in the object definitions the objects that are in range and should be loaded. By looking at Sonic 1's disassembly, I can see that this is done by the "ObjectsLoad" routine, but I'm having a hard time figuring out what it does with the object definitions.
I'm aware the the solution used by sonic Team may not apply to my engine or to the system I'm programming, but I'm running out of ideas here, and before I decide to go on with an sub-optimal design, I decided I'd ask you guys about it.
Thank you very much for the help!