[PATCH 3/3] d3d9/tests: Improve testing of display formats and IDirect3D9_CheckDeviceType().
hverbeet at gmail.com
Mon Jan 27 12:11:01 CST 2014
On 27 January 2014 17:28, Ken Thomases <ken at codeweavers.com> wrote:
>> device.c:2316: Display format D3DFMT_X1R5G5B5 not supported
> means that IDirect3D9_GetAdapterModeCount(…, D3DFMT_X1R5G5B5) returned 0 modes. This:
MSDN for IDirect3D9_EnumAdapterModes() also seems to hint that
D3DFMT_R5G6B5, D3DFMT_X1R5G5B5 and D3DFMT_A1R5G5B5 are supposed to be
equivalent as far as display modes are concerned. This may be a quirk
of the AMD driver, but I don't have a lot of Windows or NVIDIA systems
to really compare.
> Do you think I should just ignore "nmodes" for windowed mode? It seems like the test is saying that CheckDeviceType() doesn't care whether the display format is supported for windowed mode. Of course, it's unreliable to extrapolate from a single data point.
I'm not sure.
Come to think about it, the broken() in this test is perhaps a bit
overly broad as well.
>> … and produces quite a lot of output in general
> Yeah, although there was a corresponding trace() in the X8R8G8B8 loop in the old code. Since I was consolidating multiple loops into one, I took the union of the features of all of the loops. I can reduce that if you like.
Yeah, it's nice for debugging now, but in the general case it just
makes it harder to spot failures.
More information about the wine-devel