Thread: Blitter queues
View Single Post
Old 09 August 2019, 11:18   #22
Registered User

Join Date: Jun 2016
Location: UK
Posts: 338
Originally Posted by deimos View Post
So, still build a queue, but add a macro at strategic places to test whether the blitter is available and process the head of the queue if it is?
That's not a bad strategy. Obviously it depends what system you are targeting, because that will determine how much work you can do between blits.

For example, if you are writing a game for the A500 you can try to interleave blits and enemy movement. If you time it right by the time you have figured out where the enemy needs to go and calculated all the values to poke into the blitter, the blitter will be finished with the previous one. You still need to poll in case you are running on a faster A1200, but at least you avoided wasting all those cycles on an interrupt.

Another down-side of interrupts is that it can be tricky to generate the queue as the blits are taking place. Imagine the blitter finishes and the interrupt sees the end of the queue so stops, but then after that another item is added to the queue. You need to either avoid that, or detect it and re-start the blitter.

The other issue with interrupts is that you have to make sure updates to your queue are atomic. The interrupt could trigger half way through an update to the queue, so there is a little bit of overhead to manage that. I'd avoid pausing interrupts during the update and just use some kind of counter that can be written atomically.

One other way to do it is with a copper list that is effectively the blit queue. You really need to be one frame behind for that to work though, but maybe that doesn't matter for things like enemy bobs.
zero is offline  
Page generated in 0.04140 seconds with 11 queries