Problems accessing WGL extensions

I’m attempting to get the entry point for “wglGetExtensionsStringARB”
using wglGetProcAddress() in order to query the extensions available
for my graphics card. It returns NULL on an NVideo GForce DDR (as
well as an ATI Radeon 7500) so it appears that I am missing something
either in approach or software. I’m running on WinXP with OpenGL 1.2
and version 6.13.10.4109 of the OpenGL ICD for Nvidia.

I know the extensions are there since I was able to run the simple pbuffer demo from NVidia’s SDK using the glh_init_extensions() call.

Any ideas?

-Bill

Just a guess, but do you have a current rendering context when you’re calling wlgGetProcAddress?
In order for wglGetProcAddress to succeed, you need a current rendering context that is hardware accelerated (that is, uses the ICD).

So without an RC, I don’t have access to the ICD? From the documentation I saw about accessing extensions, it appeared that the RC setup could occur after the call to get the extension proc entry point. Thanks for the info.

Well, unfortunately that’s the way it is with wglGetProcAddress. It is kind of perverted that a window+RC is required to get WGL extensions such as WGL_ARB_extensions_string, WGL_ARB_pixel_format, or WGL_ARB_pbuffer, but unfortunately that’s how it is. Under Linux, glxGetProcAddress does not behave in such a ridiculous way.

One thing you can do to get the WGL extension entry points (don’t know if it’s allowed according to the spec, but then again, there is no real WGL spec anyway ;-), is to create a hidden window, set an ICD pixel format for it, create a rendering context, retrieve all the WGL extensions you need, and then destroy the window+RC again.

Ah well, I believe you’re right about the hidden window approach. Thanks again for the info.

I have example code here: http://www.area3d.net/file.php?filename=nitrogl/base.c
That uses WGL extensions to create a context, as well as using multisample for FSAA.

I have a question about the hidden window approach.

If I am not wrong (and I hope I am) the wgl extension list is device-context-dependant, as a result creating a window to get a wgl extension list, fill the pointers to some extensions and then destroy the temp window popping up another one with the functionalities we need may give error.

As far as I know, only a rendering context can be bound to a window / dc, so, when we destroy the temp window we also have to destroy the dc. Then we pop up another window with a different dc. The new dc however, may not support the same wgl functionalities of the temp window. As a result, the pointers may point to wrong address (probably resulting in program corruption).

Well, this is probably a pure theoric problem , I think we don’t really need to worry about this but, if someone got the idea, I would like to know their opinions.

The fact the wgl extension list is device dependant has sense. For example, when binding to a pbuffer (which has its own dc and rc in win) the extension which controls vsync may not be avaiable - it simply does not make sense.
Another example would be to create a temp window, enable the antialiasing extension and using it in another window which, having got another dc, it is not guaranteed to allow antialiasing…

I am not sure if this is a real problem, MSDN actually confused me. Anyway, if it is, it is probably nothing really serious…

The hidden window approach still works in that case. To be absolutely sure, you should, however, try to use the same pixel format for the hidden window and the window you’re later going to use. But in my experience with ATI and NVIDIA drivers, you always get the same entry points for any ICD pixel format. So all you have to make sure is that you get an ICD pixel format for all your render targets.

I agree with you that WGL extensions are device dependent, but why for God’s sake do the function entry points have to be rendering context dependent? As I wrote above, under Linux the design of glXGetProcAddress places a lot less burden on the application programmer.

Thanks for your reply Asgard.

So, looks like the problem is only theorical. Having vendors facing M$ bad things is good.

Unluckly, WGL is something we have to face and use.

Originally posted by Asgard:
I agree with you that WGL extensions are device dependent, but why for God’s sake do the function entry points have to be rendering context dependent? As I wrote above, under Linux the design of glXGetProcAddress places a lot less burden on the application programmer.

Because the entry points might be from more than one ICD? Don’t forget we might be dealing with more than one GPU in the same PC.

The whole opengl32.dll / ICD thing is meant to allow support for more than one ICD or MCD. That’s also why you need to get GL exts entry points after getting an RC.

The ICD mechanism only allows one ICD to be present in the system.

Then I’m lost…

What happens when you have multiple opengl cards? And multi-monitor support?
The mechanism should provide RC’s that depend on which monitor/card the window belongs to.

Before I had my multi-head GeForce4, I had a Matrox card and a GeForce2 in my PC, and only the primary device’s ICD (the GF2) was used. So on the secondary device (the Matrox card) all I got was the MS software renderer.