Ok, a 4th re-write of the API is in progress . . .
After some clever dancing with the last revisions to make Omega Fury animations work better, I have decided those enhancements have lost sight of one of its primary objectives: it is suppose to be a
programmer-friendly API. Manipulating bits throughout your game to make for optimizations is not my idea of programmer-friendly.
Implementations always shine a good light on how things should work. So, back to the drawing board I go! Actually, it is not all that bad. I already have a good draft in place. I have quite a bit coding to do before resuming its implementation in Omega Fury (and possibly re-integrating into Quikman as a differential to see how it stacks up against the original).
Here's my thoughts on what needs to be addressed:
1) No custom flip routine should be required for >8 active sprites. Thus, I got rid of the 8-bit on/off register, and made it into a SPRITE list instead, allowing for 1-16 active sprites.
2) SSSFLIP should have prior knowledge of whether an active sprite requires rendering and copy/merging into its character matrix. The game program should not have to manipulate for that to occur, or not to occur, such that each sprite's copy/merge process might be skipped if nothing new has happened to it.
3) Adding, removing, or changing a sprite on-the-fly should incur zero "glitches" as a result. While the original VIC-SSS does maintain image integrity, my recent enhancements introduced some complexity that made for some brief, but visible, graphical errors.
4) Maintain a sprite image buffer between frames to help avoid longer renders. Maintain image and buffer pointers per sprite to avoid unnecessary re-calculations.
5) The SSSFLIP routine should have the following modes:
Like before:
0 = immediate
1 = wait for next vertical sync to occur
>1 pace for that many vertical syncs (keeps frame rate steady)
But also, if >X vertical syncs occur, allow for a skip in the next frame flip to occur. This worked out pretty well for me in the later Omega Fury levels whereas the frame-skip allowed fast movement with four enemy ships (including the large carrier) -- most objects don't even lose their single-pixel movements, because they are moving at half-speed or less anyways. The player's ship can be seen moving double-pixels when flying at higher speeds, but it makes for a better playing experience if the action doesn't crawl.
I am also considering allowing for a mode that decides to split sprite rendering over two frames instead of all in one... alternating between even/odd frame updates.
