Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes
On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote:
Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to start. --- dlls/wined3d/directx.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-)
This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only. You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had.
Chris Robinson wrote:
On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote:
Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to start. --- dlls/wined3d/directx.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-)
This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29
D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only.
You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had.
I haven't really tested this patch much and I don't expect it to be applied. There was just a regression that prevented AOE from starting due to it not finding an 8bpp mode. The regression was caused by this patch: http://www.winehq.com/pipermail/wine-cvs/2007-February/030394.html BTW.
You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had. You can change WineD3D to allow WINED3DFMT_P8, but you have to modify d3d8 and d3d9 to filter it out. This is the correct approach then. Injecting P8 in ddraw will work too, but it is not correct from the design point of view(since then wined3d says "I can't do that", and ddraw says "But I insist you can do it"
On Saturday 31 March 2007 02:25:52 am you wrote:
You can change WineD3D to allow WINED3DFMT_P8, but you have to modify d3d8 and d3d9 to filter it out. This is the correct approach then. Injecting P8 in ddraw will work too, but it is not correct from the design point of view(since then wined3d says "I can't do that", and ddraw says "But I insist you can do it"
How about the attached patch? If not given an explicit mode, DDraw will loop over known good formats and not pass WINED3DFMT_UNKNOWN to WineD3D at all. Someone can then fix D3D8 to not pass it either, then fix WineD3D to not have special handling for enumerating WINED3DFMT_UNKNOWN. That should fix the current DDraw problem fine, and not immediately risk breaking D3D8 in the process. Vitaly Budovski, does this fix the problem as well?
Chris Robinson wrote:
On Saturday 31 March 2007 02:25:52 am you wrote:
You can change WineD3D to allow WINED3DFMT_P8, but you have to modify d3d8 and d3d9 to filter it out. This is the correct approach then. Injecting P8 in ddraw will work too, but it is not correct from the design point of view(since then wined3d says "I can't do that", and ddraw says "But I insist you can do it"
How about the attached patch? If not given an explicit mode, DDraw will loop over known good formats and not pass WINED3DFMT_UNKNOWN to WineD3D at all. Someone can then fix D3D8 to not pass it either, then fix WineD3D to not have special handling for enumerating WINED3DFMT_UNKNOWN. That should fix the current DDraw problem fine, and not immediately risk breaking D3D8 in the process.
Vitaly Budovski, does this fix the problem as well?
I think that's probably a good idea. Handling everything in WINED3DFMT_UNKNOWN causes far too many problems. This does fix the regression in AOE (as long as you add the WINED3DFMT_P8 format to the switch statements). Thanks Chris!
participants (3)
-
Chris Robinson -
Stefan Dösinger -
Vitaly Budovski