OGL and SDL

If you use OGL with SDL, does SDL functionally take place of GLUT? Also
what about GUI’s when running OGL with SDL? Do GUI’s that use the standard
SDL blitting calls work in a program using OGL? Or does a whole new one
need to be written up?

-Garrett, http://www.wpi.edu/~mongoose/
“Do not go where the path may lead, go instead where there is no path and
leave a trail.”
-Ralph Waldo Emerson

Garrett Banuk wrote:

    If you use OGL with SDL, does SDL functionally take place of GLUT? Also

what about GUI’s when running OGL with SDL? Do GUI’s that use the standard
SDL blitting calls work in a program using OGL? Or does a whole new one
need to be written up?

Yes, SDL takes the place of GLUT. Unfortunately, OpenGL completely takes
over the video subsystem, so you can’t use normal SDL blitting functions
to draw on an OpenGL display. I believe someone is currently working on
an OpenGL target for SDL, but I’m not sure of its status.

-John

Garrett Banuk wrote:

    If you use OGL with SDL, does SDL functionally take place of GLUT? Also

what about GUI’s when running OGL with SDL? Do GUI’s that use the standard
SDL blitting calls work in a program using OGL? Or does a whole new one
need to be written up?

There are two possibilities for using OpenGL and SDL. The first one is
using SDL for context creation and input and … (a la GLUT) by
specifying SDL_OPENGL as a flag to SetVideoMode and the second one is to
allow blitting of SDL surfaces to the OpenGL context by specifying
SDL_OPENGLBLIT (which includes SDL_OPENGL).

As the first one is already documented (or at least sort of) I’ll sum up
the second one again.

When you specify SDL_OPENGLBLIT, SDL internally creates one 256x256
texture and a shadow surface for blitting. If you requested a 16 bit
color depth the shadow surface will be RGB565 and AGBR8888 (standard
OpenGL GL_RGBA, GL_UNSIGNED_BYTE) otherwise. You can now blit to this
surface like to a normal SDL surface (which it actually is) and get
access to it directly (this is NOT the framebuffer). When you call
SDL_UpdateRects SDL will blit this surface to the screen bypassing any
stencil, alpha, depth, … tests.

Keep in mind that you have to call SDL_GL_SwapBuffers() to see the
effects :wink:

As SDL_UpdateRects has to do some expensive state changes you most
likely want to use SDL_GL_Lock/Unlock (reference counted) in combination
with SDL_GL_UpdateRects if you want to call it multiple times in a row.
Offhand I can’t think of such a case, but well, as the lock/unlock calls
are ref counted it is possible and faster (if you call it in a row). The
real reason I made it accessible is that you can modify the state used
internally for the SDL blit. So if you don’t want the stencil test to be
disabled simply call SDL_GL_Lock, set your state, blit and then call
SDL_GL_Unlock.

This needs some better documentation but I don’t have the time to do so
(and maybe not the skills in writing good documentation ;-)). So if
anyone wants to document it more and has problems figuring out what it
does or how to use it -> feel free to contact me directly.

BTW, the 16 bit implementation of SDL_OPENGLBLIT relies on OpenGL 1.2s
packed pixel stuff. It was broken in Utah-GLX with indirect rendering
until recently (get latest CVS) and still seems to be broken in DRI with
indirect rendering.–
Daniel Vogel
Programmer
Loki Entertainment Software

If you use OGL with SDL, does SDL functionally take place of GLUT? Also
what about GUI’s when running OGL with SDL? Do GUI’s that use the standard
SDL blitting calls work in a program using OGL? Or does a whole new one
need to be written up? Sorry if this is the second time I’m sending this, I
don’t think I was subscribed to the list when I sent this before.

-Garrett, http://www.wpi.edu/~mongoose/
“Do not go where the path may lead, go instead where there is no path and
leave a trail.”
-Ralph Waldo Emerson