🔒 Locked

backbuffer, adapter format, compatibility issues.

Started by IFooBar Jan 10, 2003 at 2:16 PM 3 replies 250+ views

Original Post

119

Jan 10, 2003 at 2:16 PM

Ok I'm almost done with the enumeration application. I have a few questions though... 1) If a single adapter format is found to be hardware accelerated (meaning IDirect3D::CheckFormat( HAL ) succeeded) then does that mean that ALL following adapter formats will also be hardware accelerated? 2) If a multisample type can be used with say a D3DFMT_X8R8G8B8 back buffer, then does that also mean it can be used with a D3DFMT_A8R8G8B8 back buffer (so long as the adapter supports that back buffer)? 3) Does the windowed and non-windowed version of the same adapter format (again say it was D3DFMT_X8R8G8B8) always have the exact same properties ie: supported depth-stencil formats, supported back buffer formats, supported multisample types and last question 4) If D3DFMT_X8R8G8B8 and D3DFMT_A8R8G8B8 are both valid back buffer formats, then will what ever works on the non-alpha back buffer also work on the alpha back buffer? thanks

::: Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile [edited by - IFooBar on January 10, 2003 3:18:56 PM]

S1CA

169

S1CA

Jan 10, 2003 at 2:22 PM

The answer to all of those is: NO

or more completely "probably on your hardware and most other graphics hardware, but not guaranteed by the API or guaranteed to be the case on future hardware"

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

tok_junior

Jan 10, 2003 at 6:11 PM

Well, actually, on question 2 the answer is Yes afaik.
X8R8G8B8 and A8R8G8B8 is stored in the exact same way on the card.

--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

S1CA

169

S1CA

Jan 10, 2003 at 6:48 PM

quote:
Original post by tok_junior
Well, actually, on question 2 the answer is Yes afaik.
X8R8G8B8 and A8R8G8B8 is stored in the exact same way on the card.

The storage **might** be the same... on current hardware. What if the chip decides to store 8 bits of stencil or Z buffer information in the ''X'' bits? (entirely possible, some chips are aparently already treating each pixel as a 64bit piece of data combining the colour, alpha, z and stencil into a single "element").

My point though was more that the D3D API doesn''t make any rigid guarantees that it will work. The designers of future 3D chips are only constraining themselves to the documented parts of the common APIs. Assume nothing

.

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

IFooBar

Author

119

IFooBar

Jan 11, 2003 at 2:55 AM

ok. thanks. Though there is one other thing. In the directx caps viewer. They have everything arrnged differently then the how the framework arranges it''s stuff. for example in the caps viewer they put the conflicting multisample types with the render target formats, but in the framework the conflicting multisample''s are paired with depth/stencil formats. and as for my question number 2, in the caps viewer all the adapter formats are inside the HAL forlder. but again with the framework HAL is assigned per adapter format. So the differences between the caps viewer and how the framework handles stuff is confusing me.

BTW: when i say the framework I mean D3DEnumeration.cpp/.h

anyway thanks for the input.

:::Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.