SDL_Flipping

I created a simple program that just renders and displays some images (using
a “function version” of my Noiser =D) and I ended up with a blank screen, no
matter what I did. It seems like SDL_Flip can be called ONLY with the
surface created with SDL_SetVideoMode. It took very long to be found out,
but I corrected it. Why there is no word about it in documentation?

Someone has to build a new chm version of documentation, the uploaded one is
pretty old.

What did you pass to SDL_Flip if not the surface returned by SDL_SetVideoMode?

In example a surface created with SDL_CreateRGBSurface, but it doesn’t work
AND SDL_Flip doesn’t show an error!

2009/6/12 Stefan Monov > What did you pass to SDL_Flip if not the surface returned by

SDL_SetVideoMode?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, of course it doesn’t work, what would it mean to flip an
offscreen surface?

But I agree attempting to do so should set an error.

For some reason, it seems that the last several months have had a few
people thinking that they might want to double buffer and offscreen
surface. The actual double-buffering API is available because
framebuffers have special abilities like connectivity to a video DAC,
larger-than-displayed-size framebuffer dimensions to allow you to
scroll around without a lot of blitting, and double buffering as a
relatively painless means to avoid showing incompletely rendered
visuals.

Note that the reason double buffering helps to avoid showing
incompletely rendered visuals is that your program cannot control the
passage of time, and therefore cannot control when the video DAC or
similar component wants to send a new picture to the display. Your
choices, then, are either to be careful not to draw anything unless
you’re sure you can finish drawing it before it gets sent to the
display, or to draw to a second frame buffer and only swap them when
you’re done drawing.

When you’re dealing with non-display buffers/surfaces, they are not
tied to any video DAC or any other real-time device that is going to
make demands on the readiness of your data, so you do not actually
need double buffering. If you find yourself thinking that you would
like to use double buffering on a non-frame buffer, perhaps your
programming model is a little funny, or you are do some expensive
image composition asynchronously, say in a secondary thread, or a VM
(which is still a second logical thread,) and you think “gee I sure
wish I could blit this surface to the screen and not get unfinished
garbage.”

I thought the conclusion everyone on the list came to was that if we
support in-software / emulated double buffering under any
circumstances, it might be easier on some progarmmers to make any
logical surface capable of double buffering. If that’s not the case,
though, it’s worth noting: it’s not very hard to do. Just use two
surfaces for any given surface, and when you “flip” them, just swap
their pointers. Make sure you do any locking that is necessary for
your program!On Sat, Jun 13, 2009 at 3:04 AM, Hubert Maraszek wrote:

In example a surface created with SDL_CreateRGBSurface, but it doesn’t work
AND SDL_Flip doesn’t show an error!


http://codebad.com/