[SDL] opengl buffer state

[Rhythmic Fistman]

> From: Sami N??t?nen <sn.ml at bayminer.com>
>
> On Saturday 31 March 2007, Rhythmic Fistman wrote:
> > > From: "Ryan C. Gordon" <icculus at icculus.org>
> > >
> > > > Is there any SDL way of asking for only 1 buffer?
> > >
> > > SDL_GL_SetAttribute() can be used to select double/single
> > > buffering, but in OpenGL, you really don't want to do a dirty
> > > rectangle thing...clear the color buffer every frame, redraw the
> > > whole scene and swap buffers.
> >
> > Thanks, SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 0) does the trick,
> > in the sense that the resulting image is complete. I didn't actually
> > want opengl, I just wanted vbl syncing, hence this experiment, which
> > was a failure: there's still tearing, and the image suffers the
> > positioning bug of the other mail.
> >
> > Not sure what to do, I don't really want to translate all the sprite
> > drawing code to opengl, it's a bit of a pain as there's a stack of
> > bit fiddling.
>
> You don't need to change everything. Just blit like you would normally
> do, but blit to SDL Surface you created yourself. Then upload that
> Surface to texture and draw one textured quad with opengl.

I didn't change everything, I changed the final stage of the dirty rect
code to draw using gl textures. That means for every frame you upload
all new textures and immediately draw them. It was too slow, the GLified
dirty rect code gave a variable frame rate that would occasionally drop to
15fps which tends to look a lot like tearing. I tried your suggestion of
using just one textured quad and got an improvement, sort of:  a constant 15fps.

Interestingly, once I converted the dirty rect code to gl I could work
around the
non-centred osx/sdl1.2.12 gl bug by choosing a natural resolution then scaling
the output. HOWEVER if you scale up linearly (GL_LINEAR) you can *see*/intuit
the dirty rects from the not-quite-right anti-aliasing boundary
conditions, even if you use GL_CLAMP_TO_EDGE. You have to use
GL_NEAREST. Weird.

> If this is fast enough, why would you need to change to full opengl?

That wasn't fast enough - passing to full opengl would get rid of the
texture upload
bottleneck, you could upload all the textures just once, then draw
them real fast.
Anyway, speed wasn't the (original) problem - I just wanted some portable "vbl"
syncing. Someone on the list said the only hope for that was using SDL_OPENGL,
however I noticed that the SDL_Flip manpage claims that in combination
SDL_DOUBLEBUF you can get "vbl" syncing. This almost works on my
macbook which with its lcd screen has no vbl to speak of. In this case the
SDL/quartz video code assumes a constant refresh rate of 60Hz. With a hacked
SDL 1.2.12 I found that 63.9Hz worked much better. I don't know if anyone's
interested in making such a thing configurable. It's a bit of binary search pain
in the hole finding that number, and not the sort of thing you'd like
to pass on to the user, especially if they're prone to epilepsy.
Anyway, off to try SDL_DOUBLEBUF under windows.

Fanks,
RF

-- 
felix: lightweight threads, HOFs and game scripting.
svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix