[PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().

[Henri Verbeet]

On 4 January 2016 at 22:37, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
> I asked Riccardo about this init change in an earlier version, and afair he said creating cubemaps without a device crashes on some Windows drivers. I can't find the exchange in the archives, it was probably on IRC. Riccardo, do you remember why you made this change?
>
If it was for 64-bit ddraw, it was probably fixed by
2dca999e3393cb039d2aabebf7c83328925ab30e.

>> -        if ((test_data[i].caps2 & DDSCAPS2_CUBEMAP)
>> -                && !(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP))
>> -        {
>> -            skip("Device does not support cubemaps.\n");
>> -            continue;
>> -        }
> You're creating cubemaps without checking for support now.
>
Yeah. I think that's either just supposed to work, or needs a
different kind of check, like e.g. "hal_caps.ddsCaps.dwCaps2 &
DDSCAPS2_CUBEMAP". Creating cubemaps works on the testbots without 3D
support at least, and I have the impression that
"device_desc.dpcTriCaps.dwTextureCaps" is for checking rendering
support. Note that different device types can be created from the same
ddraw interface, so it isn't necessarily clear that if e.g. a
TnLHalDevice can't render cubemaps a RGBDevice wouldn't be able to
either.

Unfortunately I don't have hardware without cubemap support, so I
suppose we'll have to wait for results from test.winehq.org, if any.