Audit #7 - only 7 bugs remain (plus the others)

I've managed to complete a number of audit sessions since the last post, mainly micro-optimisations and annotation updates, but some bug fixes as well.

I have a list of eight (8) known transcode bugs in my notebook, and tonight I finally fixed one of them. The high score entry was working except in the case where the new score was the highest in the table; it wouldn't copy the new score or clear the name from the 1st entry (and in the process I added a build option to specify the starting score). Now there are 7 known bugs...

In my audit I'm currently looking at the routine that determines whether the Solvalou has been hit by a Bacura, which is another known bug - the hit box seemed to extend off the left-hand side of the Bacura. Upon closer inspection, after some experimentation, it is apparent that the hit box is shifted to the left. You can actually fly through the right-hand side of a Bacura.

I've checked the transcode of the routine several times now, and it looks OK. What's unique about the Bacura though is that it's the only flying object that is double height (width). I'd suspect a placement issue with the sprite (as - unlike ground objects - there's no reference to where it should be) but I don't seem to have placement or hit box issues on double height ground objects! Weird...

Because my intention is to perfect the transcode in a single audit pass, rather than press on with the audit I'm going to persist until I solve this mystery.

jotd is still working on the Amiga port, but bogged down with palette limitations on the machine. He's also unable to trigger a bomb, which is a bit odd; although I haven't had issues I can't rule out a bug on my part just yet?!?

Transcode Audit Session #1

Tonight I started on the "audit" of the transcode. What I mean by this is a line-by-line review of the transcode, checking for:

• consistency between Z80 and 68K code
• consistency between Z80 and 68K annotations
• missing logic/code from 68K transcode
• micro-optmisations of 68K code

I'm only a very short way into the MAIN CPU program, but I've already been reminded of a few short-cuts I took in the transcode. Primarily, bulk initialisation (zeroing) of memory variables in a few places has not been transcoded. This is more likely to cause issues on subsequent games. And secondly, support for 2 players is completely untested, and possibly not completely implemented. For example, the code was not reading P2 inputs at all.

None of this is particularly problematic, but will take some time to implement and test in the process of completing the audit. Hopefully at the end of it I'll end up with less bugs than I have now rather than more!

Whilst I'm completing the audit, I'll probably set up the Amiga build toolchain and WinAUE and whatever else I need to be able to build and play the Amiga version - jotd is making good progress!

UPDATE: Session #2 - reorganised all the memory variables to be consistent with the original. This is necessary in order for the 'block' initialisation of memory areas to match up. A few isolated 'hack' initialisations I had made have now been removed. I also added (more) support for 2 player games - still WIP. Also fixed an erroneous annotation - makes more sense now.

UPDATE: Session #5 complete. Around 21% of the way through the MAIN CPU program, but there's a lot of data near the end so maybe actually ~25% of the way through the code? Most missing code has been for 2-player support, which I suspect is complete now (won't know for sure until the audit is done). I've also found & fixed a few subtle bugs along the way.

UPDATE: Session #6 complete. Verified pseudo random number routine (properly) - produces the same sequence as the Z80 routine. More annotations from Z80 RE and micro-optimisations.

Finished the first device (xvi_1.3p) of four (4) - so at least 25% of the way though the MAIN ROM.

Neo Geo implementation complete (transcode bugs aside)!!!

Sprite optimisation is - to the best of my knowledge - complete!

I had some time tonight to look at 2x2 tile sprite flipping, noticed that in my previous "shortcut" attempt I had made an error, fixed it... and it worked! I also verified that 1x2 sprites are never Y-flipped, so I don't need to handle this case (a similar strategy would have worked anyway).

Without going into detail, multi-level 'switch' statements have been avoided, as have look-up tables, with some convenient bit-wise operations. Quite neat in fact (and probably how the arcade hardware actually works). And the logic can likely be used in the Amiga implementation as well!

The Solvalou explosion is finally correct!

So this means that (sound aside) the Neo Geo implementation is now complete!

I will give it a final run, with a very close look at video quality, on the AES when I next get a chance.

Next task is a full audit of the RE & transcode - Z80 vs 68K - and fix the remaining few gameplay bugs in the process. This might take me a few weeks. Then I can finally dive into the Amiga implementation and try to learn a thing or two while I give jotd a hand to finish it off, before we work on the sound together.

This is taking a flipping long time!

Scant time again but have managed to do some more sprite optimisation.

Technically, there's plenty of time to update the shadow registers before the next VBLANK, but I don't like unneceessarily inefficient code. I've done some optimisation as far as the current functionality is concerned, and I'm happy with that code now. Aside from the code itself, all unused Neo Geo sprites should now be deactivated. I'm yet to see how the Andor Genesis looks now with the 96 sprite-per-scanline limit... there still may be some tweaking I can do in this regard...

The only functionality left now is to handle flipping of 1x2 and 2x2 sprites. I've tried a few shortcuts but none were successful. I might have to resort to look-up tables, which I'm not averse to. Again, it's not critical that it's as efficient as possible - just decent code.

I'm estimating that I can knock this over in just one more good long session... maybe eary next week.

Then it's the relatively lengthy and somewhat tedious transcode audit and bug-fixes.

jotd has been making more progress on the Amiga; hopefully he'll be able to share a video of the background scrolling properly soon!

When less sprites is more... good!

Just time for a quick 'n' dirty fix to the sprites, and already looking a lot better!

Each Xevious sprite has 2 Neo Geo sprites allocated, because the Xevious hardware can select double-width and double-height sprites. I thought I had coded the logic to deactivate the 2nd sprite for the (most common) 1x1 tile sprite case, but it turns out a bug meant it wasn't actually being deactivated. That explains why there were so many sprites hidden behind the display masks at the bottom of the screen!

To make matters worse, I wasn't directly deactivating unused sprites, but rather setting the coordinates in the object table and letting the subsequent logic handle the deactivation... which in hindsight probably wasn't sufficient. Regardless I now explicitly deactivate sprites in these cases.

As a result, the bottom of the screen is completely devoid of any unused sprites now.

This of course means there's more headroom before the 96 sprites-per-scanline limitation causes any issues. And I still have a trick up my sleeve if I need it...

When I do find the time, I'll go through the sprite shadow register update routine more closely and make some proper optimisations, and also add support for flipping 1x2 and 2x1 sprites.

[An aside: I think I just realised why the Bacura hit-box is off!]

Scrolling complete; only sprites to optimise now!

I'm happy enough with the scrolling on the Neo Geo now so I can move on. I could probably squeeze a few more cycles from the case where the scroll register is updated with a completely arbitrary value, (as opposed to scrolling the screen 1 pixel), but there's no point at all. In fact I had a bug in there which was benign because of the limited scenarios in which this case is executed; I almost didn't fix it (and maybe it's still not right?)

When testing on the AES it is difficult to ascertain whether or not the optimisations have made any difference to the video quality - as the sprites still need work - but it seems to me that there are actually less "sparklies" during the game and the video looks more stable. That could just be my imagination, but it's looking pretty good as-is.

The final piece of optimisation to do is the implementation of the Xevious sprites on the Neo Geo. Unused sprites are not properly deactivated and as a result affect the 96 sprite-per-scanline limit and I suspect also contribute to the "sparklies". And while I'm working on the sprite optimisations I also need to handle flipped double-width sprites properly.

I should note that the optimisations around the sprites are not specially for execution speed, as the core is idle now for between 67%-75% of the frame, and the code I will be optimising is updating the shadow copies of the sprite h/w registers in this period of the frame. So there is bucketloads of headroom on the Neo Geo; it's more about cleaning up the display and minimising the number of active sprites.

Once the sprites are done, that's it for the OSD (Nep Geo) layer (except sound).

I have a list of 8 "gameplay" bugs now; bugs that I would attribute to errors in the transcode of the core rather than the OSD (Neo Geo) layer. A few of them I should to be able to fix fairly quickly, a few others have me scratching my head. But they'll come after the above is complete (and before sound).

jotd has sent me a video of the core running on the Amiga with foreground, background and sprite layers at least partially implemented. It's pretty cool to see it running, and I have no doubt he'll be able to get it going pretty soon! He's also going to help out with the sound.

Scrolling optimisation WIP

Quick update. Didn't really have the time to spare to work on Xevious tonight, but I did anyway,

I have optimised the scrolling in the 2 cases where it scrolls down by 1 pixel (map row boundaries being the 2nd case) - ie. 99.99% of the time. I didn't get to test the final version on the AES yet, but I have tested an earlier version which wasn't quite right. It looks right on MAME, and I'm hoping that it is.

The remaining case, where the scroll register changes by an arbitrary amount (used when changing attract screens and starting areas), probably doesn't require any optimisation, but while I'm working on scrolling I will improve it a little anyway.

That will just leave the sprite optimisation before I go back and audit the transcode and fix the remaining gameplay bugs.

UPDATE: I've just checked the latest build on the AES - looks like I've fixed the scrolling and it's about as smooth as it's going to get. Still have a lot of sparklies on the screen, but that could easily be caused by my sprites which are yet to be optimised. I just need to round out the 3rd case for arbitrary positioning of the scroll register first...

UPDATE: An optimisation that I think will finally get rid of the 'sparkles' on the title screen when running on the AES... checking that the scroll reigster has actually changed before doing any scroll updates! A few minor optimisations in the calcs and branches, but I've actually broken it a little more. Hopefully next session I can sort it and scrolling will be done!