On Thu Jul 10 15:36:26 2025 +0000, Connor McAdams wrote:
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 #endifway 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. :)
Actually, it looks like the actual values of the `D3DXERR` HRESULTs are the same across each API, the difference I was thinking of was `D3DERR_NOTFOUND`/`D3D10_ERROR_FILE_NOT_FOUND`/`D3D11_ERROR_FILE_NOT_FOUND`. Those do have different values across each API and would likely require a helper function or `#ifdef`s to avoid that.
The `D3DXERR` values are shared across all d3dx versions, as are the filter flag values. So, IMO those wouldn't benefit as much from a helper function here.