No more candy, back to meat and potatoes.

I've got all the static objects rendered in their correct locations now; the only objects remaining are those relating to the player and/or are dynamically generated and/or move. Because I can't really test any of those though, I'll leave them until I have implemented the code to allow me to do so. In summary, most of the objects are rendered and it's time to proceed to the next stage.

The choice I have now is to either analyse in minute detail and then implement the sprite priority (Z order) code, or continue with reverse-engineering the rest of the code.

I've chosen to go with the latter - I'm on a roll and I don't want to risk getting bogged down in the detail of one particular routine which is, ultimately, purely cosmetic (albeit important). I figure I can tackle that right at the end whilst I can see the light at the end of the tunnel.

The key data structure in the game is an array of objects that is constructed before you enter each room (screen), and contains an entry for each sprite including the player, special objects, and foreground & background objects. Each entry is 32 bytes and contains not only 3D location & 2D rendering information, but also state information for objects for example, that move.

Last night I deduced the purpose of another two of those 32 bytes, now leaving 11 (plus a few flag bits) still remaining unknown. And whilst trying to get to sleep shortly after it occurred to me what one of the unknown flags could be - but I'm yet to test that theory.

Besides those 11 bytes, there's around 30 other 'global' variables whose purpose also remains unknown. A few of those are simple flags accessed in only a few places in the code (which shouldn't be difficult to deduce) and at least a few others are temporary storage for the recursive Z order routine. Most of the game state is stored in the aforementioned object table.

EDIT: In one fell swoop I've confirmed my theory about the flag and also crossed another three global variables off the list!

And finally, it's clear that the sprite adjustment routines are actually the object handler/update routines (and to give you an idea of the work involved, whilst there are 188 sprites defined, there are 'only' 50 distinct handler routines), so I've got a bit of renaming to do in the disassembly and my C code. I am confident now though that I have full understanding of all the code and data structures and there should be no surprises from hereon-in; the puzzle is starting to come together.

I've got a fair bit of code to implement now as I need to flesh out the main loops and the routines I've already reverse-engineered but haven't yet bothered to port to C (as they don't play an important part in the rendering) and then start to implement the bulk of the handler routines as I reverse engineer them. There's a bit of code re-use so the C port might get a little messy at the lower levels and it won't be easy to keep track of what has and hasn't been fully implemented.

The next bit of eye candy probably won't be for a while, though it'll likely be a video.