Started to look at the invader bomb rendering code. The routine that renders a bomb also checks for collision with other objects; namely shields and player laser base. I decided to concentrate on the rendering for now and worry about collisions later.
Turns out what I had already coded was only missing a single instruction once I added the requisite bomb sprite data. But the invaders would drop a bomb, it would animate correctly for the 4 different frames in the table, then produce garbage. And then they'd stop dropping bombs. It was time to examine the logic beyond the rendering routine.
Ahh, "magic numbers". Not Tomohiro Nishikado's fault of course, but rather that of the person reverse-engineering the code, though perhaps Tomohiro doesn't get away completely unscathed because he does make an assumption about tables not spanning 256-byte boundaries.
In order to save space and time, several data structures store the LSB of the last entry in a table. And in several places, the code compares that value with a hard-coded value to determine if the end of a table has been reached. So when rotating the graphics data and hence shifting data structures throughout memory, those hard-coded values are invariably then incorrect. Oops. The fix of course was to use the label of the table and appropriate arithmetic to calculate the LSB at assembly time.
And as mentioned, in a couple of instances (other) tables were traversed and reset using arithmetic on the LSB only, which obviously worked for the original code as-is but again, after rotating graphics, some of those tables actually spanned a 256-byte boundary and things subsequently went haywire. Fortunately I have copious amounts of memory on the CoCo3 and aligning those tables was trouble-free.
Incidentally during this process I found a minor bug in my original transcode; I was only displaying 3 of the 4 frames of animation for the "squiggly" bomb.
Once all that was sorted, the bombs pretty much worked correctly. I say "pretty much" at this point because there do seem to be times when an inordinate number of "squiggly" bombs are being dropped, and no others. That doesn't appear to happen on the arcade game under MAME. So I need to do further testing on that.
 |
| Explosions are a bit messy, but bombs seem to work now! |
Now I mentioned that I hadn't taken any notice of the collision logic. So I was somewhat surpised when I was hit by an invader bomb and duly exploded! The shields are similarly damaged, though I haven't visited the explosion routine(s) yet; something I'd negelected to mention in previous posts. As you can see, they currently wreak havoc on the graphics below the laser base.
I'll probably tackle them next, before moving on to player lasers.
No comments:
Post a Comment