The Mother of all Objects!

Finally debugged the Sheonites. Aside from more than the usual number of bugs in the transcode, I also updated the RE with more accurate subroutine descriptions as a result of my debugging. As it turns out, the left and right Sheonites are almost identical, except for the fact that when they 'combine' just before leaving, the left-hand Sheonite object is destroyed, and the right-hand Sheonite represents both as it shoots up the screen.

Sheonites done and debugged - the game
would never have been the same without them!

Having completed the Sheonites I moved on to the Andor Genesis (mothership). There was a bit of code in the SUB program that I had to transcode, and then work out which part(s) of the MAIN program handlers I had to implement first - the Andor Genesis comprises no less than 15 distinct objects in the object table.

In my RE up until now, I sped through the Andor Genesis handlers using 'place holder' names for all the parts. Now that I am implementing them one-by-one, I can actually back-annotate which part of the ship is handled by each object.

The ship comprises nine (9) 2x2-tile sprite 'body' objects (3x3), overlaid with 5 objects (sprites) for the turrets/reactors, and one 'master' object for the entity as a whole. I had to implement the latter object first, as all other objects reference that for state, position, etc. Thus far I have implemented the master (in part at least), the 9 'body' objects and one turret/reactor (bottom right).

Andor Genesis - partly complete

Xevious maintains a table of 64 objects - or rather a set of tables - that includes a table with the function handler address. As you'd expect, handlers (ordinarily) operate on the object with the same index as the handler is currently executing from. eg. A handler in slot #4 is operating on object #4.

The Andor Genesis, however, is unique in that a whole bunch of handlers - the 'body' handlers for example - don't reference the current object at all, but rather comprise hard-coded references to another object in the table. eg. The handler for object #1 (explicitly) modifies object #9 instead.

I can't say for certain why this has been coded this way, but it looks like they've had to reverse the order of objects in a hurry, and for some reason, they've chosen to do it this way. I should note that the lookup table for objects that comprise the Andor Genesis is actually in the SUB CPU ROM, so perhaps that has something to do with it?

Anyway, I've tried to remain true to the original code, and have preserved this aspect in the transcode. It did have the potential to mess things up a bit if the offending objects weren't all benign, but fortunately they don't call any common routines that expect the object pointer in A5 to be consistent with the index of the handler. Conversely, the not-so-benign turrets/reactors are in the right 'slot', so routines like firing at the Solvalou work properly without juggling registers.

I have seen the 96 sprites-per-line limit again with the Andor Genesis. In line with each turret there are actually 8 Neo Geo sprites, and that's without bullets. Line up the Solvalou to bomb a turret and that's another 4. Add a few bullets... that 20-sprite overhead is getting eaten up quickly.

I had the idea of turning off the middle of the tilemap layer during gameplay, as only the top 2 lines and bottom line or so is ever used during a game. A few more lines are used during attract mode, but it would at least give me another 12-30 sprites head-room...