Tired of the WGL_pixel_format extension !

[Ysaneya]

I'm really starting to be tired by this extension. I have tons of problems with it.

What i want to do is to list the pixel formats available on my system, and let the user select one of them. For that, following the spec, i'm creating a temp window to initialize the extensions, then list the formats by calling wglGetPixelFormatAttribivARB with the DC of my temp window and the unique attribute WGL_NUMBER_PIXEL_FORMATS_ARB.

On an ATI Rage 128 and ATI Radeon 8500, the call to that function fails. According to the spec, i should be able to call GetLastError() to know exactly what the error is, but what i get is a "operation completed successfully"! Grrrr. I'm 100% sure my code is correct; the only thing unusual i do is to create the main window with that extension (while generally it's only used to create PBuffers). Latest drivers installed.

It's a little better with NVidia's cards: it works on GeForces, but the drivers do not seem to follow the spec at 100%. According to the spec, WGL_COLOR_BITS_ARB should return the size of the color buffer EXCLUDING the alpha bitplanes. But it returns 32 instead of 24 with the latest drivers. There is the same problem with the ZBuffer/stencil buffer. It's not a big problem, but i hate to add dirty hacks to my code just to fix that.

Y.

[Ysaneya]

Nobody ?

Is there a silence law ?

Y.

[Ysaneya]

Found the problem. You need a valid context (on ATI cards, not Nvidia's) in order to successfully call wglGetPixelFormatAttribivARB. The logic of that is beyond me. If i want to enumerate the pixel formats, it's because i want to create a window, so i don't have a window yet !

Whoever designed that, shame on you. I hear so many times "OpenGL is better than D3D, OpenGL is easier than D3D". That is no longer true as soon as you start digging into extensions.

Enough ranting for today.

Y.

[GPSnoopy]

I knew you had to create a valid rendering context to use wglGetProcAddress for it, but you really still need a valid rendering context to use WGL_pixel_format functions?!?!?

Somehow it makes sense you need a valid OpenGL context to use OpenGL functions, but it's still completly illogical from a practical point of view.

I had to the idea to implement this among other things... but more I program in OpenGL, more I want to wait for OpenGL 2.0 before going too far in my engine. (and attack less OGL dependent parts)
Latest extensions, this once included, are a total mess, I think we can say OpenGL 1.x has come to an end.

[GPSnoopy]

Notice, you have to delete the temp windows before using wglGetPixelFormatAttribivARB (or any other function of this extension).

Not that it needs to be deleted but you don't need it anymore.
I think that the mistake you're making is that you're using the temp window's DC.

You should maybe delete the temp window, create the new and final window then use:

hDC = GetDC(hWnd);

hWnd being of the final window.

Now, at this point I don't think hDC stands as a valid OpenGL context yet (as far as I remember wglCreateContext(hDC) has to be called for that), but I might be wrong.
But from NVIDIA papers you should now be able to use WGL_pixel_format functions to finish the creation of this window by setting you pixel format.
But it means you don't need a valid OpenGL device context.

The really annoying part is creating the temp window and being sure you get a valid OpenGL ICD context for this temp window. The rest shouldn't be a problem. (except ATI's drivers J/K)




[This message has been edited by GPSnoopy (edited 01-28-2002).]

[Ysaneya]

Yes. What i wanted to do (it's not a secret) is to propose to the user, before running the application, the choice to run in an antialiased window or not.

What i've been doing is the following:

1) Create a temp window with any matching pixel format, using the "normal" wglChoosePixelFormat function. Then i create a valid context.

2) Initialize WGL and GL extensions.

3) Deleting the temp window.

So far, ok. Now, i want to list all the formats available to create a new window.

4) I get the number of available formats with wglGetPixelFormatAttribivARB and the WGL_NUMBER_PIXEL_FORMATS_ARB attribute.

5) I describe each format with the same function.

6) Propose these formats to the user, let him choose one.

7) Create a window

8) Set the pixel format chosen in 6) to this window, create context, render, etc..

As i said, it works perfectly on NVidia cards. On ATIs, it fails at step 4, and i found the reason is because there's no valid context. Actually i think i won't bother with ATI cards. They do not have the WGL_ARB_multisample extension anyway. I think it'll just use the "standard", but old & ugly method instead. What a shame.

As a note, i've also found that i got many problems with ATI drivers if i try to use many rendering contexts per thread (even on different windows). I'm becoming tired, very tired.

Y.

[Ysaneya]

A precision on my last problem: i have problems even when i do not use multiple contexts at the same time.

On my Radeon 8500, doing the following will cause a crash in glDrawElements:

1) Create temp window, set format, create context, delete context, destroy temp window.

2) Create window, set format, create context, render with glDrawElements, etc..

Y.

[devrel]

Hi Ysaneya,

Is it possible for you to send ATI developer relations your sample code? We are looking into this right now, and it would be easier for us to debug this issue with a sample code directly from you.

You can send the sample code to devrel@ati.com

Thanks.

Regards,

Vernon Chiang
ATI Developer Relations

Originally posted by Ysaneya:
A precision on my last problem: i have problems even when i do not use multiple contexts at the same time.

On my Radeon 8500, doing the following will cause a crash in glDrawElements:

1) Create temp window, set format, create context, delete context, destroy temp window.

2) Create window, set format, create context, render with glDrawElements, etc..

Y.

[Ysaneya]

Ah yes, but it's been 20 days since i had that problem. Not only am i under NDA, so i cannot send you my source code, but i also switched to Win2k and deleted the aforementionned problematic code. I will try to write a "minimal" application showing that problem this week end, though.

Y.