DXTC compression

Whitch algorymth do hardware drivers use to calculate the colors for the compression DXT1 ?

The algorymth that I use is good for the quality of the image but it is very slow.

Thx for your help


Unfortunately, no hardware compresses to DXT1. Well, except Intel/AMD hardware :slight_smile:

When you tell the driver to compress, it will try to do a fast job, but lose quality. If you tell an offline plug-in to compress, it will probably do a better, and slower, job. This is all done in software, and it’s a very real trade-off. Welcome to the real world :slight_smile:

I believe that to get decent DXT1 compression speed, you have to pick an algorithm which doesn’t sort the input pixels and then implement it in MMX. Because you’re reading the texture four scan lines at a time, you will also be careful about how you use the cache.

[This message has been edited by jwatte (edited 03-04-2002).]

Actually, I wouldn’t be surprised if the driver implemented a relatively decent, and slow, compression algorithm. Mainly because there’s no reason it can’t. After all, you’re not going to get realtime performance out of even a crappy compression algorithm, so performance isn’t the biggest issue. You don’t want it to take forever, but I’m sure they can afford to make it take a little while.

Sure I am in the real World. My algorythm can compress a 1024 X 1024 texture in 10 secondes without MMX. I scan 4X4 block to extract the closest couple of colors to the reste of the bloc, it is very slow … hehe.

I continue to search a faster method to compress my texture …