(cross-posted to scitech.gldirect and SDL newsgroup)
Scitech’s GLDirect is a pretty cool technology that
translates OpenGL calls to Direct3D calls and gives
much better performance for video cards whose OpenGL
drivers work poorly or not at all.
I have noticed an interaction between SDL’s OpenGL
context and the GLDirect driver wherein an SDL_SetVideoMode()
seems to cause a lot of information to disappear and thus
in the reshape() function which gets called to do resizes,
not only does the viewport and frustum need to be reset (which
is traditionally all you’re expected to do), but stuff such
as texture parameter initialization and it seems, display
lists and materials as well.
This is clearly unwieldy and incorrect behaviour, and probably
points to a bug in either in the GLDirect driver or the SDL
SDL_SetVideoMode() call, which one I’m not sure.
Note that resizing the window will cause its
contents to disappear. I was able to ‘fix’ the problem
by replicating the glLight(), glEnable, gl***List(),
and glMaterial() calls in init() inside reshape().
However, this should clearly be unnecessary.
In a pygame demo program I made myself, something similar
occurred, and in that case, it involved glTex***() functions
which again needed to be put in the ‘reshape’ function.
Testing under software Mesa on Linux did not result in
the problem and I think it probably does not occur with
drivers besides GLDirect or else we’d probably have heard
about it by now.__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
(cross-posted to scitech.gldirect and SDL newsgroup)
Scitech’s GLDirect is a pretty cool technology that
translates OpenGL calls to Direct3D calls and gives
much better performance for video cards whose OpenGL
drivers work poorly or not at all.
I have noticed an interaction between SDL’s OpenGL
context and the GLDirect driver wherein an SDL_SetVideoMode()
seems to cause a lot of information to disappear and thus
in the reshape() function which gets called to do resizes,
not only does the viewport and frustum need to be reset (which
is traditionally all you’re expected to do), but stuff such
as texture parameter initialization and it seems, display
lists and materials as well.
This is clearly unwieldy and incorrect behaviour, and probably
points to a bug in either in the GLDirect driver or the SDL
SDL_SetVideoMode() call, which one I’m not sure.
Note that resizing the window will cause its
contents to disappear. I was able to ‘fix’ the problem
by replicating the glLight(), glEnable, gl***List(),
and glMaterial() calls in init() inside reshape().
However, this should clearly be unnecessary.
In a pygame demo program I made myself, something similar
occurred, and in that case, it involved glTex***() functions
which again needed to be put in the ‘reshape’ function.
Testing under software Mesa on Linux did not result in
the problem and I think it probably does not occur with
drivers besides GLDirect or else we’d probably have heard
about it by now.
Actually, we have heard about it off and on for years. On windows, when
you do things like resize, you lose your entire GL context. This is well
documented and has been discussed to death on the list. Yes, it is
absurd and all the other negative things you said about it. But, that is
the way MS chose to make OpenGL work on Windows. Turns out the OpenGL
standard allows this behavior (or so we have been told). And yes, you
won’t run into this behavior in OpenGL on any Linux/UNIX platform.
If you want this corrected you should complain to Microsoft. Won’t do
you any good. But, it does feel good to complain.
Bob PendletonOn Tue, 2004-11-02 at 09:45, Jonathan Perez wrote:
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Actually, we have heard about it off and on for years. On windows,
when you do things like resize, you lose your entire GL context.
Does is happen too when reducing the window (to the task bar)? I have a
problem with my program under windows 98: after being sent to the task
bar then opened again, the graphics are corrupted and not updated…
until I manage to display the help of my program and then everything
starts working again perfectly. So I guess I’m sending some usefull
opengl commands when showing the help, but I don’t know which ones. Any
info would be great.
(I’ve spent a lot of time searching about this, and asked on this list
some time ago, but got no answer)
Thanks!
Please remove “.ARGL.invalid” from my email when replying.
Incoming HTML mails are automatically deleted.
Actually, we have heard about it off and on for years.
On windows, when you do things like resize, you lose your
entire GL context.
I’m not exactly sure what’s going on with the context,
since the whole point of my using SDL OpenGL was to
not deal with it.
But with respect to the need to call glLight(),
glEnable, gl***List(), glMaterial(), etc… all over
again each time you do an SDL_SetVideoMode() to resize,
this only occurs when using the GLDirect driver. No such
problem exists with the ATI and Nvidia OpenGL drivers
(GeForce Ti4200 and Radeon 9600XT hardware in my case)
I’ve used. In fact, virtually all OpenGL programs I’ve
tried with these drivers and cards under Windows, resize
perfectly.
Thus, the GLDirect driver could very well be the culprit
here.
HOWEVER… GLUT-based programs do not experience the same
problem even when using the GLDirect driver so it might
be worth investigating if the way SDL deals with the OpenGL
rendering context upon an SDL_SetVideoMode() can be made
as robust as Windows GLUT.
In summary…
OpenGL interface: SDL
Driver: ATI/Nvidia
Problem: No
Actually, we have heard about it off and on for years. On windows, when
you do things like resize, you lose your entire GL context.
Actually, you only have to recreate the GL context if you recreate your
window or change video format, however this didn’t work with various drivers
in the past, so SDL takes the safe route and recreates the context whenever
you set a new video mode.
At some point I’d like to add a more simple resize call to SDL 1.3 which
would not change anything about the current window other than the size,
and would not require reinitialization of the GL context.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Actually, we have heard about it off and on for years. On windows, when
you do things like resize, you lose your entire GL context.
Actually, you only have to recreate the GL context if you recreate your
window or change video format, however this didn’t work with various
drivers in the past, so SDL takes the safe route and recreates the context
whenever you set a new video mode.
At some point I’d like to add a more simple resize call to SDL 1.3 which
would not change anything about the current window other than the size,
and would not require reinitialization of the GL context.