[SDL] pixels vs blit

Anatoly R. 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:

	pArena->GetRect(hMyRect);

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:

	pArena->GetARect();

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 mailing list