On Fri Oct 25 06:45:02 2024 +0000, Connor McAdams wrote:
Yeah the 48->64bpp one is the trickier one, but ultimately solvable with `enum d3dx_pixel_format_id` patches. I can defer handling these until that stuff is upstream if that's preferable. I kind of intended on this to be a stop gap to solve some of the test todos in my surface to file saving patches. Once those were upstream, we could replace this with d3dx conversions instead. Or, I guess I could just do the `enum d3dx_pixel_format_id` patches prior to introducing the new saving code. My main concern with that is introducing an internal format ID seemed like it should be included with code sharing with d3dx10, which is why I initially moved to it. But, I guess having an image with a format that isn't represented by the existing `D3DFORMAT` IDs is also a motivation to introduce `enum d3dx_pixel_format_id` early.
I've uploaded a [branch](https://gitlab.winehq.org/cmcadams/wine/-/commits/WIP/d3dx9-new-fmt-id-v1) doing this without WIC conversion, let me know what you think :)
This avoids doing any conversion at all, it just reports a different format in the `D3DXIMAGE_INFO` structure than the format stored in the `d3dx_image` structure. If you think the approach in that branch is better, I can close this MR and open another one with the patches from that branch instead.