[PATCH] wined3d: wined3d_check_surface_capability return TRUE for surfaces with WINED3DFMT_FLAG_TEXTURE.

[Henri Verbeet]

On 5 September 2017 at 18:31, Lorenzo Ferrillo <lorenzofersteam at live.it> wrote:
> Which issue was  caused by relying on WINED3DFMT_FLAG_TEXTURE ?
>  I admit that I know nothing about directx or wined3d (and the code is not
> much documented. ).  Also considering that this specific control wasn't the
> only thing that was removed in that commit.
> I'd certianly like to learn a better way to deal with these issues. My
> studying of the wine source code started recently.
> Thanks.
>
Special formats like "RESZ", "NVDB" and "INST" can't be used to create
resources, but are instead used to indicate that drivers support
specific vendor extensions. In wined3d, these formats have
WINED3DFMT_FLAG_TEXTURE set, but don't have an internal format, since
they can't be used to create textures. The reason they have
WINED3DFMT_FLAG_TEXTURE set is mostly historic.

There also exist formats like e.g. YUV and P8 formats that can't be
used for texturing, but can be used for e.g. blits. Those have an
internal format, but don't have WINED3DFMT_FLAG_TEXTURE. The intention
of commit 8c98be4791f18f31b04a4a0f08d18979aa0d06df was to report those
formats as supported for surfaces, without calling into the blitter,
since that wouldn't work with subsequent commits, and was a little
questionable to begin with. Unfortunately that commit failed to take
the "extension" formats into account. Instead of restoring the
WINED3DFMT_FLAG_TEXTURE check, I think it would make more sense to
introduce a dedicated flag for those extension formats, and check that
instead.