• entries
455
639
• views
424141

# GTL3 DXTn Flipping Cont.

142 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...

There are no comments to display.

## Create an account

Register a new account