On 29 January 2016 at 00:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
+ if (sample_count > 32) + return E_FAIL; I think that's D3D11_MAX_MULTISAMPLE_SAMPLE_COUNT.
+ 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.
+HRESULT CDECL wined3d_device_check_multisample_quality_levels(const struct wined3d_device *device, + enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type, + DWORD *quality_level_count) I don't think we really want to introduce a new entry point for this. I guess the issue is that we can't get at the wined3d object that created the device from inside d3d11, but I think it would be preferable to do something about that instead. It seems likely that CheckFeatureSupport() and CheckFormatSupport() would run into this as well.