[SDL] UpdateRects sketchy

paul at theV.net paul at theV.net
Sun Sep 15 06:10:01 PDT 2002


On Sun, Sep 15, 2002 at 09:39:00AM +0100, Nick Whitelegg wrote:
> 
> Is this always the best solution though? I haven't got round to
> experimenting, but say you had a 2D game where there were a number of
> moving sprites plus various (occasionally only updated) status info like
> score and lives. What I tend to do (e.g. for my ZXLIB C++ game library) -
> and, like I said,
> I haven't tested this yet - is use UpdateRects() for the sprites (as they
> move each time) but, for the scores, just blit them and update them as
> needed as they are only occasionally updated. Otherwise (I'm using the STL
> vector container to store my update rects) I'd have to add in the score
> update rectangle to the list of update rectangles each time I want to
> update it, do the updating with UpdateRects(), then remove the score
> update rectangle from the list of "dirty" rects. At a guess, this seems
> slower but I may be wrong?

Depending on your application and your algorithm, the use of 
dirty rectangles can be faster or slower. You mileage will
always vary. Just for you reference, I have a general purpose
dirty rectangle implementation at

	http://www.gime.org/twiki/bin/view/Gime/WebDownload

There is always a tradeoff of using dirty rectangles, but the 
key is not to update (or even redraw) your whole screen surface
by all means, unless you are using hardware surface. If you 
don't have too much stuff changing on screen EVERY frame, dirty
rectangles definitely helps.
 
> This (aka SDL_Flip() I presume) seems to be extraordinarily slow on my
> system (X3.3.6, 16bpp display, SDL1.2.1, windowed, software surface) -
> don't know why. 

AFAIK, SDL does not support hardware surface with X11, therefore, 
SDL_Flip() is not going to do you any good since the screen surface
you get is only software surface that resides in main memory. In
this case, SDL_Flip() is equal to SDL_UpdateRect(screen, 0, 0, 0, 0)

Regards,
.paul.




More information about the SDL mailing list