Very brief update.
After five days away from the keyboard I decided there was only one possible reason for the erase ship routine not working... and I was right! Because I cut-and-paste the render routine and used it for the erase by replacing the video writes with CLR, it simply wasn't possible for it to fail. And it wasn't actually failing at all - I simply wasn't calling it!
I have a jump table for the (tokenised) DVG commands, and for the previous iteration without any constant offsets, the ship was erased (for now) by a call to the generic erase_chr routine, since the ship is no larger than a character. So when I added new code to the render_ship routine that moved it...
Right now I'm where I was at with the IIGS version, with the exploding ship graphics as well. In short, all the rendering is done - it's just not done at exactly the right position on the screen. The shots are coming out near the nose of the ship, but it's still offset by a pixel or two in some orientations. Why is a complete mystery to me, as both the ship and shot appear to have a constant offset applied to them.
Most of the asteroid hits seem spot-on too, but occasionally I've seen a shot pass right through the middle of a saucer.
I was hoping things would "just work" with the scaling sorted but it appears there's something still amiss. I just hope it's not buried in the Atari display list code, because that's all Greek to me...
I'm tempted to forge ahead with the Coco3 optimisations at this point, but something is nagging at me to get it exactly right this time before moving on. At least once all the offsets are deduced and coded I can back-port to any Apple version(s)!
Off by one pixel might simply be a rounding issue when scaling coordinates. If shot appears at position+offset1 and ship appears at position+offset2 but the sum of one rounds up and the sum of the other rounds down there'll be a mismatch. Off by two pixels might be a compound mismatch because predrawn sprites have integer pixel positions and actual end-points might have rounded differently if it were computed on the fly.
ReplyDeleteThanks Sock! Would normally agree, but I'm using the same scaling algorithms and bitmaps as Norbert's emulator, AFAICT, and he doesn't appear to have this issue. However I'll need to confirm it all (again) of course!
Delete