PDA

View Full Version : wglChoosePixelFormatARB



Megalomaniac
08-18-2005, 07:05 AM
Hi,
Iíve been having a spot of bother using WGL extensions. Iím attempting to use wglChoosePixelFormatARB in conjunction with glClampColorARB to turn off the clamping of colour values output from the fragment shader (rest assured I have a very good reason for wanting to turn off the clamping and have been informed this is the best way to do it; any other suggestions are welcome). However

wglChoosePixelFormatARB = (PFNWGLCHOOSEPIXELFORMATARBPROC)wglGetProcAddress( "wglChoosePixelFormatARB" );returns NULL. I canít even call

wglGetExtensionsStringARB = (PFNWGLGETEXTENSIONSSTRINGARBPROC)wglGetProcAddres s( "wglGetExtensionsStringARB" );which also returns NULL. Is there anything I need to make sure Iím doing before these calls bearing in mind this was previously working with a simple ChoosePixelFormat call before I started playing around with the clamping and changed the pixel formats accordingly.

Iím running this on an NVIDIA 6800 with ForceWare version 77.72.

Thanks in advance for any help :)

sqrt[-1]
08-18-2005, 03:01 PM
Do you have a context valid when you make these calls?

You need a context active before you can make valid wglGetProcAddress calls. So you typically create a "dummy" context to get the handles.

tamlin
08-18-2005, 04:56 PM
Even if redundant: have a look at some of humus' demos, and grab framework. I think that explains it all (even if a bit terse :) ).

Megalomaniac
08-19-2005, 06:39 AM
Thanks for the help guys, Iíve made a bit of progress but am now stumped on something else along the same lines. I managed to get something going from a combination of things I read on NeHe, Humus etc. However while I now get no errors itís not performing as expected.

What Iím actually after is an output of unclamped float values (32-bits per component if poss) from the fragment shader and my code looks something like this at the moment:

First I set a PIXELFORMATDESCRIPTOR

static PIXELFORMATDESCRIPTOR pfd =
{
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW |
PFD_SUPPORT_OPENGL |
PFD_DOUBLEBUFFER,
PFD_TYPE_RGBA,
128,
32, 0, 32, 0, 32, 0,
32,
0,
0,
0, 0, 0, 0,
16,
0,
0,
PFD_MAIN_PLANE,
0,
0, 0, 0
};and set a basic pixel format with no WGL stuff (apparently you have to do this first??):

void SetupPixelFormat( HDC hDC )
{
int nPixelFormat;

nPixelFormat = ChoosePixelFormat( hDC, &pfd );
SetPixelFormat( hDC, nPixelFormat, &pfd );
}Then I sort out the context:

hRC = wglCreateContext( hDC ); // Create the rendering context
wglMakeCurrent( hDC, hRC ); // Make the rendering contextNext I setup the WGL stuff (just before the texture / shaders setup stuff, Iíve also tried placing it afterwards):

bool SetupWGLPixelFormat( HDC hDC )
{
int nPixelFormat;

wglChoosePixelFormatARB = (PFNWGLCHOOSEPIXELFORMATARBPROC)wglGetProcAddress( "wglChoosePixelFormatARB" );

if ( !wglChoosePixelFormatARB )
{
MessageBox( NULL, "wglChoosePixelFormatARB not supported", "Error! (SetupWGLPixelFormat)", MB_OK );
return false;
}

BOOL bValidPixFormat;
UINT nMaxFormats = 1;
UINT nNumFormats;
float pfAttribFList[] = { 0, 0 };
int piAttribIList[] = { WGL_DRAW_TO_WINDOW_ARB,GL_TRUE,
WGL_SUPPORT_OPENGL_ARB, GL_TRUE,
WGL_ACCELERATION_ARB, WGL_FULL_ACCELERATION_ARB,
WGL_COLOR_BITS_ARB, 128,
WGL_RED_BITS_ARB, 32,
WGL_GREEN_BITS_ARB, 32,
WGL_BLUE_BITS_ARB, 32,
WGL_ALPHA_BITS_ARB, 32,
WGL_DEPTH_BITS_ARB, 16,
WGL_STENCIL_BITS_ARB, 0,
WGL_DOUBLE_BUFFER_ARB, GL_TRUE,
WGL_PIXEL_TYPE_ARB, WGL_TYPE_RGBA_ARB,
0, 0 };

bValidPixFormat = wglChoosePixelFormatARB( hDC, piAttribIList, pfAttribFList, nMaxFormats, &nPixelFormat, &nNumFormats );

if ( !bValidPixFormat )
{
MessageBox( NULL, "Invalid Pixel Format", "Error! (SetupWGLPixelFormat)", MB_OK );
return false;
}

SetPixelFormat( hDC, nPixelFormat, &pfd );

return true;
}Then I attempt to turn off clamping:

glClampColorARB( GL_CLAMP_VERTEX_COLOR_ARB, GL_FALSE );
glClampColorARB( GL_CLAMP_FRAGMENT_COLOR_ARB, GL_FALSE );
glClampColorARB( GL_CLAMP_READ_COLOR_ARB, GL_FALSE );Before finally dumping values out with:

glReadPixels( 0, 0, WINDOWWIDTH, WINDOWHEIGHT, GL_RGBA, GL_FLOAT, fPixels );
glReadPixels( 0, 0, WINDOWWIDTH, WINDOWHEIGHT, GL_DEPTH_COMPONENT, GL_FLOAT, fDepth );The problem is the values are still clampedÖÖI'm told this is possible in GL so I must be missing something.

Hope these questions arenít too daft but Iím jumping in at the deep end a bit with OpenGL having only used DirectX previously. So thereís a bit of a combination of internet trawling and guesswork in the code. :D

Thanks again.

jide
08-19-2005, 07:41 AM
Originally posted by sqrt[-1]:
Do you have a context valid when you make these calls?

You need a context active before you can make valid wglGetProcAddress calls. So you typically create a "dummy" context to get the handles.Are you sure this will suffice ? Countrary to Linux, Windows pointer functions that are returned depend on the context. Clearly, a GL function pointer, under Windows, might not work (point at the good address), depending on the context.

Here is the quote from the specs (glXGetProcAddressARB):



Should corresponding functions exist in the window-system specific
layer on non-GLX implementations?

Yes. wglGetProcAddress already exists for Microsoft Windows, and
Apple has stated they will support aglGetProcAddress.
Unfortunately, there is an unavoidable inconsistency with
wglGetProcAddress, which returns context-dependent pointers.
This should be made abundantly clear in the documentation, so
that portable applications assume context-dependent behavior.
So, a dummy context might be the worst thing to do under Window. To my opinion...

Megalomaniac
08-19-2005, 07:50 AM
The context is sorted before any calls to wglGetProcAddress, so that shouldnít be a problem.....I hope :D

Humus
08-19-2005, 09:50 PM
Are you trying to create a floating point framebuffer? That's not supported by the hardware. Rendering to floating point has to be done in off-screen buffers, pBuffers or FBOs.

sqrt[-1]
08-20-2005, 11:56 PM
Originally posted by jide:

Originally posted by sqrt[-1]:
Do you have a context valid when you make these calls?

You need a context active before you can make valid wglGetProcAddress calls. So you typically create a "dummy" context to get the handles.Are you sure this will suffice ? Countrary to Linux, Windows pointer functions that are returned depend on the context. Clearly, a GL function pointer, under Windows, might not work (point at the good address), depending on the context.

Here is the quote from the specs (glXGetProcAddressARB):



Should corresponding functions exist in the window-system specific
layer on non-GLX implementations?

Yes. wglGetProcAddress already exists for Microsoft Windows, and
Apple has stated they will support aglGetProcAddress.
Unfortunately, there is an unavoidable inconsistency with
wglGetProcAddress, which returns context-dependent pointers.
This should be made abundantly clear in the documentation, so
that portable applications assume context-dependent behavior.
So, a dummy context might be the worst thing to do under Window. To my opinion...Yes I would also not recommend getting extension entry points from under any context but the one you can use them. However, the wglChoosePixelFormatARB type calls I believe are an exception to this rule as you need a context to get the entry points, but these are functions you use in creating a context. So chicken and egg...

As to the origional poster, take note of what Humus said. Re-reading your post it seems tou are trying to create a floating point frame buffer which is not possible. Also note that you can only set the pixel format once for a window. (looking at your example code)

Megalomaniac
08-22-2005, 03:37 AM
Ahhh I see, I was told floating point framebuffers were possible. Looks like I'll have to use FBO's then. Thanks guys