[SDL] Bug with dynamic GL loading
Ryan C. Gordon
icculus at clutteredmind.org
Wed Sep 7 22:20:00 PDT 2005
> Couldn't set GL mode: Couldn't load GL function glBegin: No GL driver
> has been loaded
> Ah, so that explains it then... No library handle.
> Wonder if that's a (Classic) Mac-specific little bug ?
> The Quartz version seems to be "cheating" here anyway, as it
> loads and unloads the CFBundle for every GL_GetProcAddress ?
Lots of rambling follows:
The docs say you need to call SDL_GL_LoadLibrary() before using
SDL_GL_GetProcAddress(), since you may want to load something other than
the system default GL...although really this is a Linux thing mostly,
and even there it's a relic from the Mesa/3Dfx/UtahGLX/DRI/Nvidia days.
Most systems, including modern Linux, want to load one library from one
central place and it's the user, not the app, to blame if the wrong
driver is installed there.
This is also why you can get away with passing a NULL to
SDL_GL_LoadLibrary on MacOS X and other platforms, even though this is
undocumented behaviour: those platforms don't care WHAT you request,
since they'll ignore it anyhow.
That being said, the reason some platforms will do the loading for you
is because, increasingly, they need standard GL entry points to do some
common things...setting up the GL context used to be entirely
glX/AGL/wgl/etc calls that were outside the GL proper, but that's less
I don't know if your patch is correct in this case, but we should
probably implicitly force a library load if the user hasn't done it
already when SDL_SetVideoMode() is called with SDL_OPENGL...some
platforms already do this, as you've seen.
In the meantime, we should fix that test program, too. :)
More information about the SDL