I’ve noticed after tooling through Sam’s Alien and Maelstrom
code that he always queue’s up all blits and does them in
one pull. in my immediate perspective i can’t quite figure
out why this is?
Is this a good design practice? Is there a performance benefit
to doing all the blits together (locking?).
I’m curious why Sam does it this way. Nothing obvious
is grabbing me.
Pete Shinners wrote:
I’ve noticed after tooling through Sam’s Alien and Maelstrom
code that he always queue’s up all blits and does them in
one pull. in my immediate perspective i can’t quite figure
out why this is?Is this a good design practice? Is there a performance benefit
to doing all the blits together (locking?).I’m curious why Sam does it this way. Nothing obvious
is grabbing me.
When I was porting digger to SDL I also queued blits for the purpose to
optimise screen updating - i.e. after all blits are queued I check the quieue
for the fully overlapping blits to decrese number of SDL_UpdateRect calls. Also
it helps to reduce the number of screen locking/unlocking, which could be
useful in the situation when locking/unlocking is expensive (probably remote
X11, however I’m not sure).
I donno why Sam did it, though ;).
-Maxim
I’ve noticed after tooling through Sam’s Alien and Maelstrom
code that he always queue’s up all blits and does them in
one pull. in my immediate perspective i can’t quite figure
out why this is?Is this a good design practice? Is there a performance benefit
to doing all the blits together (locking?).
If you must manipulate the pixels of hardware surfaces, then yes, it’s
an obvious benefit to avoid repeated locking. But often this isn’t needed.
You can gain some locality of reference anyway, and that’s always good.
Otherwise separating the presentation from the game logic can improve the
clarity of the program, and you might be observing that.
When I was porting digger to SDL I also queued blits for the purpose to
optimise screen updating - i.e. after all blits are queued I check the quieue
for the fully overlapping blits to decrese number of SDL_UpdateRect calls. Also
it helps to reduce the number of screen locking/unlocking, which could be
useful in the situation when locking/unlocking is expensive (probably remote
X11, however I’m not sure).
I donno why Sam did it, though ;).
Mostly so the updates happen all at once. If you don’t do this, then some
of the screen will be visibly updated separately from other portions of the
screen. Most of the time you don’t want this. 
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Mostly so the updates happen all at once. If you don’t do this, then some
of the screen will be visibly updated separately from other portions of the
screen. Most of the time you don’t want this.
I assumed he was referring to the blits themselves, not the update calls.
(Admittedly the latter is a no-op when drawing directly to the visible screen).
But doing the blits close together (and near the update) still improves
locality of course