On Tue Jul 8 22:53:12 2025 +0000, Matteo Bruni wrote:
I haven't really checked how this looks in the end, so this might be a bad take on my part, but this cast kinda rings a bell. Here I'd expect a call to a (likely trivial) function converting from the d3dx-neutral `enum d3dx_image_file_format` to the d3dx9-specific `D3DXIMAGE_FILEFORMAT`. The function could also validate the values if need be (or make it simple to add that later on if not necessary right away).
Working on this a bit alongside the `ID3DXBuffer` issue has lead me to another question, how API agnostic do we want this helper source file to be?
Just as an example, each d3dx API has it's own `D3DXERR_INVALIDDATA`/`D3DX10_ERR_INVALID_DATA`/`D3DX11_ERR_INVALID_DATA`. Would you prefer to have our own `D3DX_ERROR_INVALID_DATA` error code that gets translated to the proper return code in each module with a `d3dx10_error_from_d3dx_error()` type of helper? Or should we go with the: ``` #if D3DX_D3D_VERSION == 10 #define D3DXERR_INVALIDDATA D3DX10_ERR_INVALID_DATA #endif ``` way of handling it?
This also relates a bit to the `D3DXIMAGE_FILEFORMAT` translation I'm doing here, in my later patches I have the image file formats unsupported by d3dx9 gated behind an API check, e.g you don't need a conversion function because calling into d3dx_helpers from d3dx9 would never successfully return a `D3DX10_IFF_GIF` for example. If the plan is to eventually use this outside of just our d3dx modules, which I think was mentioned in a discussion awhile ago, I think the agnostic approach makes more sense. I just wasn't sure if that's still something we were interested in. :)