Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422566

GTL3 DXTn Flipping Cont.

Sign in to follow this  

91 views

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.

Bugger.

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  


0 Comments


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