Red Green Texture Compression
|Core in version||4.6|
|Core since version||3.0|
|Core ARB extension||ARB_texture_compression_rgtc|
There are 4 RG compression formats: unsigned red, signed red, unsigned red/green and signed red/green.
All of these basically work the same. They use compression identical to the alpha form of DXT5. So for red only formats, you have 1 64-bit block of the format used for DXT5's alpha; this represents the red color. For red/green formats you have 2 64-bit blocks, so that red and green can vary independently of one another.
The signed formats are almost identical. The two control colors are simply considered to be two's compliment 8-bit signed integers rather than unsigned integers, and all arithmetic is signed rather than unsigned. Also, rather than having 0.0 and 1.0 in the table, you have -1.0 and 1.0. Also, the comparison between alpha0 and alpha1 (red and green, depending on which block it is) is undefined if alpha0 is -127 and alpha1 is -128. That is because the comparison logic for two's compliment integers is slightly different from unsigned integers when comparing -128 to -127. The specification says that the result is undefined, so the resulting color values will be undefined.
Therefore, when manually compressing your signed texture formats, make sure you do not have a block that makes the first color -127 and the second -128. Obviously, any non-buggy compression tool will take care of this for you.
Normalized Integer rules are in effect here. Particularly important for RGTCs are the rules for signed normalized integers. Integer values on the two's complement range [-127, 127] map to [-1, 1]. -128 may be used as well, but it will also map to -1. Because of this, and the above notation, it is best when compressing signed data to never generate values of -128.