At the moment, if I want to use compressed textures in my game I have to have GL do it during the upload. This is obviously slower than I'd like, so I'd prefer to compress the textures offline and load the compressed data directly using glCompressedTexImage2D.
This works perfectly fine on Windows using DXT1, 3 and 5. However, once I get to Linux I have problems. The chip I'm testing on is an Intel 915GM which supports only FXT1 (a format developed by 3DFX as a rival to S3TC in 1999 which suffers from lack of adoption) through MESA. It'll compress textures to FXT1 through glTexImage2D just fine, but point blank refuses to load them through glCompressedTexImage2D. Even if I use glGetCompressedTexImage to get data compressed by glTexImage2D.
Also, I have the 3DFX encoder source, and none of the 4 different flavours of FXT1 (mixed, hi, chroma, and alpha) are the same as what glCompressedTexImage2D is returning.
So, two questions: Does MESA actually support loading compressed textures (I know it's an area under development), and if so, exactly what flavour of FXT1 does it accept and where can I get an offline encoder for it?
Loading compressed textures
In theory, Mesa supports compressed textures just fine, including loading of compressed textures. In practice, compressed textures are surrounded by software patent idiocy. This results in them being disabled by default and requiring an external library for full support. This means that, in practice, compressed texture paths get very little testing, and even code paths that are not directly affected by the software patent idiocy - such as uploading pre-compressed textures - may fall into disrepair.
Unfortunately, there's no good solution to this. There is some hope (?) that the attitude of the Mesa developers towards software patents becomes more of an "oh fuck it!" attitude because of floating point support. Floating point rendering is surrounded by even more ridiculous software patent idiocy, but it is central enough to a 3d rasterizer that it might push the Mesa developers towards a different attitude. After all, there's not really a technical problem in supporting an OpenGL implementation without compressed textures, but without floating point? Not so much. And a change in attitude could benefit the support of compressed textures as well, in the long run.
In the short run, I would make sure that (a) your program works correctly with other OpenGL implementation and (b) that you're using most recent drivers. If things still don't work, bring the issue up with the Mesa developers. There's a chance that they haven't even noticed the issue yet (I know I never did any compressed texture testing when I was working on the r300 driver, because of the above).
Unfortunately, there's no good solution to this. There is some hope (?) that the attitude of the Mesa developers towards software patents becomes more of an "oh fuck it!" attitude because of floating point support. Floating point rendering is surrounded by even more ridiculous software patent idiocy, but it is central enough to a 3d rasterizer that it might push the Mesa developers towards a different attitude. After all, there's not really a technical problem in supporting an OpenGL implementation without compressed textures, but without floating point? Not so much. And a change in attitude could benefit the support of compressed textures as well, in the long run.
In the short run, I would make sure that (a) your program works correctly with other OpenGL implementation and (b) that you're using most recent drivers. If things still don't work, bring the issue up with the Mesa developers. There's a chance that they haven't even noticed the issue yet (I know I never did any compressed texture testing when I was working on the r300 driver, because of the above).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
