I am developing a windowed OpenGL application that I’ve recently ported
from GLUT to SDL so I can take advantage of portable threads, SDL_Net,
etc. I’ve run into a little hitch in resizing the window–namely, all
OpenGL state is lost as soon as I call SDL_SetVideoMode(). Yes, I know
this has been discussed before–and I know that changing the pixel
format of an OpenGL rendering context on Win32 requires resetting
OpenGL–but simply changing the dimensions of the viewport shouldn’t (it
didn’t under GLUT, anyhow).
So I guess what I’m asking is, can I just resize the current SDL surface
without having to ditch it and create a new one? I mean, without
resorting to the nasty trickery shown below…
case SDL_VIDEORESIZE:
#ifdef WIN32
{
// Holy cow, this is evil. But it seemed to do the trick.
SDL_Surface *surface = SDL_GetVideoSurface();
surface->w = event.resize.w;
surface->h = event.resize.h;
}
#else
SDL_SetVideoMode(event.resize.w, event.resize.h, 0, SDL_OPENGL
| SDL_RESIZABLE);
#endif
glViewport(0, 0, (GLsizei) event.resize.w, (GLsizei) event.resize.h);
Windows requires you to nuke and reinitialize OpenGL if the pixel format
changes, which happens when the framebuffer bit depth changes. Currently,
SDL simply always resets OpenGL on any SDL_SetVideoMode call in Win32,
which is overkill but consistent enough to work around.
I have code that avoids this in some cases, and sends an SDL message if
it actually had to reset the context, so you can call SDL_SetVideoMode,
and then peep at the message queue to see if you lost the context (which
you shouldn’t, if you’re just resizing). I’ll be sending it here once
it’s had more testing, but you can pull it out of the CVS tree of
StepMania at http://www.sf.net/projects/stepmania/ (under
stepmania/src/SDL-1.2.5/) if you want.On Fri, Apr 11, 2003 at 08:57:00PM -0600, news.gmane.org wrote:
I am developing a windowed OpenGL application that I’ve recently ported
from GLUT to SDL so I can take advantage of portable threads, SDL_Net,
etc. I’ve run into a little hitch in resizing the window–namely, all
OpenGL state is lost as soon as I call SDL_SetVideoMode(). Yes, I know
this has been discussed before–and I know that changing the pixel
format of an OpenGL rendering context on Win32 requires resetting
OpenGL–but simply changing the dimensions of the viewport shouldn’t (it
didn’t under GLUT, anyhow).
–
Glenn Maynard
Windows requires you to nuke and reinitialize OpenGL if the pixel format
changes, which happens when the framebuffer bit depth changes. Currently,
SDL simply always resets OpenGL on any SDL_SetVideoMode call in Win32,
which is overkill but consistent enough to work around.
My question is, why is there a need to call call SDL_SetVideoMode() at
all when an OpenGL window is resized (i.e., by the user dragging the
window borders)? The OS already resized the window; the SDL_Surface is
just a skeleton–pixels is NULL and hwdata (in my experience) is NULL as
well; glViewport() takes care of drawing in the new window correctly.
The only thing that doesn’t work, as far as I’ve seen, is that mouse
coordinates are bounded by the prior dimensions of the window. I fixed
this in my Win32 build by setting w and h myself. So why not just have
an SDL_GL_ResizeWindow (or something like that) that takes care of this
common case and promises not to clobber the OpenGL state?
Please set a real name in your From field; I like talking to people, not
hostnames.On Sun, Apr 13, 2003 at 03:58:13PM -0600, news.gmane.org wrote:
My question is, why is there a need to call call SDL_SetVideoMode() at
all when an OpenGL window is resized (i.e., by the user dragging the
window borders)? The OS already resized the window; the SDL_Surface is
just a skeleton–pixels is NULL and hwdata (in my experience) is NULL as
well; glViewport() takes care of drawing in the new window correctly.
The only thing that doesn’t work, as far as I’ve seen, is that mouse
coordinates are bounded by the prior dimensions of the window. I fixed
this in my Win32 build by setting w and h myself. So why not just have
an SDL_GL_ResizeWindow (or something like that) that takes care of this
common case and promises not to clobber the OpenGL state?
That’d change the SDL API in a way that would break backwards compatibility,
which I don’t think Sam is going to even consider.
And the patch to handle OpenGL context resets is needed anyway, since
it’s unacceptable to spend 20 seconds reloading textures just because
the user changed to fullscreen; so having a separate call for changing
only the resolution is just unneeded API bloat.
–
Glenn Maynard
Please set a real name in your From field; I like talking to people, not
hostnames.
Whoops, looks like Mozilla stuck the group name there by default. 
(I’m using the mailing list through news.gmane.org)
That’d change the SDL API in a way that would break backwards compatibility,
which I don’t think Sam is going to even consider.
Why would that break backward compatiblity? Apps can continue calling
SDL_SetVideoMode() and possibly losing their OpenGL state. It would
just provide a shortcut for apps that want resizable SDL_OPENGL windows
and don’t want to worry about possibly losing their state.
I concede that I don’t know whether it’s possible to implement on all
platforms, though, so your solution does seem more robust.