On Fri, Oct 25, 2019 at 6:11 PM Henri Verbeet hverbeet@gmail.com wrote:
On Fri, 25 Oct 2019 at 17:08, Paul Gofman gofmanp@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...