Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Last Attacker

Compression Formats

This topic is 5151 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''ve been working on OpenGL for quite some time but I would like to know how the following texture compression formats work on your video card : * 16-bit * 32-bit (No compression here, right? Normal size) * Compressed (How?) * DXT1 (What is it? How does it work?) * DXT3 (Ditto) This is not important, just something of intrest I would like to know. Well I checked out these stuff when I was tuning the settings of my card through RivaTuner. Thanks // Last Attacker \\---=( LA )=---// LA Extreme \\

ICQ Number : 120585863

E-mail: laextr@icqmail.com

Share this post


Link to post
Share on other sites
Advertisement
As far as i know DXT means Direct-X DDS image compression, but I dont know about any desription of it ... im looking for it too.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
This site has code to load DDS-files, enough to get you started and then some:

http://www.b500.com/~hplus/graphics/

DDS is nice, since you generate mipmaps ''offline'', rather than when you upload to the gfxcard. You will notice a speed increase and at the same time have full control over how the ''minification'' of the texture is done.

Share this post


Link to post
Share on other sites
The actual compression part of DDS files is DXTC, or S3TC in the OpenGL part of the world, which works something like this:

4x4-pixel blocks are processed individually. For each block, two colours are chosen by the compressor, and stored in the compressed file. Two other colours are calculated from these -- 33% colour 1 plus 66% colour 2, and then 66% colour 1 plus 33% colour 2 -- and each pixel in the block is converted to the closest of these four colours. Since each pixel is then one of four colours, it only takes two bits to store that pixel.

The difficult part when compressing is choosing the initial two colours so that the compressed image looks as close as possible to the original image - it''s lossy compression, but unnoticeable (hopefully) on smoothly shaded textures.

Assuming a 16-bit input image, each uncompressed block would be 2 (bytes per pixel) * 16 (pixels) = 32 bytes. The compressed block is 2 (bytes per colour) * 2 (stored colours) + 0.25 (bytes per pixel) * 16 (pixels) = 8 bytes -- a quarter of the original size.

Decoding can be done fairly easily in hardware, since it''s just interpolating two colours and then doing a lookup for each pixel. Compression takes a lot longer, but it''s not a problem when the textures are stored already compressed (e.g. in DDS files).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!