Funny Depth Buffer behaviour with DirectX 9.0c on NVIDIA Quadro NVS 285
Author
This happens only when I turn on multisampling.
The depth buffer seems to reverse the z order.
It doesn't happen all the time. Sometimes when I launch the app
it's OK, sometimes the z order is reversed. When it is reversed, it
looks like the multisampling has been disabled (even though it is on).
Any idea what is going on here?
1. Any output from the Debug Runtimes?
2. Any chance of a screenshot?
3. Do you have the latest drivers?
4. What happens if you use the reference rasterizer instead? If it works with that, then it's likely a driver bug.
2. Any chance of a screenshot?
3. Do you have the latest drivers?
4. What happens if you use the reference rasterizer instead? If it works with that, then it's likely a driver bug.
On top of Steve's suggestions - how are you handling the MSAA device creation? DXUT should handle it properly, but off the top of my head I think the implicit depth-stencil is not created with MSAA and is thus disabled initially. This could create all sorts of on-screen garbage. The debug runtimes will tell you if this is the case.
hth
Jack
hth
Jack
Did you make sure that there is a depth buffer? From your description it sounds like there might not be one, or it's not enabled, and it's just the order of drawing deciding things.
Author
I set AutoDepthStencil to TRUE.
Is there a way to detect if it has been created?
I can't use the debug options because my acccess to the
machine is remote. Does not happen on all machines.
Is there a way to detect if it has been created?
I can't use the debug options because my acccess to the
machine is remote. Does not happen on all machines.
And what about the reference rasterizer? If it works fine on the ref rast, then I'm 99.9% sure it's a driver bug.
Author
You're right. Got the latest drivers and the problem disappeared.
Just how do you guys working on shrink-wrapped products cope with this?
Not enough that you use the API correctly, you have to wonder if its your
code or the card makers code that causes the bugs.
Just how do you guys working on shrink-wrapped products cope with this?
Not enough that you use the API correctly, you have to wonder if its your
code or the card makers code that causes the bugs.
Quote:Original post by ConstantinThat's exactly what the reference rasterizer is for (Well, one of it's uses). The reference rasterizer is just that - a reference device. All drivers should behave as it behaves. If they don't, then there's a bug in the driver.
Just how do you guys working on shrink-wrapped products cope with this?
Not enough that you use the API correctly, you have to wonder if its your
code or the card makers code that causes the bugs.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
