Wow, that would have to be the most frustrating part of the transcode so far! What should have been relatively straightforward - implementation of the Xevious sprites on the Neo Geo (a bloody great sprite engine itself) - resulted in no less than 3 days of banging my head against a brick wall!
There were plenty of red herrings along the way, including 'corrupt' sprites that were actually the result of the VBLANK interrupt routine taking way too long to execute and updating VRAM whilst the display is active. I thought it was the sprite routines writing to the wrong addresses in VRAM and corrupting the background layer. Numerous other little bugs but one after the other, I fixed them and the problem remained. I was getting ready to give up...
And then I discovered a cut 'n' paste error which meant I was writing to the wrong area of VRAM when updating the sprite X coordinates. Not corrupting the background layer though, but rather corrupting the Y coordinates of the sprites themselves. I must have checked that line of code a dozen times, and never saw it!!! 😫
Anyway, much relief now to have finally found the problem.
 |
| The sparkle on the logo is a Xevious sprite |
Now I can look at tidying up the sprite code; removing the debug code and making it more efficient.
It's not entirely finished as I need to add support for double height and/or width sprites, which will be fairly trivial on the Neo Geo. But for now, as they're seldom used, I'll press ahead and start transcoding the SUB CPU routines that parse the object table for the map and create/place the sprites for the ground-based objects. Actually, first I'll add the Solvalou, and get that moving around the screen!
It's another big milestone as this means the OSD layer (and its interface) is all-but-complete, allowing me to transcode the vast majority of the game now without having any more technical challenges on the Neo Geo. Almost to the point of cranking the handle now... almost!
No comments:
Post a Comment