Hacker News new | past | comments | ask | show | jobs | submit login

> But for some programs (e.g. large video games), preloading all your assets is very common and decoding speed can be crucial.

Those games typically don't need lossless image compression. There are much better (and faster) algorithms for lossy texture compression, many of which can even be decoded directly by the GPU. The S3TC family is one popular example.

One interesting commercial product in this space is Oodle Texture: http://www.radgametools.com/oodletexture.htm




Lossy causes some issues with normal maps, so QOI seems good for those cases where lossless is preferred to balance loading (and streamed loading) performance and space use, but yes, in general S3TC is good for sRGB color textures in PC games.

Using a lossy hardware compression (like S3TC) that's natively supported by the hardware is especially a good way to save on GPU RAM! Double the texture resolution for free, essentially.


It's true that lossless is often not the best approach, although it's worth pointing out that anyone can implement Quite OK while both the approaches you mention are not really friendly to open source.


S3TC is patent-free as of October 2017, and is implemented in open-source graphics drivers.


Are the best available compressors for the format open source as well? That would be news to me, although I admit I haven't looked into the format in quite some time.

More generally, my point about video games was just that you can frequently cut their size by 50-75% just by turning on file compression on the game directory. Developers are obviously missing some easy wins in this area - including huge wins with lossless compression alone.


basisu (Binomial's Basis Universal GPU Texture Codec) is pretty much state of the art here. Open source, offers excellent compression and very quickly decodes to pretty much all GPU native formats.


basisu is really impressive, but it’s not perfect for all use cases.

I tried using it in a WebGL game, but found that a) decoding was too slow, and b) the quality was too low.

PNG is much bigger, so you’d think it wouldn’t be good for a web game, but once an image has been downloaded and cached, the most important factor is the decode-and-upload time. On the web, PNG and JPEG handily beat basisu there.

In a different situation, basisu could have worked out for me. On native rather than web, maybe the decode time would have been fine. With more photographic rather than geometric assets, maybe the quality would have been fine.


The advantage of using a native hardware compression format is that you save on GPU RAM, which is especially useful for web which may display on mobile systems.


That’s true, but it’s a trade-off rather than a straight win. Hardware formats do have a few disadvantages:

1. Larger size on disk

2. Reduced quality at all MIP levels

3. Complexity of each platform wanting its own special format.

Basis fixes 1 (by adding an extra layer of compression) and 3 (by transcoding to almost any format at load time). But it doesn’t fix 2, and it adds another downside -- decompressing and transcoding is relatively slow.


PNG/JPEG are not natively understood by GPUs, though. GPUs have compressed formats they natively understand, and basisu can transcode to them quickly. You'll be burning a lot more GPU texture memory as you'll be asking the GPU store raw image data instead of compressed image data.


Look at Rich Geldreich's bc7enc_rdo.


Use Universal Basis




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: