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?!?
UPDATE: Have to admit, the Bacura hit box issue is doing my head in. So I thought I'd post on my blog and hope for a Eureka moment?!? Hmm... waiting.... waiting....
Both the Solvalou and bullets have the same issue (different routines) so that would suggest a sprite placement issue. However there are 2 reasons this can't be the case: (a) the 2x2 sprites for ground-based objects are in the correct positions and (b) running the original Xevious and mine side-by-side shows the Bacura in exactly the same place at the same time. On mine, the Solvalou is destroyed by the 2nd Bacura on level 3, whilst on the original, it's destroyed by the 4th.
 |
| The Solvalou about to be destroyed by a Bacura that misses - and rightly so - on the original arcade game. |
At least the enemy placement is completely deterministic; starting a game from power-on before any demo can run will result in exactly the same sequence of enemies. This is because the pseudo-random number routine is never called outside a demo/game. This then means I can halt execution and inspect and compare values of the Bacura objects and sprite registers on both versions.
Fiddly but seemingly necessary now that I have no theory whatsoever...
UPDATE: Fixed the Bacura hit-box bug!!! 6 to go...
No comments:
Post a Comment