PDA

View Full Version : ChooosePixelFormat



NTBone
04-12-2004, 06:37 AM
I run wglinfo and I get a list of formats for windowed mode. Some of which support 16, 24 and 32 for z-buffer. When I run my app I use choose pixel format with depth buffer set to 32 but I always get 24.

When I attempt to force my app to use one of the pixel formats with 32 bit depth buffer I get

glLockArraysEXT = ( void (APIENTRY*)(GLint, GLsizei)) wglGetProcAddress("glLockArraysEXT");
glUnlockArraysEXT = ( void (APIENTRY*)()) wglGetProcAddress("glUnlockArraysEXT");

these two lines of code failing. Anybody know why?

plasmonster
04-12-2004, 10:10 AM
First, LockArrays functionality has nothing to do with the pixel format, save the necessity of having a rendering context before you start binding extensions. Secondly, 24 bits is not uncommon for a video card. NVidia's cards, for example, pack the depth and stencil into 32 bits, so don't expect to get a full 32 bits for depth alone.

Also, you might consider avoiding the use of explicit function casting and use the typedefs
that are included in the extension header:

...
#include "glext.h"
...
#define EXT( type, name ) type name = 0;
EXT( PFNGLLOCKARRAYSEXTPROC, glLockArraysEXT )
EXT( PFNGLUNLOCKARRAYSEXTPROC, glUnlockArraysEXT )
...

glLockArraysEXT = (PFNGLLOCKARRAYSEXTPROC)wglGetProcAddress( "glLockArraysEXT" );
...

This is much easier to read, and less error prone. OpenGL is wonderfully consistent when it comes to naming things, so you can figure out the type name without digging into the headers:
They all begin with PFN (pointer to function)
followed by GL or WGL ( good old OpenGL )
followed by the name of the function
followed by EXT, ARB, NV, ATI, ...
followed by PROC.

all in upper case. So if you know the name of the extension, and who created it, you are good to go. You can also enable the prototypes in the extension header itself, but with some thought, this can give you alot of flexibility.

Honk
04-13-2004, 04:27 AM
Originally posted by RadicalHumility:
First, LockArrays functionality has nothing to do with the pixel format, save the necessity of having a rendering context before you start binding extensions. Not quite right. By picking an non-accelerated pixelformat he will be forced into software rendering (aka the pesky MS implementation) which
doesnt support this extension and hence wglGetProcAddress() will fail.

This seems to be the problem here.

I fully agree with the other information though.

@NTBone:

I suggest that you request a 24 bit z-buffer with an 8 bit stencil buffer since this is the most common setup.