On 22 August 2011 21:16, Stefan Dösinger stefandoesinger@gmx.at wrote:
- {WINED3DFMT_D24_UNORM, 0x0, 0x0, 0x0, 0x0, 4, 24, 0}, {WINED3DFMT_X8D24_UNORM, 0x0, 0x0, 0x0, 0x0, 4, 24, 0},
How is WINED3DFMT_D24_UNORM different from WINED3DFMT_X8D24_UNORM?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 22.08.2011 um 23:50 schrieb Henri Verbeet:
On 22 August 2011 21:16, Stefan Dösinger stefandoesinger@gmx.at wrote:
- {WINED3DFMT_D24_UNORM, 0x0, 0x0, 0x0, 0x0, 4, 24, 0}, {WINED3DFMT_X8D24_UNORM, 0x0, 0x0, 0x0, 0x0, 4, 24, 0},
How is WINED3DFMT_D24_UNORM different from WINED3DFMT_X8D24_UNORM?
It has a different application-visible ddraw format. The reason why I added the new format is that we have to convert in both directions and make sure we never tell the app a surface is D24X8 when it requested D24 or vice versa.
The alternative is to just change the current ddraw format of D24X8 into how my patch describes D24, but Windows actually advertises both formats, and I think we should do the same.
On 23 August 2011 00:38, Stefan Dösinger stefandoesinger@gmx.at wrote:
How is WINED3DFMT_D24_UNORM different from WINED3DFMT_X8D24_UNORM?
It has a different application-visible ddraw format.
I'm not sure that really justifies adding duplicate formats in wined3d. Also, calling this D24_UNORM violates wined3d format naming conventions. D24_UNORM would be a 3 byte format without padding.
Am 23.08.2011 um 00:53 schrieb Henri Verbeet:
On 23 August 2011 00:38, Stefan Dösinger stefandoesinger@gmx.at wrote:
How is WINED3DFMT_D24_UNORM different from WINED3DFMT_X8D24_UNORM?
It has a different application-visible ddraw format.
I'm not sure that really justifies adding duplicate formats in wined3d.
I see 3 alternatives:
1) Just change the ddraw pixelformat for X8D24. That would be covered by test results from some Windows HW(Radeon 9000M, WinXP), but we might break some games
2) Leave the status quo and blame bug 22434 on the app. That would be covered by test results from another Windows machine(Radeon X1600, WinXP)
3) Advertise both X8D24 versions if X8D24 is supported. Change ddraw_surface_init to make sure we don't have to convert back from the wined3d format. Then, once device_parent_create_depth_stencil is gone, we'll never convert wined3d depth formats to ddraw formats and we can support both X8D24 versions in ddraw without having two versions in wined3d.
Also, calling this D24_UNORM violates wined3d format naming conventions. D24_UNORM would be a 3 byte format without padding.
The ddraw format is already wrong. It claims to be 3 byte without padding, but as the test shows it actually has 1 padding byte. I think at the heart of this issue is that driver vendors couldn't agree how to represent a 3 byte depth with one byte padding format in a DDPIXELFORMAT structure.
On 23 August 2011 11:48, Stefan Dösinger stefandoesinger@gmx.at wrote:
- Advertise both X8D24 versions if X8D24 is supported.
Change ddraw_surface_init to make sure we don't have to convert back from the wined3d format. Then, once device_parent_create_depth_stencil is gone, we'll never convert wined3d depth formats to ddraw formats and we can support both X8D24 versions in ddraw without having two versions in wined3d.
That's probably the one you want anyway.
The ddraw format is already wrong. It claims to be 3 byte without padding, but as the test shows it actually has 1 padding byte. I think at the heart of this issue is that driver vendors couldn't agree how to represent a 3 byte depth with one byte padding format in a DDPIXELFORMAT structure.
Sure, but we can try to limit the damage somewhat.
-
Henri Verbeet -
Stefan Dösinger