[PATCH 1/6] d3d11: Implement d3d11_device_CheckMultisampleQualityLevels().

Matteo Bruni matteo.mystral at gmail.com
Wed Feb 3 13:10:04 CST 2016


2016-01-29 15:35 GMT+01:00 Henri Verbeet <hverbeet at gmail.com>:
> On 29 January 2016 at 00:51, Matteo Bruni <mbruni at codeweavers.com> wrote:
>> +    if (sample_count > 16)
>> +    {
>> +        FIXME("sample_count %u not handled yet.\n", sample_count);
>> +        return S_OK;
>> +    }
> I think that belongs in wined3d_check_device_multisample_type().
>
>> +    hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device,
>> +            wined3dformat_from_dxgi_format(format), sample_count, quality_level_count);
>> +    if (hr == WINED3DERR_INVALIDCALL)
>> +        return E_INVALIDARG;
>> +    if (hr == WINED3DERR_NOTAVAILABLE)
>> +        return S_OK;
> This is fine, but the d3d10+ API probably makes more sense in the long
> run. I.e., eventually we'd want to handle the difference in d3d8/9
> instead.

Yes, agreed, but handling the (d3d9-only) D3DMULTISAMPLE_NONMASKABLE
setting outside of wined3d seems to be a bit awkward. Other possible
options might be to keep the non-maskable option (and the enum
wined3d_multisample_type instead of the sample count) but otherwise
follow the d3d10+ API or simply return the multisample_types field
from struct wined3d_format and let the clients deal with it.

Mostly for curiosity I had a quick look at the d3d12 API on MSDN, at a
first glance it mostly resembles the d3d10 interface except that there
isn't a separate function for it i.e. it's been merged into
CheckFeatureSupport().

Anyway, for the time being I've kept the current API although I can
certainly change that.



More information about the wine-devel mailing list