Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/surface.c:
return E_OUTOFMEMORY;
- hr = IWICBitmapFrameDecode_CopyPixels(bitmap_frame, NULL, row_pitch, slice_pitch, buffer);
- hr = IWICBitmapFrameDecode_GetPixelFormat(bitmap_frame, &src_pixel_format); if (FAILED(hr))
goto exit;- /*
* Needs conversion. Ignore D3DFMT_P8 because multiple different WIC* formats map to D3DFMT_P8, and they don't require conversion.*/- if (memcmp(&src_pixel_format, dst_pixel_format, sizeof(*dst_pixel_format)) && image->format != D3DFMT_P8) {
free(buffer);return hr;
hr = IWICImagingFactory_CreateFormatConverter(wic_factory, &wic_converter);
Okay, now for a more architectural point... I'm not particularly keen about making use of WIC conversion stuff. Among other things, d3dx9 has flags to control filtering and such and those don't really map to WIC's. Currently we don't implement most of them, to be fair, but using WIC doesn't seem like a move in the right direction.
Could we reasonably use the existing d3dx9 machinery (`d3dx_load_pixels_from_pixels()` and such) to convert the image to the desired format? Are we going to get problematic formats out of WIC, or is there some other issue that makes that complicated?
For the two relevant formats in this MR, I expect the 24 -> 32 bpp conversion to already work. The 48 -> 64 bpp one is tricky because we'd need a new `formats[]` entry and there is no suitable `D3DFORMAT` for a 3 channel 16 bpc UNORM format. But that's basically a self-imposed limitation, nothing forces us to use `D3DFORMAT` to identify formats internally.
Looking at your branches, I see that you end up with an `enum d3dx_pixel_format_id` to identify formats in d3dx, which should indirectly fix this. I'd suggest to simply defer converting from those "unrepresentable" formats (or maybe this whole conversion business entirely) to some time after `enum d3dx_pixel_format_id` is introduced, unless you really need it sooner.