Closed leiradel closed 1 year ago
IIRC sokol_gfx.h actually had RGB565 support in the past as optional format, but it wasn't supported well enough to justify keeping it in (the current list of pixel formats is basically what WebGPU supports, and they did extensive research what formats are supported across GPUs and 3D APIs, and this doesn't include any of the packed 16-bit formats: https://www.w3.org/TR/webgpu/#texture-formats
D3D11 and Metal only have BGR565 formats not RGB565 (D3D11 only since D3D11.1, while sokol_gfx.h currently uses D3D11.0, and Metal only supports it on devices with Apple GPU, but not on Intel Macs). On GL you might hit a software-conversion step on texture upload if the input format doesn't match a supported hardware format).
TL;DR: not a fan of adding RGB565 support back in :)
Nah, that's a totally valid reason. I thought RGB565 was universally supported. Maybe I can come up with a shader to get two pixels from RG and two from BA to avoid the CPU conversion, although I'm not sure it would make a difference in the grand scheme of things, given the software framebuffers are small.
Ok, I'll close this then as 'not planned' :)
Some system that I emulate generate video frames with that format. It would be great if I could create a texture with that format and update the pixels directly. Right know I have to convert the formats in software before updating the texture.
I could contribute something for OpenGL, but I wouldn't know what to do WRT the other backends.