ZBuffer Depth problems...

BlitzMax Forums/MiniB3D Module/ZBuffer Depth problems...

SLotman

(Posted 2010) [#1]

2nd time I get some rendering problems on MiniB3D - as in meshes being rendered in the wrong order. Both cases, with Intel chipsets.

I managed to fix it by going into Intel's control panel and changing the ZBuffer to 24 bits - it's default is 16 bits.

My concern is this: probably my game will run on such a hardware, and common people wouldn't know how to change that.

Is that something I can change on MiniB3D to force the ZBuffer depth, or at least check the current supported depth? Anything that could fix that instead of telling the user to "change the 3d settings" on the machine?

Edit: Just found a nice page here with a ZBuffer calculator; I'm going to try to test if changing the ranges of the camera has any effect into the rendering problems, and if it has, I'll post here some results.

Last edited 2010

Kryzon

(Posted 2010) [#2]

Is that something I can change on MiniB3D to force the ZBuffer depth, or at least check the current supported depth? Anything that could fix that instead of telling the user to "change the 3d settings" on the machine?

That lies in BRL.mod\glGraphics.mod\glgraphics.win32.c.

There's a part there that...

static void _initPfd( PIXELFORMATDESCRIPTOR *pfd,int flags ){

	memset( pfd,0,sizeof(*pfd) );

	pfd->nSize=sizeof(pfd);
	pfd->nVersion=1;
	pfd->cColorBits=1;
	pfd->iPixelType=PFD_TYPE_RGBA;
	pfd->iLayerType=PFD_MAIN_PLANE;
	pfd->dwFlags=PFD_DRAW_TO_WINDOW|PFD_SUPPORT_OPENGL;

	pfd->dwFlags|=(flags & _BACKBUFFER) ? PFD_DOUBLEBUFFER : 0;
	pfd->cAlphaBits=(flags & _ALPHABUFFER) ? 1 : 0;
	pfd->cDepthBits=(flags & _DEPTHBUFFER) ? 1 : 0; // THIS IS THE CULPRIT.
	pfd->cStencilBits=(flags & _STENCILBUFFER) ? 1 : 0;
	pfd->cAccumBits=(flags & _ACCUMBUFFER) ? 1 : 0;
}

...set's up the Pixel Format Descriptor. Now, I believe since that Conditional Expression only alternates between 1 and 0 for the DepthBit value, you either get NO depth buffer, or a DEFAULT value for the depth buffer precision.

In a wild guess, you could add another enumerator for a 24 and 32 bit depth buffer:

enum{
	_BACKBUFFER=	0x2,
	_ALPHABUFFER=	0x4,
	_DEPTHBUFFER=	0x8,
	_STENCILBUFFER=	0x10,
	_ACCUMBUFFER=	0x20,
	_DEPTHBUFFER24= 0x40, // added
	_DEPTHBUFFER32= 0x80 // added
};

And these as well, to your BRL.mod\graphics.mod\graphics.bmx:

Const GRAPHICS_BACKBUFFER=	$2
Const GRAPHICS_ALPHABUFFER=	$4
Const GRAPHICS_DEPTHBUFFER=	$8
Const GRAPHICS_STENCILBUFFER=	$10
Const GRAPHICS_ACCUMBUFFER=	$20
Const GRAPHICS_DEPTHBUFFER24=	$40 'Added
Const GRAPHICS_DEPTHBUFFER32=	$80 'Added

And then changing _initPfd():

static void _initPfd( PIXELFORMATDESCRIPTOR *pfd,int flags ){

	memset( pfd,0,sizeof(*pfd) );

	pfd->nSize=sizeof(pfd);
	pfd->nVersion=1;
	pfd->cColorBits=1;
	pfd->iPixelType=PFD_TYPE_RGBA;
	pfd->iLayerType=PFD_MAIN_PLANE;
	pfd->dwFlags=PFD_DRAW_TO_WINDOW|PFD_SUPPORT_OPENGL;

	int depthBits=0;
	depthBits=(flags & _DEPTHBUFFER) ? 1 : 0;
	depthBits=(flags & _DEPTHBUFFER24) ? 24 : depthBits;
	depthBits=(flags & _DEPTHBUFFER32) ? 32 : depthBits;
	
	pfd->dwFlags|=(flags & _BACKBUFFER) ? PFD_DOUBLEBUFFER : 0;
	pfd->cAlphaBits=(flags & _ALPHABUFFER) ? 1 : 0;
	pfd->cDepthBits=depthBits;
 	pfd->cStencilBits=(flags & _STENCILBUFFER) ? 1 : 0;
	pfd->cAccumBits=(flags & _ACCUMBUFFER) ? 1 : 0;
}

Last edited 2010

SLotman

(Posted 2010) [#3]

Thanks! I also tried changing the code on linux part, on ChooseVisual to:

	// updated here to fix depth buffer problems on Linux on GMA Intel
	if (flags&FLAGS_DEPTHBUFFER32) 
	{
		*s++=GLX_DEPTH_SIZE;*s++=32;
	} else {
		if (flags&FLAGS_DEPTHBUFFER24) 
		{
			*s++=GLX_DEPTH_SIZE;*s++=24;
		} else {
			if (flags&FLAGS_DEPTHBUFFER) 
			{
				*s++=GLX_DEPTH_SIZE;*s++=1;
			}
		}
	}

And on MacOS too, on _initAttrs:

	if (flags & FLAGS_DEPTHBUFFER32 )
	{
	   attrs[n++]=kCGLPFADepthSize;attrs[n++]=32; 
	} else {
		if( flags & FLAGS_DEPTHBUFFER24 )
		{ 
			attrs[n++]=kCGLPFADepthSize;attrs[n++]=24; 
		} else {
			if( flags & FLAGS_DEPTHBUFFER ){ attrs[n++]=kCGLPFADepthSize;attrs[n++]=1; }
		}
	}

Don't know if any of this will work - but at least I can test it (probably today, if I'm feeling better) on a win-pc at work :)

SLotman

(Posted 2010) [#4]

Didn't fix anything :(

The only thing that worked was changing the near and far values from the camera, increasing the near value a lot, and reducing the far value drastically.

Last edited 2010

Kryzon

(Posted 2010) [#5]

Ugh, I thought it wouldn't... when it's easy like that, you know it's got something more to it. I'll post it in the Module Tweaks forum (since this is what we're doing).

SLotman

(Posted 2010) [#6]

I think there isn't much that can be done - apparently the Intel opengl driver 'locks' the buffer to 16 bits, unless the user changes it manually - Direct-X on that part does a better job, it always create a 24bits depth buffer afaik :(

I totally understood what you've done - and even found some stuff on the Linux and Mac part doing just that - setting the value manually to 24 or 32 (the next byte written after the DEPTHBUFFER flag), but still - I think Intel (at least on windows) is locking the buffer to whatever is specified in their control panel settings :/

Kryzon

(Posted 2010) [#7]

Well, that is plain nonsensical on their part, if you ask me.
I hope you can find a workaround.

SLotman

(Posted 2011) [#8]

Just a small update: altough it doesn't affect Intel cards at all, it did work on a Nvidia 320M card on MacOS - so maybe all that code could be at least a little useful!

Kryzon

(Posted 2011) [#9]

Oh! glad it works.

Did you notice any actual benefit? I mean, did you get less Z-fighting\flimmering, something like that?
Cya.

SLotman

(Posted 2011) [#10]

Yes, the z fighting was completely gone on the Mac.

Too bad it doesn't work also on the Intel GMA, but at least it is something :)