Why bitshift to get to the x,y,z co-ords

[paulyc]

For one thing, it appears the code doesn't quite match the struct, specifically on calculating the z position. According to that struct the z bits are Position2 & 0x7FFFF. Heading calculation is clearly incorrect so I'm going to guess the ZPos is too (or for a different version of the packet?).

How to figure out where the bits are? Group the bit fields into 32 bit integers since the type of each bit field is int.
First 32 bits is posData[0] Position1
unsigned pitch:12;
signed deltaX:13; // change in x
unsigned padding01:7;

Second 32 bits, posData[1] Position2
signed z:19; // z coord (3rd loc value)
signed deltaHeading:10; // change in heading
unsigned padding02:3;

z is listed first so it is simply the lowest 19 bits of this 32 bit int, posData[1] & 0x7FFFF

Third posData[2] Position3
signed x:19; // x coord (1st loc value)
signed deltaZ:13; // change in z
again, x listed first, lowest 19 bits, posData[2] & 0x7FFFF

Fourth posData[3] Position4
unsigned heading:12; // heading
signed deltaY:13; // change in y
unsigned padding03:7;
nothing here

Fifth posData[4] Position5
signed animation:10; // velocity
signed y:19; // y coord (2nd loc value)
unsigned padding04:3;
animation is stored in the lowest 10 bits, y is stored in the next 19 bits, that's why it needs to be shifted right by 10. (posData[4]>>10) & 0x7FFFF

[paulyc]

Next question, EQ19ToFloat. The largest positive value we can store in a 19-bit integer is 0x3FFFF and the largest (magnitude) negative value we can store is 0x40000. But remember, our value is stored into only the lowest 19 bits of the 32-bit variable EQ19Value. Stored as a 32-bit int, 0x40000 is not a negative number at all, to properly store a negative 19-bit value into 32-bits the high bit needs to be sign extended all the way to the left, 0xFFFC0000.

So the first line of this function tests if the value is supposed to be negative, if it is, the second line does a little bit of trickery to sign extend the 19-bits into 32 (same as 0xFFF80000 | EQ19Value), now we have a proper signed native int.

The last line converts that properly sign extended 32-bit integer into a 32-bit float. Yes, (1<<3) is the same thing as 8, I think it is written like this to make it more clear what is going on. Whats going on is the lowest 3 bits of this integer are a fractional part. For example EQ locs are shown with one digit decimal value after the point, doesnt map perfectly to the range of .0 to .9 since 3 bits is 7 values so theres a little rounding error but

000 = .0
001 = .125
010 = .25
011 = .375
100 = .5
101 = .625
110 = .75
111 = .875

[paulyc]

Originally Posted by paulyc

Next question, EQ19ToFloat. The largest positive value we can store in a 19-bit integer is 0x3FFFF and the largest (magnitude) negative value we can store is 0x40000. But remember, our value is stored into only the lowest 19 bits of the 32-bit variable EQ19Value. Stored as a 32-bit int, 0x40000 is not a negative number at all, to properly store a negative 19-bit value into 32-bits the high bit needs to be sign extended all the way to the left, 0xFFFC0000.

So the first line of this function tests if the value is supposed to be negative, if it is, the second line does a little bit of trickery to sign extend the 19-bits into 32 (same as 0xFFF80000 | EQ19Value), now we have a proper signed native int.

The last line converts that properly sign extended 32-bit integer into a 32-bit float. Yes, (1<<3) is the same thing as 8, I think it is written like this to make it more clear what is going on. Whats going on is the lowest 3 bits of this integer are a fractional part. For example EQ locs are shown with one digit decimal value after the point, doesnt map perfectly to the range of .0 to .9 since 3 bits is 7 values so theres a little rounding error but

000 = .0
001 = .125
010 = .25
011 = .375
100 = .5
101 = .625
110 = .75
111 = .875

By the way, this type of number format, which has some integer bits and some fractional bits, is known as fixed-point. It is not as commonly used as floating-point and not typically implemented in hardware, which is why this function exists, to convert the value into a format that the CPU can natively manipulate.

So to summarize, EQ19ToFloat takes a 19-bit fixed-point number, which has 16 integer bits and 3 fractional bits, and converts it to a 32-bit floating-point number.