I think I've just doubled the number of posts from last year in just 2 days this year!?!
At lunchtime today I continued where I left off last night. A few red herrings along the way but I've managed to identify a couple of issues that explain the crashes, and even fix one of them.
The game determines whether or not the invaders have reached the left/right side of the screen by simply examing video memory at either extreme of the display, depending on the current direction of the so-called "rack" movement. Any set pixel on the extremity will cause the invaders to reverse direction and drop down (8 pixels) on the screen.
Because the screen is now rotated the video memory addresses of the left/right sides have changed, and it just so happens that the areas in question now both contain pixels. So the logic was reversing the direction and dropping down the invaders every frame, which quickly crashed the game.
This wasn't apparent to me though, because I didn't see the invaders move at all. That's because there was a bug in the algorithm for calculating the invader video memory address; it worked for 'byte-aligned' sprites (as they all are when first drawn) but for non-aligned sprites it stamped all over memory. And that in itself made things even more difficult to debug because the behaviour wasn't always the same.
I've temporarily disabled the 'edge of screen' detection logic so at least I can see the invaders march across the screen. I've debugged - or at least improved - the sprite video memory address calculation routine so the invaders (and incidentally, the player base) appear at roughly the correct location on the display. However it has also become apparent that I need to further 'improve' the routine for rendering a non-aligned sprite, but that's not too surprising given the bugs I've just found.
That aside, the game is running; invaders are marching and dropping bombs and you can move your base left/right. Firing your laser, however, crashes the game. Again, not surprising.
I am happy with the progress and although the rotation is perhaps a little more complex than I originally thought (or recall thinking), I don't think there's much more to be done other than debug and a few extra patches here & there (like edge-detect, which upon reflection is going to run a lot slower than the original). Although I still have graphics data that needs to be rotated.
FWIW my CoCo3 source code can be built either rotated, or not, with a single .define.
Oh and one last thing that I'm a little embarrassed to mention. For years I've been documenting how to run/debug these little projects in various places because I invarably forgot how (MAME command-line options, etc). Only last night it actually occurred to me that I could add various (new) targets to the makefile and have it launch MAME... 😳
No comments:
Post a Comment