W or Z Buffer & 3D Card Questions!
Alan Carter
have been using Glide, and the W-Buffer seemed like the best option. Now I
have come to take a look at Direct3D and noticed that they say many cards
do not support W-Buffering!
I have a few questions for anyone that could please help:
1. Does anyone have access to lots of video cards, and have possibly
tested them to see which support W-Buffers, and which don't ? Or is there
a doc that lists compatabilities across different 3D cards ?
2. M$ reckon its best to use Z-Buffers for better card compliance in
hardware, to tell the truth I don't really know the difference between a Z
or a W buffer, apart from one uses 0.0 to 1.0 ? And the other uses 16bit
float sized values ? If that's all the difference is, is it going to cause
me a lot of heartache to switch over to the ZBuffer method now ?
3. Does anyone have any 'golden rules' on supporting 3D cards through D3D.
I'll be using DrawPrimitive, but at the moment I'm using just about every
lighting and effects option that my Voodoo provides. Is there a good way
to maintain the broadest compatability while retaining as many effects as
possible ? I would like the shift over the D3D to go easy, and not be
pulling my hair out when this game gets tested on different machine setups
and falls over.
And finally, I'm beginning to wish I never started using Glide in the first
place now just because its card specific. This 3D card lark is starting to
scare me like soundcards used to, some support some features while others
do other 'special' things. I can't afford to buy all the cards, and I hate
tedious code all over that kills certain effects. Is there a decent
cross-card base to write to ? Does anyone who has used D3D with
DrawPrimitive have any tips at all they would like to share with a scared
individual :-)
I know some people will suggest just querying the device caps through D3D
and supporting whatever features are available, that just seems like a bit
of a shot in the dark though!
Thanks all, Al.
Roadkill
Alan Carter wrote in message <01bdd7f7$bf2e04c0$LocalHost@alan>...
>A game I have been working on has been using the W-Buffer, mainly because I
>have been using Glide, and the W-Buffer seemed like the best option. Now I
>have come to take a look at Direct3D and noticed that they say many cards
>do not support W-Buffering!
As far as I know a lot don't.
>I have a few questions for anyone that could please help:
>
>1. Does anyone have access to lots of video cards, and have possibly
>tested them to see which support W-Buffers, and which don't ? Or is there
>a doc that lists compatabilities across different 3D cards ?
I've been working on a game also and have tested it on:
PII-266 Pure3DII Voodoo2 12MB
PII-266 ATI All-In-Wonder 4MB
Pro200 Matrox Millinium2
P200 Voodoo Rush
P166 Stealth 3000 4MB
P166 Stealth 2000 4MB
P166 S3 Virge 2MB
P133 Stealth 2000 4MB
P90 Creative Labs Voodoo2 8MB
and it has worked on all of them, with the exceptions that the fog did not
work on the ATI and the alpha blending didn't work on the S3 2MB. The fog
DID work on the ATI once, but then I had some help with new surface setup
code and now the fog nor the MODULATE_ALPHA work anymore, and they did
before.
>2. M$ reckon its best to use Z-Buffers for better card compliance in
>hardware, to tell the truth I don't really know the difference between a Z
>or a W buffer, apart from one uses 0.0 to 1.0 ? And the other uses 16bit
>float sized values ? If that's all the difference is, is it going to cause
>me a lot of heartache to switch over to the ZBuffer method now ?
Z-buffering in D3D is not that much of a problem, and it's supported by most
cards.
>3. Does anyone have any 'golden rules' on supporting 3D cards through D3D.
> I'll be using DrawPrimitive, but at the moment I'm using just about every
>lighting and effects option that my Voodoo provides. Is there a good way
>to maintain the broadest compatability while retaining as many effects as
>possible ? I would like the shift over the D3D to go easy, and not be
>pulling my hair out when this game gets tested on different machine setups
>and falls over.
>
>And finally, I'm beginning to wish I never started using Glide in the first
>place now just because its card specific. This 3D card lark is starting to
>scare me like soundcards used to, some support some features while others
>do other 'special' things. I can't afford to buy all the cards, and I hate
>tedious code all over that kills certain effects. Is there a decent
>cross-card base to write to ? Does anyone who has used D3D with
>DrawPrimitive have any tips at all they would like to share with a scared
>individual :-)
I wouldn't say that it was bad using Glide. Unreal used Glide and a
software mode. They were suppose to port it to D3D and OpenGL, but I
haven't seen it yet. I'm not sure if there's an advantage to using Glide
over D3D or not. What I mean is I'm not sure if Glide takes advantage of
3Dfx functionality that D3D or OpenGL haven't implemented or not. Things
that the card does that Microsoft nor SGI took into accout perhaps? I
haven't seen the SDK so I don't know. If it does support things better
since it is native 3Dfx you might consider programming in D3D but also
having a Glide port included for those lucky individuals with 3Dfx chips.
>I know some people will suggest just querying the device caps through D3D
>and supporting whatever features are available, that just seems like a bit
>of a shot in the dark though!
>
>Thanks all, Al.
It is a complicated pain to check everything, but believe me it'll pay off.
Example: My program checks for MODULATE_ALPHA and if it doesn't find that
cap it gives the texture an alpha value. Of course now the alpha on that
texture is fixed and can't be changed during gameplay(actually it can but it
would be too slow for realtime), but at least it's there instead of being
solid. Another problem could be if you don't check for something and it
happens to be supported on one card but not on another. It could work on
the first computer but crash the second one. That's the extreme case.