I like big Booms and I can not lie!

Well, that was a little easier than I first thought! Maybe because I implemented it incrementally, 2x2-tile sprite support is now (mostly) working. Explosions and Garu Derotas at least are good. I suspect I need to handle flipping differently for 2x2-tile sprites, because Sol Towers don't look right. It'll be a bit ineffcient but fairly straightforward. Right now I'm not concerned with code optimisation.

BOOM - 2x2 tile sprite explosion!

I had a choice of whether to program the 2nd chained sprite in the shadow registers, or on-the-fly as the sprite hardware is being updated. Programmatically it wouldn't have made much difference, as the 2nd sprite only needs tile codes, colours and the chain bit to be programmed.

I was undecided until I remembered that the latter is updated in the VBLANK interrupt service routine, and as such efficiency is critical. Much more efficient if the shadow registers are updated in the main program loop (which should be spinning idle by the time the next VBLANK interrupt fires) and simply block-written into VRAM.

Xevious is now using 266 of the 384 usable sprites on the Neo Geo. They are not all active at the same time, but there will be times when it could run very close to the 96 sprite-per-scanline limit. As I mentioned, there are 75 sprites always active on any 1 scanline at a time, not counting the Xevious sprites. Cutting it fine, but I think I'll get away with it.

UPDATE: I have fixed the 2x2-tile sprite code and all the sprites I have seen thus far in the first few levels are correct. It wasn't a flipping problem, but rather the details of how the sprite codes are mapped amongst the 4 individual sprites. I also fixed a (seemingly) benign bug in the sprite rendering code.

The Sol Tower is finally rendered correctly!

Another issue I had to fix at the same time; because of the difference in coordinate systems, the 2x2-tile sprites need to have their X coordinate adjusted with respect to 1x1-tile sprites. Initially the adjustment was done simply when updating the shadow registers, but then tonight I noticed I could no longer destroy the Sol Tower once it had risen!?!

I quickly realised that it was the sprite X coordinate adjustment that was breaking the bombing-detection routines that use the shadow registers (as I mentioned in a previous post). I looked at moving the adjustment to the sprite hardware register updates, but there's not enough information to (efficiently) determine when the adjustment needed to be made. It's also not ideal to spend more time than absolutely necessary in the VBLANK ISR. It was then I had the idea to have the code write two versions of the shadow registers (for the X coordinates only); the original coordinates for bomb-detection, and the adjusted coordinates for hardware register updates.

In hindsight I'm a little surprised the implementation for 2x2-tile sprites was completed in a day, and as it turned out I had procrastinated for no good reason. It certainly looks a lot better, and I am even closer now to being able to declare that - sound aside - the OSD code is complete.

There are still a few glitches that I have ignored until now; occasionally the score (foreground tilemap layer) is just a black bar, and the map isn't displaying the tiles from the 2nd bank (not visible until later aeras, and I'm sure it was at one point previously). I'll proably continue to ignore those until I get to optimising the OSD routines.

For now though, I'll continue with any new ground-based objects that appear in Area 2. First up is the Domogram - the round vehicles that follow paths and fire at the Solvalou. The RE for them is complete, so I know what I'm up for. FYI they blindly follow pre-canned paths, cleverly designed to give the illusion of some sort of ability to actively avoid Solalou bombs. They won't be the first moving objects that have been (at least partially) transcoded (Grobda claim that prize) but will certainly add to the dynamics of the screen once they're done.