Shipping textures as PNGs is suboptimal

Oh but if you care about GPU support then I'm pretty sure https://github.com/GPUOpen-Tools/Compressonator has GPU support for BC(n) compression at least. Could rip those shaders out.

There's support for various HAP codecs in ffmpeg, VLC, etc, but I think support for HAP R is lacking. However HAP, HAP Alpha, HAP Q and HAP Q Alpha have wide support. They use DXT1/DXT3/DXT5/RGTC afaik.

Compared to your implementation, their addition of BC7 is quite recent, yet they did have support for alpha channels for probably a decade.

Yes, because they learnt it somewhere, for example, this article.

I don't get the negativity. Unless you work on bleeding edge R&D, every technique you know has been documented somewhere by someone else. So only the bleeding edge R&D people should write tech blogs?

Anecdotally, even I had known what texture compression is, this article still taught me something: the existence of Tacant View. It looks like quite a neat app.

Of course, they might have written the blog post with the intention of drawing attention to themselves and being noticed. These days, I can't bring myself to be upset about that sort of thing - if the content is good, better self-promotion than AI slop or hyping up the next hot investment vehicle.

Mostly web games I'd think, it's not uncommon to ship with png or jpg textures for small download size (but then you pay with in-memory size and texture sampling bandwidth - thus Basis Universal).

So if the texture is small I'd use u8, for a very large texture BC4 isn't a bad idea.

1. Fonts are a very small percent of most games’ storage and frame time, so there’s less motivation to compress them than other textures

2. Every pixel in a font is pretty intentional (unlike in, say, a brick texture) so I’d be hesitant to do anything lossy to it

I suspect that a single channel SDF for something like a UI shape would compress decently, but you could also just store it at a lower resolution instead since it’s a SDF. For SDF fonts I’d probably put them through the same asset pipeline but turn off the compression.

(Of course, if you try it out and find that in practice they look better compressed than downscaled, then you may as well go for it!)

[EDIT] a slightly higher level answer—you probably wouldn’t compress them, but you’d probably still use this workflow to go from my_font.ttf -> my_font_sdf.ktx2 or such.

In a way the hardware-compressed formats are paletted, they just use a different color palette for each 4x4 pixel block.

Having said that, for retro-style pixel art games traditional paletted textures might make sense, but when doing the color palette lookup in the pixel shader anyway you could also invent your own more flexible paletted encoding (like assigning a local color palette to each texture atlas tile).

Taking the time to learn about these sorts of compression methods is well worth it, as once you start loading assets of any appreciable scale or number, the savings in asset loading times can add up to be significant, turning what might have been a noticable jarring pause or stutter into something much less noticable.

Think about it, with hardware texture formats, not only are you not having to decode the PNG on the CPU, but you're also literally uploading less data to the GPU overall, since it can be transferred in a compressed form.

Using image formats for texture formats is amateur game development. PNG’s are fine for icons or UI or while you’re still trying to figure out what you’re doing. Once you know, you switch to a faster, no translation required, texture formats that load faster, support physical layers, compression, and are already in BGRA format.