Scott Sellers: From a technical perspective, FXT1 is different from S3TC in a number of ways. Generally speaking, S3TC only uses one compression algorithm, and as a result, there are parts of images which may not compress without noticeable loss in image quality. FXT1, on the other hand, uses 4 different compression algorithms, and the specific compression algorithm is chosen at a block level to optimize visual quality. So, in terms of overall visual quality, FXT1 is superior to S3TC. Additionally, S3TC does not support 4-bit compressed textures with a multi-bit alpha component (used for smoke and fire, for example…), whereas FXT1 does, so for textures which include multi-bit alpha components FXT1 actually has twice the compression ratio of S3TC. Finally, FXT1 is superior to S3TC because it's an open source standard and will therefore be adopted much more widely by game developers, internet publishers, and hardware vendors much more readily than a proprietary technology such as S3TC.

In terms of larger texture compression capability, neither S3TC or FXT1 is dependent on the size of the texture for the compression algorithm, so both are well-suited for compressing high resolution textures.

Because FXT1 is an open standard, we feel it will be adopted readily by a wide class of developers. Many developers get wary of compression standards if they don't have the ability to use compress textures on their CD, in a variety of different 3D APIs, across multiple platforms, etc. S3TC has had difficult getting widespread adoption, we believe, because S3 will not allow S3TC to be used outside of the DirectX environment. So, developers naturally lean away from technology with such constraints. By making the technology publicly available with FXT1, the developers are not constrained in any way and as a result we expect very broad adoption and use of the technology.

Why do we support both S3TC and FXT1 in hardware? Well, first just to make this point clear because there has been some confusion about this, S3TC and FXT1 are fundamentally different compression algorithms and as a result you cannot effectively "emulate" one with software tricks if you only have support for one of them in hardware. So, we have different logic in the hardware to handle S3TC from FXT1, and visa-versa. That being said, we chose to support both S3TC and FXT1 because we not only want to have a broad, freely available compression standard (in the form of FXT1), but also want to be the hands-down best Direct3D accelerator out there. While S3TC is not being used in a large number of games right now, there are developers that are using it and we want to make sure our hardware is always THE best for running 3D games. Direct3D is the most popular 3D API in the world, and we try our best to make sure our hardware supports its feature set in its entirety.