[PATCH 2/3] d3dx9: Return D3DERR_NOTAVAILABLE from D3DXCreateVolumeTextureFromFileInMemoryEx() for _RENDERTARGET or _DEPTHSTENCIL usage.

[Matteo Bruni]

On Fri, Oct 25, 2019 at 6:11 PM Henri Verbeet <hverbeet at gmail.com> wrote:
>
> On Fri, 25 Oct 2019 at 17:08, Paul Gofman <gofmanp at gmail.com> wrote:
> > diff --git a/dlls/d3dx9_36/texture.c b/dlls/d3dx9_36/texture.c
> > index 12cb2f3983..d71682117c 100644
> > --- a/dlls/d3dx9_36/texture.c
> > +++ b/dlls/d3dx9_36/texture.c
> > @@ -1149,6 +1149,9 @@ HRESULT WINAPI D3DXCreateVolumeTextureFromFileInMemoryEx(IDirect3DDevice9 *devic
> >      if (!device || !data || !data_size || !volume_texture)
> >          return D3DERR_INVALIDCALL;
> >
> > +    if (usage & (D3DUSAGE_RENDERTARGET | D3DUSAGE_DEPTHSTENCIL))
> > +        return D3DERR_NOTAVAILABLE;
> > +
> Does this really need to be explicitly handled in d3dx9? You can't use
> 3D textures as render targets in d3d9, see also volumetexture_init().
>
> Going by D3DERR_NOTAVAILABLE, I suspect the real issue is that
> D3DXCheckVolumeTextureRequirements() should catch this through
> CheckDeviceFormat(), but it currently doesn't because it goes through
> D3DXCheckTextureRequirements(), which calls CheckDeviceFormat() with
> D3DRTYPE_TEXTURE instead of D3DRTYPE_VOLUMETEXTURE. The underlying
> assumption that format capabilities are the same for 2D and 3D
> resources isn't quite true.

Yes, that's one of the traps lying around in d3dx9. I'm sure there are more...