Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.
Am 08.01.2014 um 10:56 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>:
+ for (i = 0; i < 7; ++i) + { + hr = IDirectDrawSurface_GetAttachedSurface(mipmap, &caps, &tmp); + ok(SUCCEEDED(hr), "Failed to get attached surface, i %u, hr %#x.\n", i, hr); + hr = IDirectDrawSurface_GetColorKey(tmp, DDCKEY_SRCBLT, &color_key); + ok(hr == DDERR_NOCOLORKEY, "Got unexpected hr %#x, i %u.\n", hr, i); + IDirectDrawSurface_Release(mipmap); + mipmap = tmp; + } What is the 3D rendering and blitting behavior of the mipmap sublevels? Does an application have to set the color key on all surfaces to get proper color keying on a mipmapped texture, or do the sublevels use the color key from the root surface?
On 8 January 2014 11:46, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
What is the 3D rendering and blitting behavior of the mipmap sublevels? Does an application have to set the color key on all surfaces to get proper color keying on a mipmapped texture, or do the sublevels use the color key from the root surface?
I don't really know, but I suspect I'll find out soon enough if this patch breaks something there. I somewhat suspect it'll use the root color key for 3D rendering and the key from individual surfaces for blits. The current code is just wrong either way though.
Am 08.01.2014 um 12:01 schrieb Henri Verbeet <hverbeet(a)gmail.com>:
I don't really know, but I suspect I'll find out soon enough if this patch breaks something there. Ok, your call.
I somewhat suspect it'll use the root color key for 3D rendering and the key from individual surfaces for blits. The current code is just wrong either way though. Did you test if it is possible to set a color key on a mipmap sublevel?
On 8 January 2014 12:40, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
I somewhat suspect it'll use the root color key for 3D rendering and the key from individual surfaces for blits. The current code is just wrong either way though. Did you test if it is possible to set a color key on a mipmap sublevel?
I just did, looks like it returns DDERR_NOTONMIPMAPSUBLEVEL.
Am 08.01.2014 um 13:04 schrieb Henri Verbeet <hverbeet(a)gmail.com>:
On 8 January 2014 12:40, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
I somewhat suspect it'll use the root color key for 3D rendering and the key from individual surfaces for blits. The current code is just wrong either way though. Did you test if it is possible to set a color key on a mipmap sublevel?
I just did, looks like it returns DDERR_NOTONMIPMAPSUBLEVEL. I guess that answers where the color keys for draws and blits involving mipmaps come from - assuming those operations even have a defined result.
I’ll test Prince of Persia 3D once I’m back on Linux with your patches. This game uses color keys, and I am fairly sure it uses mipmapped textures. I don’t know if it combines those two though.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-08 13:13, schrieb Stefan Dösinger:
I’ll test Prince of Persia 3D once I’m back on Linux with your patches. This game uses color keys, and I am fairly sure it uses mipmapped textures. I don’t know if it combines those two though. Patch 1 breaks Prince of Persia 3D (Wine appdb id 3743). It doesn't break quite in the way I expected though. Instead of gates with broken transparency it draws a mostly black screen, with only torch flames visible.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzVLpAAoJEN0/YqbEcdMw+noP/0TSK10PmzDd8NSARH6K7itd C664s6XuAhokmFSrAVD5chis3o2gvjoay949Iz59w2N8DIXFnqNdPsNy+8zbfbWz fwPDQRJX8+3ueBXiz34E2c3ocM/iyZ7VGB+2jkMZFh5y8GSNdwR5BjbKH3Hzx1W+ gpcg/LD/YLFtE3yDH0Mwp5rknQfzBuBEqfGidUCg7/oUsDneomDd6j0FTj4I44j3 hkKHufSrO3phmTL9XEwG47s2acvWbMhq1s3aCl53iBTvRfxh8fT/lpGGipu0XKE5 fexxM9aqCAcopctaZZcFiycLgOvhJOJcnckv7an2m4j0kdZnq0Y/ZWlMjaDi/7Tn wbddfkmig73+TQ72uavkkpaUvNZLZorXULK3PNcorAlMaQ3BmHgRZVHQua/kp4Ku 1OUkCM/GpianKZKanP0b0gVWrloW0rgBvcz4jOUTsLkZ1Rrf2qqdIt2KFzXO8a2E 2pTNhu3tdMCahYUQGYj5asCWmJMweSV5T61rLPl+QSUm6ZSIq4xulOd++vTp38xU 5qNDHJ81oROuoMEqE1T4xNrRtPWZKibsRx9SRnzcCj/+e+ePTCxMjIs/kA7uMODr KB/FcRuy/ByNpWl3g9RXqFh5oVPWELBO+XZrRg/fsnjqsYeL3YR9sP6gn4vHwsc4 QrrV7isa0jsR/MtIYAiW =vbGu -----END PGP SIGNATURE-----
On 8 January 2014 14:30, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am 2014-01-08 13:13, schrieb Stefan Dösinger:
I’ll test Prince of Persia 3D once I’m back on Linux with your patches. This game uses color keys, and I am fairly sure it uses mipmapped textures. I don’t know if it combines those two though. Patch 1 breaks Prince of Persia 3D (Wine appdb id 3743). It doesn't break quite in the way I expected though. Instead of gates with broken transparency it draws a mostly black screen, with only torch flames visible.
It's probably best to hold of on at least the first two patches in this series then.
participants (2)
-
Henri Verbeet -
Stefan Dösinger