[SDL] pixels vs blit
emulynx at delfi.lv
Mon Jan 20 03:41:00 PST 2003
Nick Whitelegg wrote:
> The way I have solved this is rather convoluted internally but clean at
> the level of my ZXLIB API. I also have an Arena class which essentially
This solution does not seem terribly convoluted to me. You've just
added a few layers of indrection, that's all. You could probably hide
all this behind a function call, perhaps a protected method called
GetRect(), which contains a line like:
where pArena is a pointer to the arena object and hMyRect is the handle
to this Sprite object's rectangle. If the array of rectangles never
moves in memory and is also therefore never resized, you could remove
one layer of indirection by having Arena::GetRect() return a pointer to
the SDL_Rect instance within its internal array, which each Sprite could
maintain a pointer to.
The queue idea mentioned by another poster also makes sense. In that
case, Sprite::GetRect() could look like:
which would return the next free rectangle in the queue. Then you'd
call pArena->UpdateRect(pRect) to mark it as changed, so that it gets
blitted on the next screen update.
> The alternative way I can think of, which would be simpler internally,
> would be to store an array of Sprites inside the Arena, each containing
> its own update SDL_Rect. However, as I said, this would not permit the use
> of SDL_UpdateRects().
Not so. It would merely mean that Array would have to traverse the list
of Sprites, find out how many rectangles there are that need updating,
collect them into a single array of SDL_Rects, and send that to
SDL_UpdateRects(). This would be moderately expensive, but it shouldn't
entirely eat away your 120% speed gain.
More information about the SDL