Originally posted by jwatte:
[b]You know, it really wouldn’t be that hard to create a library called something like “opengl20_32.dll” and make it expose all the OpenGL functions that are part of the 2.0 API, and internally, it would LoadLibrary the opengl32 library, extract extensions, and punt/error on functions it couldn’t get.
As far as I know, none of the extensions libraries actually do it this way. I wonder why? It’d be pretty slick. #include <gl20.h> and off you go, no specific extensions references needed![/b]
AFAIK, it’s a bit harder than that since opengl32.dll always gives you valid function pointer (ie. you don’t have to reinitialize all the addresses linked with the dll when you change of rendering context).
But if your app only ever uses one rendering context, then it is easy to do.
In my app I do it mostly this way, I include something like “opengl_1_5.h” then I only have to call opengl_1_5::initialize(); (here it’s not done automatically, because opengl32.dll initializes its own pointers when you create the rendering context and I’m not bypassing wgl calls).
The thing to remember is that it’s context specific, and when changing of rendering context you have to reinitialize it.
As for extension checking, my philosophy is to only check the version string. So I know it’s a bad idea to call opengl_1_5::initialize() when the drivers returned 1.1 
.
When the drivers return 1.5 it only means that it’s compliant with OpenGL 1.5 specs, but in practice it does not implies that it supports all the core features in hardware (and sometimes, not even in software, ie GeForce 2 + multisampling).
But even so I only check the extension string for extensions that aren’t in the core features (eg anisotropic filtering).
After all, all the core features are not guaranteed to have a corresponding ARB extension in the extension string (crossbar is a perfect example, but sometimes some core features don’t even have a similar extension and have been directly introduced as core features).
With this method, the only thing that can happen is that you can use functions linked to a feature that isn’t supported (ex: compressed textures) either in hardware or software.
So your program will work (ie. it will not crash because of a null function pointer) but of course the rendering will not be correct.
Uber-checking is IMHO worthless. In the philosophy described above, if we only support 1.5 or higher, it’s not going to help us to know whether or not the hardware is really capable of handling all core features (even if it says so via the version string).
The only thing uber-checking does add is a pretty message to the user telling him he has to buy newer hardware. But then again, it’s a lot of hassle, because it’s impossible to be 100% sure about every single feature.
