summaryrefslogtreecommitdiff
path: root/TextureCompression.moin
diff options
context:
space:
mode:
Diffstat (limited to 'TextureCompression.moin')
-rw-r--r--TextureCompression.moin75
1 files changed, 0 insertions, 75 deletions
diff --git a/TextureCompression.moin b/TextureCompression.moin
deleted file mode 100644
index e89ad8b..0000000
--- a/TextureCompression.moin
+++ /dev/null
@@ -1,75 +0,0 @@
-= Texture Compression =
-
-== S3 Texture Compression (S3TC) ==
-
-See S3TC.
-
-== ATIMach64 / ATIR128 texture compression ==
-
-According to an ATI press release:
-
- ''3D RAGE PRO supports several methods of texture compression, including use
- of palletized textures, with VQ permitting 8:1 compression, allowing content
- developers to produce richer content without limits on texture size. Texture
- compression technology and the ability to share host memory gives the
- developer more memory to work with when handling complex textures and
- removes the need to write complicated texture management schemes.''
-
- -- IanRomanick
-
-This is something interesting that I had also noticed when reading the
-chip specs, a TEX_COMPRESS bit that enabled 4:1 VQ compression. (the 8:1
-must be with palletized textures simultaneously). At that time I didn't
-fully understand what was the meaning of this so I left this for a later
-time.
-
- -- JoseFonseca
-
-I took a peek at the ARB_texture_compression extension. New internal format
-tokens would need to be created for each of the compressed formats
-available. So, if only compressed RGB textures are supported by the
-hardware, then something like GL_COMPRESSED_RGB_VQ1_MESA would need to be
-added. Then, when a texture is sent into the driver, if the texture format
-is non-compressed (i.e., GL_RGB) and the internal format is either
-GL_COMPRESSED_RGB_VQ1_MESA *or* GL_COMPRESSED_RGB, the driver would need to
-compress it. If the texture format is already GL_COMPRESSED_RGB_VQ1_MESA
-(very, very, very, unlikely), it would just get passed through.
-
-Now, the new token could probably be skipped. If the requested internal
-format is GL_COMPRESSED_RGB, just compress the texture and be done with it.
-Given the likely hood of ANYONE having pre-compressed textures for this
-format, this is probably both the easiest and best route to take. This is
-amplified by the fact that I don't think that even the ATI drivers export
-this functionality in OpenGL. Does anyone know any different?
-
-Perhaps we could discuss this more in the IRC chat today.
-
-http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt
-http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt
-http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt
-
- -- IanRomanick
-
-While I was searching around the net for papers on texture memory
-management, I came across some references to Talisman and DirectX 6.0
-texture compression. It seems that the compression algorithm used is
-called "TREC," which is short for "Texture and Rendering Compression."
-
-http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF
-http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm
-
-Apparently, it is some sort of DCT based compression scheme. That would
-explain why ATI is the only company to ever implement it in hardware. :)
-
- -- IanRomanick
-
-According to the docs, mach64 implements 4:1 VQ de-compression, but
-there's no other info. Rage 128 also has a VQ texture format bit,
-according to the register header file. Sega dreamcast used a form of VQ
-compression also, I think.
-
- -- LeifDelgass
-
-== General resources ==
-
-[[http://www.gamasutra.com/features/20010416/ivanov_01.htm|Image Compression with Vector Quantization]] (registration required) has a fairly extensive description to VQ (vector quatitization) encoding, including sample code. It actually distuinguishes VQ from DXTN (which is S3TC).