Jump to content
Sign in to follow this  
  • entries
  • comments
  • views

GTL3 DXTn Flipping Cont.

Sign in to follow this  


So, after some half decent TF2 playing I decided to work on a few of the bugs in the GTL3 DXTn flipping routines.

The problems with the DXT1 flipping turned out to be a matter of maths errors on my part mostly; generally I was skipping too many bits, or not enough and it was all going a bit wrong.

The same pattern of problems appeared in the DXT2/3 routines as well, where some debugging and making sure the numbers were sane quickly took care of the problem.

DXT4/5 however is proving more intresting;

Recall, if you will, from an earlier entry where I mentioned the alpha values were stored as 3bit pairs and as such didn't really fit into any common data structure, just to be annoying.

So, I decided to hack things a bit by casting to a 64bit type and just ignoring the bottom 16bits of data. It seemed like a sane idea at the time, however this is C++ and nothing is as it seems.

In order to get the bits we want this lovely bit of code was created;
boost::uint64_t srcdata = *(reinterpret_cast(&src.lookup1));

where lookup1 is the first in the list of variables used to hold the table information.

Then, to write back the same kind of trick was used;
boost::uint64_t * destptr = reinterpret_cast(&dest.lookup1);
*destptr = destdata;

We can do this because there are no virtuals in this struct and we'll be overwriting the following colour data right away.

This nearly works, however I think I'm being tripped somewhere by endian issues or something.

The layout of the struct in question is thus;

struct dxt1 {
boost::uint16_t colour0, colour1;
boost::uint32_t lookuptable;
dxt1() : colour1(0), colour0(0), lookuptable(0) {};

struct dxt4 {
boost::uint8_t alpha0, alpha1;
boost::uint8_t lookup1,lookup2,lookup3,lookup4,lookup5,lookup6;
dxt1 colourdata;
dxt4() : colourdata(), alpha0(0), alpha1(0), lookup1(0), lookup2(0), lookup3(0), lookup4(0), lookup5(0), lookup6(0) {};

Now, I realise I haven't packed things, so maybe VC8 is doing something with the alignment, I'll check that in a bit, however things don't work as expected.

If all our lookup values hold 0xFF and our dxt4::colourdata::colour0 hold 0xff instead of getting 0xffffffffffff00ff when read I infact get 0x00ffffffffffffff.


This also causes a problem on write back, because the lower 16bits are zero in the dest data, which means that lookup1 and lookup2 both get 0x00 for values.

So, yes, I need to work out how I'm going to demong that data into something I can make use of... or maybe just come up with a whole new algo or something, I dunno; something with an array of 6 elements and some shifting magic or something.

Either way, I suspects nightmares abound to fix this up [smile]
Now, however, I sleep...
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!