Re: [5/5] ddraw: Emulate a 24 bit depth format without stencil or padding
On 22 August 2011 21:16, Stefan Dösinger <stefandoesinger(a)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(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOUtpOAAoJEN0/YqbEcdMwDgkP/AyRXdrfJeKJymAET+WAtKAo vD0shbn3Ke8IMCHpHQSQMs3FqXWze8x2brQUPWdIhw8Vcz6j0gR0TUwxjM35YUVQ mYiTH2qlq69TIMUFJDg4Df693tTE+NropbyzjfvXHhcRQc4bRaF9xFRIj4/ATtE9 98zU6SomKw2oQ2g8oNg2knLOIuRhQHhvYRg4o7e4RXrZfL1TrM5P6yuUDzdEBwRk TQJdKcwCgJ0as/WwJqdb49uTBtYXyc3HljyJOFcBUChBiC2Kp3s9gq8DcxN1/v8o KuZHfW3w62oElvLzoRoe6hk6RmDu02of6XpW4iQfA/rqBWeOyzzxqAxoT3KBRvTy CXEifQatY7B4RvzfBXTBZTafs4LG8zYFah2IGAGCTMEUKIOsXYNf9KxJHH4EcGXv TAMs15VE662NQji6FlGZbTIcBCdG+IvLmdgvIwEMJM0xbNpKHNZZDU2LdDuJNQCf vg9B9KGPLB1wVr021Gi3VyM/eI9uGwCE2dTkxeJg+oDIQnLQy17OYGb9b+9Y+kv5 v4fexE7lCM++aCv75/cQyASK7E9TGEg6v50r2Ry2KL1PpnA8y1cxKt41vP1Oh4fr 0GHVwCY58xCqfxRzHsIaZBN95Tne0aDMijFneYmfuVnuRxoGuWEip1mEfNUfVDzs XsuJZCY1v/hq62ohOsDX =/DEZ -----END PGP SIGNATURE-----
On 23 August 2011 00:38, Stefan Dösinger <stefandoesinger(a)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(a)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(a)gmx.at> wrote:
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.
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.
participants (2)
-
Henri Verbeet -
Stefan Dösinger