Did you enable r_ext_compressed_textures 1? Otherwise, quakeIII won't use compressed textures.(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.
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
------------------------------------------------------- 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