GameCube's S3TC: How does it work?

[Fox5]

No, the only chip that supports FXTC is 3dfx VSA-100. The NV2a in Xbox supports S3TC(=DXTC).

And based on the only page I've seen that actually tested FXTC, it had worse results than S3TC in nearly every case. The only good part was that it didn't require a license. (did 3dfx even have an s3tc license, or did they just convert everything to the various modes of FXTC?)

 

[Simon F]

And based on the only page I've seen that actually tested FXTC, it had worse results than S3TC in nearly every case. The only good part was that it didn't require a license. (did 3dfx even have an s3tc license, or did they just convert everything to the various modes of FXTC?)

Please see my comment above about patents....

("Bit masking" ...)Any hardware that supports paletted textures
If you have hardware support for 4 bit palettes, and have two textures where you need just four indices each, you can pack them into a single 4-bit texture and use two palettes......

Hmm, I think I can see a much better way of doing this which would allow you to pack more data in than this It should frequently allow both textures to have more than just 4 indices

 

[Xmas]

Hmm, I think I can see a much better way of doing this which would allow you to pack more data in than this It should frequently allow both textures to have more than just 4 indices

Instead of reducing to the 4 best colors for each texture, you could optimize for the 16 best color pairs. Basically, palette optimization in 6/8 dimensional space instead of in 3/4 dimensions (RGB/RGBA).

 

[Squeak]

If the number of pixels starts to become smaller than the number of colors, yes. But for medium-sized mipmap levels I don't think that's the case.

But the problem is that those "AA entries" take up a huge part of the palette so really only have a handful of "base colors".

It can't be denied that you are correct to some extent, but in realword cases the problem isn't that great, for the reasons I already mentioned.

Instead of reducing to the 4 best colors for each texture, you could optimize for the 16 best color pairs. Basically, palette optimization in 6/8 dimensional space instead of in 3/4 dimensions (RGB/RGBA).

Sure, that's what you do when you want to create a palette animated texture.

The "advantage" of the other approach is that it's more immediate and predictable. For example if all you want is a large monochrome detail texture it will save you space and pageshifts. You could also have texture and MIP maps on the same page, making trilinear easier on some platforms. And as mentioned, it has been used for luminans compression.

There's different sizes.
With point sampling resize to 25% and then resizing to 200% I get your first image, but what I get with a box filter looks substantially different (and way better) than your second image.

You're right, the filter was set to "2" in PS, must've used it before and didn't notice.

 

[Fafalada]

Hmm, I think I can see a much better way of doing this which would allow you to pack more data in than this It should frequently allow both textures to have more than just 4 indices

Treating the channels of two maps as one larger vector and optimizing the palette(s) for that?

I guess I should try and see if it makes a difference - it's true that for luminance maps I used, every little helps(so even 2more indices would visibly improve results), but I have no idea how much 'pairing' would there be between two maps data.

Thanks for the explanation, it wasn't obvious to me that this is about switching palettes.

Yea it's kind of homage to the old days of bitplanes on Amiga
Anyway, it's not the only useful compression trick you can get with palettes - one other I like is using two 8bit palettes to simulate Simon's 2x2VQ at high speed (1/4 ops/texel, so long as hardware isn't too fussy about memory addressing modes).

 

[Simon F]

Instead of reducing to the 4 best colors for each texture, you could optimize for the 16 best color pairs. Basically, palette optimization in 6/8 dimensional space instead of in 3/4 dimensions (RGB/RGBA).

Treating the channels of two maps as one larger vector and optimizing the palette(s) for that?

Yes.. it seemed to me that treating it as VQ problem would do the trick. There's likely to be a some chance of correlation between pairs of pixels in the two textures.

 

[darkblu]

("Bit masking" ...)Any hardware that supports paletted textures
If you have hardware support for 4 bit palettes, and have two textures where you need just four indices each, you can pack them into a single 4-bit texture and use two palettes. In both palettes, you duplicate the entries in a way that makes the bits you don't need for the current texture irrelevant. This doesn't require dependent reads at all.

Let's put the two index bits for texture 0 into the two low bits of the texture and lets call the palette entries C00, C01, C02, C03.
Likewise put texture 1's two-bit indices into the high bits and let's name the colors C10, C11, C12, C13.

When you want to sample texture 0, you make this 4-bit palette current:
C00, C01, C02, C03
C00, C01, C02, C03
C00, C01, C02, C03
C00, C01, C02, C03
I.e. all rows are equal. The two higher bits don't affect the color that's pulled from the pallete.

When you want to sample texture 1, you switch to this palette:
C10, C10, C10, C10
C11, C11, C11, C11
C12, C12, C12, C12
C13, C13, C13, C13
All columns are equal now. With this palette, the two higher bits are irrelevant.

you believe you meant 'the two lower bits' in that last sentense.