Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[pre-ll] Add BC1 (DXT1), BC3 (DXT5) S3TC texture formats #2733
Adds compressed BC1 & BC3 image formats for gfx_device_gl/opengl. Image data is expected to be already compressed.
Each supports rgb & srgb.
I've been investigating texture compression to reduce VRAM usage in my game Robo Instructus. For this end I wanted more efficient 8-bit channel rgb & rgba storage with good opengl driver & hardware support.
S3TC is old and the best supported compression available (see https://opengl.gpuinfo.org/listcompressedformats.php). Patent issues are now history (see https://en.wikipedia.org/wiki/S3_Texture_Compression). For testing I used GPUOpen-Tools/Compressonator for encoding, which is quite fast and seems to have decent quality.
I didn't include BC2/DXT3, or BC7 as I don't plan to use it. However, support for this format can be trivially added on top of this change.
I did investigate ETC2 compression too which is newer yet features wide support. However, I found actual hardware support for ETC2 on the desktop is much more limited that it may appear. It was a bit of a downer to see no VRAM usage reduction on my polaris RX480 when using ETC2 compressed textures. ETC2 formats also didn't seem to work without the
For the above reasons I decided against using ETC2 in the game & adding it here. Note though; similarly to BC2, this change will make it simpler to support ETC2 formats in future if desired.
Robo Instructus is an OpenGL 3.3 game so I'm not personally interested in other API support for these formats at the moment. Also considering pre-ll code is in support mode, and unsupported formats already seem common I thought it wasn't a big deal not supporting other APIs.
I went with Vulkan naming style ie prefix with BC1. Maybe you guys have a better idea of what you'd like to name the formats. I'm not hugely fussed here.
Ok the extensions are in gfx_gl and documentation for the new formats is there. I don't see only supporting OpenGL as an issue, as other backends could be added later anyway.
I've been using these formats for all the textures in Robo Instructus for the last two beta updates and everything seems fine with my testers.
Let me know if you have better ideas for the format names, otherwise this is ready to go I think.
@alexheretic unfortunately, no. The format stuff is re-exported from
Saying that, it would only be breaking for code that has a comprehensive match statement across the surface types, which I don't know any (for pre-ll), so in practice this would be a breaking change, especially considering that 0.18 was released relatively recent and hasn't gotten that many users.
Yes I'd have thought the only users matching on all surface types would be the gfx backends themselves. That along with the fairly recent v0.18 version I'd also favour sticking with 0.18 & yanking on complaint.
But either way will work in the end.