I think I get what your saying here, about white and black being your max and min. The answer is simple, to my simple mind. You need to compress your max and min based uppon your full data set. Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Brown with red and blue then. --- Roland Scheidegger <[EMAIL PROTECTED]> wrote: > Dieter Nützel wrote: > >>>(needed for QuakeIII/rtcw, don't know about > >>>rtcw:et). This time I haven't tested the r200 patch, only radeon so use > >>>at your own risk. > > > > > > Using 8/8/8 Color bits, 24 depth, 8 stencil display. > > GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL > > Initializing OpenGL extensions > > ...using GL_S3_s3tc > > ...using GL_EXT_texture_env_add > > ...using GL_ARB_multitexture > > ...using GL_EXT_compiled_vertex_array > > > > ~160 fps at 640x480 fullscreen > > ~156 fps at 640x480 window > > > > On 1280x1024x24 desktop both without sound. > Did you enable r_ext_compressed_textures 1? Otherwise, quakeIII won't > use compressed textures. > > 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). > You will also get quite a few "color banding" artifacts. It's kinda > funny, you can get absolutely HUGE color errors in theory (because a > 16-pixel block needs to be encoded with only 4 colors, of which only 2 > are specified directly, the others are calculated and are somewhere > in-between the other 2 colors), but what you actually notice are > (comparatively) very minimal color banding errors because the encoded > colors are only 16bit, not 32bit. Though a newer version of the encoder > reduces this problem quite a bit (some stupid design flaw which led to > rounding errors), a really clever encoder could reduce this problem > 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). > Another problem is the encoding can sometimes fail pretty horribly. If > you have one white and one black pixel in your 16-pixel block, those > will get chosen as the 2 base values. If the other 14 pixels are all > green for instance, well tough luck - they are now all either black, > dark gray, light gray or white... The improved encoder I have here > improves this a bit, but fundamentally it seems to be a hard problem to > get the best (or at least a decent) encoding - not to mention you'd need > to figure out how to define what a good encoding actually is... > Alpha (DXT5) encding is also improved in the new version. > There's no new patch available yet - trust me, you don't want to see the > code ;-). Furthermore, I'll convert this to use the dlopen/dlsym stuff > as discussed already before I'll submit another patch. > > Roland > > __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
