Had a bit of spare time so I started on the optimisation tonight. The focus was the sprite print routine, though from all reports that's actually not one of the hotter spots in the code. Regardless, I managed to find a few cycles here and there which equated to roughly one frame-per-second improvement on a busier screen - instead of 5/6 it's now 6/7 fps.
Nothing too tricky; found a PSHS/PULS inside a loop that was completely unnecessary, pre-computed an LEAX outside a loop, used post-increment to remove an LEAU, and finally moved a few temporary variables from the stack to the direct page.
Also found a bug in the process, but one that doesn't appear to affect the code - a word-sized variable on the direct page was only allocated a single byte, and AFAICT wasn't used at the same time as the next variable.
Next step is to locate and review my correspondence with fellow porters to identify the critical areas I should be looking at!
If you get it equal to (or slightly better than) the speed of the original, then it's pretty good. What's the fps on the busy screens on the original?
ReplyDeleteI'm aiming for slightly better - I don't see any point in having it run much faster as it will change the gameplay (and likely make it too difficult).
ReplyDeleteI'm not sure what the fps range is for the original, and I don't really know of any easy way to measure it other than patch it to add profiling code... and/or patch an emulator...