Problem with GetDepthStencilSurface

1) If the depth surface wasn''t created as D3DFMT_D16_LOCKABLE, then ummm it isn''t lockable


2) Many chips/drivers don''t support D16_LOCKABLE


3) Locking the depth buffer isn''t ever a good idea anyway in performance terms. There are only a few reasons I can think of that you''d "need" to:

a. lens flare (and similar) occlusion: Take a look at some of the other threads running at the moment in this forum.

b. pre-rendered backdrops with fixed depth information: store a low polygon version of the backdrop in its 3d form and use this to just render that to the depth buffer (set a ZERO:ONE blend mode).

c. nailboards (and similar): the whole point of using nailboards & impostors is performance - forcibly serialising & stalling the GPU and CPU and performing essentially a software blit is going to hurt performance a lot more than the extra polygons. Pixel shader 1.3 and above has instructions to do interesting things with the depth buffer which could probably be exploited to do nailboards.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

I want to read the stencil buffer to find out if an specific point is already drawn, isn''t that the right way to do that?

Couldn''t anybody tell me if it even is possible to find out if an pixel was already drawn? this would help me a lot!

I just want to do the test for my skybox, i want to check if it''s necessary to draw it (because skybox slows down everything very much)

So , how are you going to check if the skybox needs to be drawn using pixel checking ?

The problem is your "check" will involve using the CPU to read individual pixels which will slow everything down and is just about the slowest way of achieving what you want, i.e. I''d expect your performance to go to below rendering WITH the skybox.


1) Since a skybox goes behind everything else, there is a large chance that it is mostly occluded as you know. So simply render the skybox LAST and leave Z buffering on - Z buffering will perform the occlusion test for you on a per pixel basis!

2) And if you really must use the stencil buffer to do this, you can use stencil test for it.


Either way, still make the draw call (Draw*Primitive) with the skybox, and let the hardware decide when pixels are occluded and so don''t need rendering - I suspect the reason your code goes "slow" when the skybox is rendered is due to fillrate - letting the Z buffer sort that kind of thing out is what Z buffers were invented for.


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

i will simply check if one of my polygons points is not drawn, then i will draw the poly (first I''m converting the 3D points to 2D screenspace)

ok, but then i will have to create an really big skybox (currently it''s only at an dimension of 1)....

what is stencil test?


btw, why not use CPU, since DX seems to only use the GPU for all it''s stuff we could still use the CPU for supporting stuff

i checked out your methode, but there is an very big problem using that methode

I have some geometry wich turns ZWRITE off, so the sky will overdraw all geometry rendered with ZWRITE off

Obviously anything which doesn''t write to the depth buffer such as alpha blended stuff should be drawn after the sky. Why not just change the render order

- render all of scene which uses ZWRITE=TRUE
- render sky, ZWRITE=TRUE and backface culling on
- render the part of the scene which uses ZWRITE=FALSE, leave Z buffer testing enabled.

Personally I don''t see any other way of doing it. Performing a test with the CPU will always usually be more expensive than the above.

500 500 500 500

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

ok, I think you''re right. I''m using stacks for rendering my Q3 level, so changing the render order would be no problem.

I need ZWRITE off for rendering the sky, because I''m using alpha blending to blend the sky layers (with zwrite on I would get very odd z-buffer problems on my sky)