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.)
- and as for scaleing, i was looking at the Hermes source and at the
scaleing code in it, and i was wondering if it would be
posible/aceptable to integrate it to sdl and implement it in the
following way:
-eather add a function SDL_SetVideoMode_Scale with the extra option of
the scale, or add flag’s for scaleing such as SDL_SCALE2X (which method
would be preferable?)
-set it up so when you do an SDL_Flip it would automaticly scale it so
the programs code doesnt change at all except in the seting of the video
mode, and the program doesnt have to wory about scaleing and it can be
added to prity much any SDL program really easily. im thinking this
would not work with some of the combinations of options i asked about in
- which is why im asking
Is there any reason to explicitly ask for 2X scaling? Wouldn’t it make
sense just to switch the monitor to the requested mode?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
