Have you seen it yet? This took me two sessions to find, God knows how many hours.
The frustrating problem with this bug is that it caused memory to be corrupted elsewhere, memory that happened to be a part of the program. So the symptoms made no sense.
The game would crash after losing the first life, during setup for the next life. Once I'd found the place where the crash was happening, it was a routine that had already worked properly once. What was going wrong when it ran the second time?
After pausing the emulator just before the crash and opening the monitor to examine the memory, I could see that my code at that particular spot was now corrupt. But that corruption could have happened at any time after initialising the game. No clue as to the culprit.
I eventually started returning from the game at various points and using the monitor to check whether the corruption had happened yet. Eventually a pattern in the corruption itself gave a clue as to where it might be coming from. Even then, that loop looked fine. Often you see what you know should be there, rather than what actually is there.
Even if you've not spotted the problem, you may be asking why I needed to decrement X until beyond zero. Decrementing X or Y followed by a bne or beq (branch if equal to zero or not zero) is a very neat way to write a loop. This loop needs X to count down to and including zero. I guess it's possible to rearrange things a couple of different ways so that you can still use X=0 and not need a compare. But this is the dirty way that I wrote it at the time because I tend to just bash it out willy nilly and tidy up later*
I've now altered that loop so that it doesn't do that compare at all.
In case you haven't spotted it, cmp is a 'compare A' not a 'compare X'.
The loop copied a block of data into a table using X as an index. So with the bug in place, the loop wasn't finishing and after 0 it was writing spurious data into memory 255 bytes away, which happened to be in the middle of real game code.
Lessons learned: As well as taking the time to write more elegant code, I'll also be rearranging things so that all variables and tables are at the very end of my code. If a similar corruption or overflow happens, then it's likely to go into empty memory or into game data or tables. That will leave the game running and may yield more clues as to what's going wrong.
The game is going great now that it's back on track, thanks for asking.
* probably never tidy it up.
Comments
Post a Comment