-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-08-22 12:32, schrieb Henri Verbeet:
- if (desc.pool != WINED3D_POOL_DEFAULT && desc.pool != WINED3D_POOL_SYSTEM_MEM)
- {
WARN("Color-fill not allowed on surfaces in pool %#x.\n", desc.pool);
return D3DERR_INVALIDCALL;
- }
I realize that this just keeps existing code in place, but as far as I can see this check is redundant. There's already a somewhat strange check right above this one that tests if the surface is a render target or in WINED3D_POOL_DEFAULT. Unless I missed a way to create a non-default pool render target testing only for WINED3D_POOL_DEFAULT should be enough.
The patch also works only as long as we keep the D3DUSAGE_RENDERTARGET check in wined3d_device_set_rendertarget_view and not move it to wined3d_rendertarget_view_create. Is that your intention?
On 22 August 2014 13:14, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2014-08-22 12:32, schrieb Henri Verbeet:
- if (desc.pool != WINED3D_POOL_DEFAULT && desc.pool != WINED3D_POOL_SYSTEM_MEM)
- {
WARN("Color-fill not allowed on surfaces in pool %#x.\n", desc.pool);
return D3DERR_INVALIDCALL;
- }
I realize that this just keeps existing code in place, but as far as I can see this check is redundant. There's already a somewhat strange check right above this one that tests if the surface is a render target or in WINED3D_POOL_DEFAULT. Unless I missed a way to create a non-default pool render target testing only for WINED3D_POOL_DEFAULT should be enough.
It's probably a bug that we don't enforce rendertargets to be in the default pool, but there's currently nothing to prevent you from creating e.g. a texture with D3DUSAGE_RENDERTARGET and D3DPOOL_MANAGED. You'll get a FIXME from surface_init(), but creation will succeed.
The patch also works only as long as we keep the D3DUSAGE_RENDERTARGET check in wined3d_device_set_rendertarget_view and not move it to wined3d_rendertarget_view_create. Is that your intention?
Yes, at least for the time being. Moving that check wouldn't work well for depth/stencil views, and I haven't quite decided yet if the blitter interface should use views or just a resource + index, although I'm leaning towards the latter.