Am 08.01.2014 um 10:56 schrieb Henri Verbeet hverbeet@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@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@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@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@gmail.com:
On 8 January 2014 12:40, Stefan Dösinger stefandoesinger@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.
On 8 January 2014 14:30, Stefan Dösinger stefandoesinger@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.
-
Henri Verbeet -
Stefan Dösinger