http://bugs.winehq.org/show_bug.cgi?id=15636
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2009-04-21 03:56:53 ---
if you're forcing S3TC support on, and your hardware doesn't support it, it shouldn't change the behaviour of your app
AFAIK, my hardware supports decompression, but not compression. The former is apparently all that's needed for this particular application. The referred URI further reads: "you will get errors if applications try to use online-compression (like QuakeIII does)".
BTW, somewhere I read that it could be that MS-Windows' D3D drivers would report the S3TC capability even on my hardware. That would make CMR2 run there. So the force_s3tc_enable option gets wine closer to MS-Windows' behaviour. It's not to be frowned upon. Material for wine-wiki?
I think your glxinfo would be interesting here. If they're different
As I said, they are. A single additional capability is output, something xyz_s3tc (from memory, I cannot check right now). Must be ext_texture_compression_s3tc as it's this one wine checks in dlls/wined3d/directx.c.
There's something else going on here.
Well, what's puzzled me is the following quote from http://dri.freedesktop.org/wiki/S3TC "force_s3tc_enable... This may be of use for some games which require S3TC or don't use the ARB_texture_compression extension correctly." So there would be some correct use of ARB_texture_compression (which wine should thus implement) that does not depend on this option?!? I could not find further information on this.
The two pages about S3TC are not clear enough, IMHO. It took me some time after initially reading them to combine that it would benefit CMR2.
bug 14939 is reported with an nvidia card
Yes, much to my surprise. NVidia is probably supported by CMR2 (I will look up the package cover). Does the CMR2Demo (URL in top template) work for you with NVidia?