http://bugs.winehq.org/show_bug.cgi?id=38581 Doug Johnson <dougvj@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dougvj@gmail.com --- Comment #42 from Doug Johnson <dougvj@gmail.com> --- Created attachment 80734 --> http://bugs.winehq.org/attachment.cgi?id=80734 Screenshot with transparency working Surfaces are not palletized but are RGB555 (Looked up FourCC code on surface pixelformat struct, which is 0, and the bits is 16, which means rgb555, see https://fourcc.org/pixel-format/rgb-bi_rgb/) These are the color keys I captured and their respective rgb values (after proper masking): 0x0 0x1f 0x5cec 0x6ce7 0x7e0 0x7ff 0xfffff81f 0xffffffff (0, 0, 0) (0, 0, 255) (189, 57, 98) (222, 57, 57) (8, 255, 0) (8, 255, 255) (246, 0, 255) -> Magenta! (255, 255, 255) Magenta is the failing color key, and it appears to be sign-extended for some bizarre reason So, I made this fix: @@ -5118,7 +5120,10 @@ static HRESULT ddraw_surface_set_color_key(struct ddraw_surface *surface, DWORD if (color_key) { - fixed_color_key.dwColorSpaceLowValue = fixed_color_key.dwColorSpaceHighValue = color_key->dwColorSpaceLowValue; + fixed_color_key.dwColorSpaceLowValue = fixed_color_key.dwColorSpaceHighValue = (color_key->dwColorSpaceLowValue & + (surface->surface_desc.ddpfPixelFormat.dwRBitMask | + surface->surface_desc.ddpfPixelFormat.dwGBitMask | + surface->surface_desc.ddpfPixelFormat.dwBBitMask )); switch (flags & ~DDCKEY_COLORSPACE) And, Voila! I am working on a test case to make sure this fix doesn't cause problems for other pixel format types and palette indices. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.