[SDL] Scaleing, SDL_DOUBLEBUF, SetVidMode, etc.....

Mattias.Blomqvist at nokia.com Mattias.Blomqvist at nokia.com
Fri Apr 14 01:20:09 PDT 2000


This explanation was very nice. Thanks Sam. I do have some additional
questions though.

1) What are the requirements to actually get a hw surface when you ask for
it? I presume you cannot get it under X11? If so what should be used
instead?

2) Is there any other restrictions on dubblebuffering than the fact that
there have to be enough free videomemory? If so, what are the restrictions?

Thanks in advance
Mattias Blomqvist

> -----Original Message-----
> From: EXT Sam Lantinga [mailto:slouken at devolution.com]
> Sent: 14. April 2000 9:33
> To: sdl at lokigames.com
> Subject: Re: [SDL] Scaleing, SDL_DOUBLEBUF, SetVidMode, etc.....
> 
> 
> I think I'll add this to the FAQ.
> 
> > 1)could someone please explain to me how exactly SDL_Flip,
> > SDL_SetVidMode and SDL_UpdateRect work with and without 
> SDL_DOUBLEBUFF,
> > SDL_HWSURFACE and SDL_SWSURFACE (in terms of where the pixel data is
> > being written and how it gets to the screan)
> 
> If you request SDL_SWSURFACE, then you get a video buffer allocated in
> system memory, and you must call SDL_UpdateRects() or 
> SDL_Flip() to update
> the screen.  SDL_Flip() calls 
> SDL_UpdateRects(the-whole-screen) in this
> case.  All allocated surfaces will be in system memory for blit speed.
> 
> If you request SDL_HWSURFACE, then if possible SDL will give 
> you access
> to the actual video memory being displayed to the screen.  If this is
> successful, the returned surface will have the SDL_HWSURFACE flag set,
> and you will be able to allocate other surfaces in video memory, which
> presumably can be blitted very fast.  The disadvantage is that video
> memory tends to be much slower than system memory, so you don't want
> to write directly to it in most cases.  In this case, 
> SDL_UpdateRects()
> and SDL_Flip() are inexpensive noops, as you are writing to memory
> automatically being displayed.
> 
> If you request SDL_HWSURFACE, you may also request double-buffering
> by adding the SDL_DOUBLEBUF flag.  If possible, SDL will set up two
> buffers in video memory for double-buffered page flipping.  If this
> is successfully set up, then you will be writing to the non-visible
> back-buffer, and when you call SDL_Flip(), SDL will queue up a page
> flip for the next vertical retrace, so that the current video surface
> will then be displayed, and the front and back video buffers will be
> swapped.  The next display surface lock will block until the flip has
> completed.
> 
> You should always check to see if you need to lock a surface before
> accessing the pixels.  A lock is necessary when the 
> SDL_MUSTLOCK(surface)
> macro evaluates to true.  You should never assume that you can blindly
> write to a video surface without locking it, otherwise your code will
> work on some platforms and video drivers, but not others (and 
> it's tough
> to debug in the fullscreen modes in which this often matters.)
> 
> See ya!
> 	-Sam Lantinga, Lead Programmer, Loki Entertainment Software
> 



More information about the SDL mailing list