Interesting to go back and read my blog posts from the beginning! So much that I'd forgotten about, and quite obviously a scary amount of hours put into retro ports thus far. Doesn't seem like I have a lot to show for it though... 😒
I didn't read them all today, but I will have to go back and read all my entries for Donkey Kong when the time comes. If the Lode Runner and Knight Lore posts are anything to go by, it will go a long way towards reminding me of what I've done and how I've done it. No doubt I get a lot more out of my own blogs than anyone else reading them...
So back to Xevious today and I finally removed the dependencies on the Neo Geo layer in the main code. All the hit-box calculations are done using the sprite shadow register values which are - for efficiency reasons - in OSD (Neo Geo) format. In order to finish the transcode ASAP, I simply left it that way, with a note to revisit it when it was time to optimise.
All the hit-box calculations use the 8 most significant bits of the X/Y register. On the original hardware, the most significant bit of the X register had to be rotated in via the carry to produce X[8:1] every time it was referenced in a hit-box calculation. On the Neo Geo, X had to be shifted down by 8 bits, while Y had to be shifted down by 7 bits. Neither solution is optimal, so I opted to create another (platform-agnostic) copy of the X/Y register values exclusively for hit-box calculations (I already had to create a 2nd copy of X a while back to handle 2x2-tile sprites anyway).
Since this is done as the last operation in the SUB CPU main loop before spinning waiting on VBLANK, timing isn't critical. This also had the added bonus of simplifying the 68K code whenever they were referenced, as I combined the previously separate X&Y values into a single array, and eliminated the need to do word operations or any pre-shifting.
It should also allow other platforms (Amiga) to start implementing sprites now.
Now I can focus solely on getting the Neo Geo port to run at 100% with no disappearing sprites. The few remaining bugs will sort themselves eventually. I haven't actually profiled any of the code yet, but I do know the critical sections will be scrolling and sprite h/w updates, as they're both done during VBLANK. Scrolling is currently horrendously inefficient, so I'm hoping for big gains there.
Foreground and background access routines are pretty horrid as well - and they disable interrupts whilst executing by necessity - but there's not a lot of that happening during the game. So I'm not sure how much can be done there.
For disappearing sprites (96 per scanline limitation) I've thought a little about how I can mitigate that; by ensuring that unused sprites are inactive (in the Neo Geo h/w) and also turning off some foreground sprites that aren't used during gameplay.
No comments:
Post a Comment