UP2 (squared)

[Brian Beuken]

ohhhh it was a bug...small one but important, and probably not mine, though my activation of it was due to some sloppy code, it seems that this function in the binary reader

glm::vec3 BinaryReader::ReadCompressedVec3()
{
glm::vec3 vec;
vec.x = ReadByte();
vec.y = ReadByte();
vec.z = ReadByte();
return vec;
}

Behaves quite differently on intel chips, the byte that is read is sign extended (any value over 128 is considered negative in 2's compliment binary) creating a negative float (thats actually correct behaviour), rather than a value from 0-255 (which is the inncorrect behavoir of the ARM cast)
Its probably a bug in GLM rather than being a specific issue, someone coded the intel code to sign extend when loading a char into a float.

The fix is simple, make sure you only send the char part to the float, don't allow it to be sign extended

glm::vec3 BinaryReader::ReadCompressedVec3()
{
glm::vec3 vec;
vec.x = ReadByte() & 255;
vec.y = ReadByte() & 255;
vec.z = ReadByte() & 255;
return vec;
}

Or.. a more elegant fix is for ReadByte to return an unsigned char which is better, and what I should have done in the first place.

Quite a complex bug tbh, it took a lot of tracking down, and head scratching determining where the data was faulty, what data was faulty, where it was set up and finally where it was loaded...not an easy route..

But its all working fine now.   the demo's will be updated accordingly for anyone using an intel based board, the fix does no harm to the ARM version.