Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Which tools are considered best-quality for compressing textures for use in OpenGL? Which can be used from the Linux commandline?

And which lossless compressors give good ratio/speed on compressed textures?

(I see that Skyrim's BSA archives are typically only half the size of the DDSes they contain)

share|improve this question

You'll usually find the graphics card manufacturers provide decent tools for compression textures, such as Nvidia here. These seem to be supported on multiple platforms.

For hardware accelerated rendering you'll not find any lossless formats supported that offer any compression. The most popular current formats supported for example by graphics cards under DirectX are DXT1/3/5 for images, DXTN for normal maps. I don't use OpenGL but I'd expect these to be supported even if called something slightly different.

I've typically seen DXT textures zip to about half their original size, so it's possible just using zlib will get you the same end result (then decompress before uploading to the gfx hardware).

share|improve this answer

Compressed textures always(*) have fixed compression ratios. Basically all of the formats I've seen take a tile of texels (such as 4x4) and store just enough information to regenerate the tile, or something that resembles that tile closely enough. Comparing different compression methods you have a tradeoff between blurriness and noisiness, but the basic principles (patented, of course) seem to be the same everywhere.

Paletted textures can also be seen as a primitive compression method.

The positive side of these kinds of compression is that it's (relatively) easy to build hardware that can perform random access reads from it. If you'd store your textures as PNGs or JPGs in memory, you'd have to decompress, on average, 50% of the image on every texture fetch. That's just not feasible =)

Due to these limitations, the "compressed" textures can be compressed further with traditional compression methods, like ZLIB

(*) today, at least. Who knows, maybe someone will think of something new.

share|improve this answer
Spot on; so the question is, which tools do the best job of minimising artifacts from the compression of the texture, and what compression algorithms give the best decompression-speed to compression-ratios for compressed textures? LZO vs ZLIB vs anything else? – Will Feb 13 '12 at 10:15
I don't have enough experience with various tools for the texture compression, which is why I didn't touch that part in my answer - I've just used ATIs compressonator and been happy with the result. But I'm afraid the answer depends a lot on your source data and actual requirements. As to LZO vs ZLIB vs others, I'd say, if ZLIB is good enough, just use it and move on to something more important; if it's not, then benchmark various things yourself with your real data. – Jari Komppa Feb 13 '12 at 10:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.