Quote Originally Posted by Chris View Post
Being able to use S3TC, and being able to use the textures *properly*, are two different things. The advantage of S3TC is that they take up about 1/4th less space on the card than the uncompressed counterparts and are decompressed on-the-fly, allowing more/larger textures to be used and used faster (since less data needs to be read). If you have to decompress them on load, you gain nothing.
Internally, S3TC is used whether or not you have the code that touches on the patent- if the textures were already formatted that way. It does no good to have it reside in the driver to decompress (which is where the use on the card would entail...) and put it to another, uncompressed buffer for the texture in question. The problem in "enabling" it is that for you to be completely correct, you need to be able to GENERATE the compressed textures from uncompressed ones- which is wherein lies the problem with the drivers. If you have pre-generated textures in S3TC, you can DO S3TC with the stuff we have in hand right now- patent's covered, they had to buy the rights to do the hardware decode. It's the on-the-fly generation part that's the gotcha.