visible-screen sprite updating.
Looking at what I want the screen to be able to do, there is a problem with trying to update sprites. There's just no time left in the hblank. A sane person would just say "Ok, let's just pull out the playfield color update. All you need is that one extra command in there."
But I don't wanna. 
So if you can't do the update in hblank. You'd have to do it during the visible screen. The obvious problems with this would be what if you try updating it when it's being displayed? Are you displaying the right line of graphics depending on if the sprite comes before or after the sta GRP0/GRP1? With P0 and P1 to consider, both which can be displayed anywhere on the screen, the potential headache increases.
But then, these concerns -can- be determined prior to drawing the screen. So what do we need? A way to vary where on the screen we're going to do the update of the sprite so that we know it won't corrupt either P0 or P1. See what I mean about ugly code?
Yeah all because I insist on trying to keep that silly sta COLUPF in there. 
I'll be mightily impressed with myself if I can pull this off. 
*update*
I don't know what to think of this. In way of checking the timing, I tried cramming everything I could into the most complex scenario I could think of. (Playfield Color & Data Change, Player Turn On/Off, Sprite Graphic Update) and it -just- fit in a constant 76 cycles. But there's no real room to have multiple trigger points for the sprite drawing during the visible dislpay.
While typing this however I thought up something else that might be useful to enable me to actually get hblank sprite updates. It comes with a tradeoff of having the player's look change slightly on scanlines where this condition occurs, but that's not really a Bad Thing. Getting too tired to attempt it right now tho, so going to leave a note in my code to pick up tomorrow.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
3 Comments
Recommended Comments