-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-04-30 um 11:09 schrieb Henri Verbeet:
That's not wrong as such, but it is pretty arbitrary. WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the component masks and sizes, it shouldn't depend on the resource type. Once we'll get proper integer types for d3d10, it will probably make sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an enumeration instead, perhaps even per-component.
Yeah, as I said in the mail that introduced the split, I could move things like FLAG_FLOAT and FLAG_GETDC into a separate, resource-independent flags field. Or we just keep it the way it is and track things like float per component later on.
I'm using WINED3D_GL_RES_TYPE_RB instead of 2D here because this function is doing checks for the onscreen WGL buffer. It's not the same as a renderbuffer but it has the similar limitations and abilities that I don't see a reason to add a separate WGL buffer resource type at this point.
if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET)&& (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)))This is actually wrong. At least, as long as we don't allow (plain) renderbuffers to be used for FBO attachments. There's nothing in the spec that says formats that can be used for color rendering with renderbuffers have to be available for color rendering with textures as well, and in fact that's much of the reason for this patch set.
I'm not really making a distinction between "is this format a depth stencil format" and "Can a resource with this type and format be created". Maybe we should add some WINED3DFMT_FLAG_SUPPORTED flag and check it in resource_init regardless of what the app requests?
WINED3DFMT_FLAG_TEXTURE doesn't work for this purpose because when the application creates a non-texture depth stencil surface (or even the implicit depth stencil) we have no reason to require WINED3DFMT_FLAG_TEXTURE.