On 4 January 2016 at 22:37, Stefan Dösinger stefandoesinger@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.