-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-07-07 14:53, schrieb Henri Verbeet:
I don't think this fix is quite correct either. The drawable format is a wined3d internal thing, ddraw shouldn't have to know about it. In principle it wouldn't necessarily need to be WINED3DFMT_B8G8R8X8_UNORM either, for example if we ever get around to supporting 10 bpc display modes.
The drawable format is a winex11.drv / winemac.drv internal thing. wined3d calls ChangeDisplaySettingsEx to set an 8 bpp mode, but winex11 never really complies with that request. Wined3d depends on that non-compliance though. I guess wined3d P8 support currently fails on Windows.
In practice WINED3DFMT_B8G8R8X8_UNORM (or any other non-indexed RGB format) gives us the right answer. Ideally we'd make the emulated P8 mode explicit, but then we have to take care that applications that query the display mode with user32 don't break.
So I think the fix for this would need to be in wined3d_check_device_format(), or its utility functions.
I don't think so. Wined3d_check_device_format doesn't know what ddraw is going to do with the source surface. What if e.g. the application tries to create a YUY2 offscreen surface in P8 mode?
I'm open to the argument that blits between converted surfaces with the same format should be reported as supposed. But in that case we'd get the right answer for the wrong reason.