From: Roland S. <rsc...@hi...> - 2004-01-14 16:08:08
|
Daniel Vogel wrote: > [replying to multiple people] > > >> They also enable the old, undocumented, dead and buried GL_S3_s3tc >> extension > > > http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt Yes, but everything there just says "unknown" - no compression format, nothing interesting at all (except the format tokens), even how to submit compressed textures is just a guess there! This is not what I'd call documentation. > >> Note that the alpha decompression of DXT5 (in txformat_tmp.h) is >> horribly broken - stupid bug, the version from the earlier patch is >> actually correct (games likely never need this). > > > The sole reason of using DXT5 over DXT1, apart from working around > below mentioned HW "features" on GeForce 1-4 cards, is using the > alpha channel and we most certainly make a lot of use of the alpha > channel of DXT3/5 textures and I would expect other games do the > same. Yes certainly. But software decompression of textures really should never happen in games (performance of software rasterization really isn't good...), and I don't think current games have much use for reading back decompressed textures. > >> further (you can get better than 16bit color accuracy by means of >> the calculated colors, provided the GPU does the decoding in more >> than 16bit). > > > To the best of my knowledge the only GPUs that don't do this are > NVIDIA's GeForce 1-4 cards with DXT1 (they use 32 bit precision for > DXT3/5). You definitely want to use 32 bit for doing the > color1/color2 blending as the artifacts are quite noticeable for e.g. > lightmaps. > > >> dark gray, light gray or white... The improved encoder I have here >> improves this a bit, but fundamentally it seems to be a hard > > > Check out NVIDIA's encoder as a reference as it is the best out > there. > > http://developer.nvidia.com/object/nv_texture_tools.html I did take a look there earlier but 1) I couldn't figure out what the original license for the source code is (nvidia's license wouldn't permit the use of the source code for anything) 2) I have no idea if this is the same algorithm which is used in the DXT_TOOLS anyway 3) Being an offline solution it might not be suitable for online compression (might emphasize quality over performance too much) 4) at first look it seemed to miss the DXT5 encoder 5) It's way more fun to write an own implementation ;-) Roland |