Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / Using TNT's stencil buffer with Direct3D Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Ness

August 09, 1999, 09:23 PM

Have you ever tried to run the ShadowVol & ShadowVol2 samples included with the DXSDK? If you have (and you also happen to be the proud owner of a TNT - mine 's a Viper550 by the way), maybe you 've noticed a subtle, nevertheless quite important detail: they don 't work.

Now, before you think something on the lines of "oh, that 's unusual for a Microsoft product", the above statement is not exactly true. The software emulation works, as well as the reference rasterizer. However, when the HAL device is selected (the default), all you get is a darkened image. No shadows at all. As it turns out, this is the result of the stencil buffer not working as it should (or not working at all, actually).

After the initial disappointment (a stencil buffer is a very nice thing to have), I had a nasty thought. Remember that wonderful pixel format restriction that DirectX -the only API which can be described as ‘truly inspired’- imposes on you? From the moment that you 've set the video mode of your choice, you 're stuck with a primary surface having a specific pixel format. That 's quite normal. And now the catch: all surfaces that are created on the card ’s memory (this includes the all-important depth buffer), must be of the same type (i.e. share the same format with the primary surface). At least on some hardware. Or some drivers. Or with some surfaces. Or with some combination of the above. My God, I love this API.

Now, I will not argue if that was really necessary or not. What it means however, is that you can ’t use, say, a 32-bit Z-buffer while in a 16-bit video mode (or can you? if you play with DDTest a bit, you can catch a small glimpse of the inconsistent and brain-damaged hell that is DirectDraw).

TNT supports three z-buffer formats: Z16, Z24 and Z24S8. Bingo! I switched my desktop to 32-bit color depth, and the samples worked perfectly (well, no sh*t Sherlock). After that, I went ahead and wrote my own testing code. The strange thing is that when I try to create a (32-bit by necessity) depth & stencil buffer in a 16-bit mode, I don't get an error. The buffer gets created normally, and the surface description returned by DirectDraw confirms that it is indeed a Z24S8 surface. However, the stencil part does not work (I haven 't checked if the z part is *really* 24 bits wide or the driver is feeding me BS, though).

My question, therefore, is this: have you managed to make the stencil buffer work in a 16-bit video mode? I badly need its services (volumetric shadows are only a small part of it), and I can 't believe that it 's unusable unless you 're willing to take the performance hit associated with 32-bit rendering. That would be Bad. I 've never heard of any such thing, too.

Am I missing something? (quite probably I am)

Ness/Arcadia


 
This thread contains 1 message.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.