Just how does FXT1 work? Well it uses four different algorithms. I'll leave it to 3dfx to explain these:
CC_MIXED (similar to other texture compression schemes): A 4x4 texel block is represented by two bits-per-texel for opaque textures. Additionally, each block has two 16-bit colors stored in an RGB 565 format. The two RGB 565 colors and two additional colors (created by interpolating between the two RGB 565 colors) form the primary colors for this texel block and its associated four color lookup table. A 2-bit index is used to determine which color from the lookup table will be used for each texel in the 4x4 block. Transparent textures are created by making one of the four colors transparent.
CC_HI (best for spatial resolution): A 4x8 texel block is represented by three bits-per-texel for opaque and transparent textures. Each block stores two 15-bit colors in an RGB 555 format. The two RGB 555 colors and five additional colors (created by interpolating between the two RGB 555 colors) form the primary colors for this texel block. Additionally, an eighth color is defined to be the transparent color. A 3-bit index is used to determine which color from the 8-entry lookup table will be used for each texel in the 4x8 block.
CC_CHROMA (good at complex color areas): A 4x8 texel block is represented by two bits-per-texel for opaque textures. Each block stores four 15-bit colors in an RGB 555 format. All four colors are used directly with no interpolation to form a 4-entry lookup table. The 2-bit index assigned to each texel in the block is used to determine which of the four colors is assigned to each individual texel. Note that Colors4 only applies to opaque textures, as it does not support transparency.
CC_ALPHA (gives the best control over complex alpha transparencies at four bits-per-texel): A 4x8 texel block is represented by two bits-per-texel for opaque and transparent textures. Each block stores three 20-bit colors stored in a 5555 format. The first and second 20-bit colors are used for the primary colors of the left 4x4 block, while the second and third colors are used for the primary colors of the right 4x4 block. Two additional colors are created in each block by interpolating between the two primary colors for that block. A 2-bit index is assigned to each texel in the block and a lookup table is used to determine which color is applied to each texel.
It is interesting to note that the CC_MIXED is very much similar to S3TC.
Actually, there are really only minor differences between the two. FXT1
was actually developed prior to the launch of S3TC however. So the question
of how they are so similar arises. Well apparently, both S3TC and CC_MIXED
are based on what is known as BTC, a technique that was introduced several
years ago in a paper at Siggraph. It is very interesting that both S3
and 3dfx came up with something so similar.
While it all looks very good so far, there are a few serious concerns
that I have. First is that 3dfx does not allow an adjustment in the amount
of compression used. It is pre-calculated so an exact amount of compression
is used for every texture. So a 32-bit texture will have 8x compression,
a 24-bit 4x and a 16-bit 2X. Because they are unchangeable, any image
quality loss resulting from the compression will present and the same
on every texture. Normally a game developer can adjust the amount of compression
used to fit their needs, but 3dfx isn't allowing this. On the fortunate
side of things, unless you really look close (perhaps even to the point
of zooming... I haven't seen it in a game yet so I can't accurately comment)
you won't likely notice the loss. However, it should be noted there that
while allowing the rate of compression has its advantages, there are also
problems with it. Basically, having a fixed compression ratio is good
since it means that you know exactly how to find all texel data. Variable
compression algorithms can result in major trouble in finding a specific
texel inside the compressed data. 3D accelerators access textures on a
per texel level (you might need one texel and not one around it). In general,
texture compression is based on pallets so they are always fixed.
An issue that concerns me even more is developer support. While 3dfx is
quick to point out that it is free to anyone and is cross-platform, I
still wonder if FXT1 will really catch on. S3TC has been out for about
a year now and support is just now developing. Will FXT1 have the same
problem? It has to be figured that the developers who are now supporting
S3TC/DXTn will not be so quick to jump on the FXT1 bandwagon, even with
the advantages it brings. And beyond that, if you consider that no other
chip maker has support nor is planning support (this is based on the fact
that FXT1 is just being announced) and that there will be some time before
support develops, even more questions come up. Really one of these is
the issue of a compression platform. There is a very strong chance that
S3TC will become that platform of choice simply based on the fact that
it has been around for a year longer than FXT1. While I'm not saying this
will be the case, I'm simply stating it as a possibility.
Overall though, FXT1 looks interesting, though certainly not earth shattering. The question of developer support is really the big issue. Even so, FXT1 is certainly a technology that I hope both hardware and software developers will pickup on. Its so open that anyone can use it, and that is really the great thing. Really though, the most important thing is that some type of texture compression is used. Right now, FXT1 does seem to be the best solution though. I guess we'll just have to wait and see what happens.
