SDL probably doesn’t specify this, and probably nor does the opengl standard,
but, can I say anything about the opengl buffer state between calls to
SDL_GL_SwapBuffers?
I’m trying to get vbl syncing in some SDL code (1.2.11), and instead of
changing all my sprite drawing code to use textures, I instead
made the conservative update/dirty region code draw using
textures, with no call to glClear. This worked ok for a few implementations,
however on others it looks like there are two opengl buffers to which
I draw, which of course doesn’t work with conservative redraws.
Is there any SDL way of asking for only 1 buffer?
RF–
felix: lightweight threads, HOFs and game scripting.
svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix
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.
All modern hardware expects this, it’s cleaner to code, and in some
cases, it can be faster, since the GL knows it can discard some previous
state.
Also, it’s the only way you’ll get hardware supported sync-to-vblank.
–ryan.
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.
RF.> From: “Ryan C. Gordon”
–
felix: lightweight threads, HOFs and game scripting.
svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix
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.
If this is fast enough, why would you need to change to full opengl?On Saturday 31 March 2007, Rhythmic Fistman wrote:
From: “Ryan C. Gordon”
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> From: Sami N??t?nen <sn.ml at bayminer.com>
On Saturday 31 March 2007, Rhythmic Fistman wrote:
From: “Ryan C. Gordon”
–
felix: lightweight threads, HOFs and game scripting.
svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix