[C/C++] float packed in short int, how to convert back and forth?

Started by
4 comments, last by reptor 13 years, 6 months ago
I've been told that some numerical data I am trying to read from a file is in the C/C++ data type 'short int' in the file. That would be a 16-bit integer.

But that it is actually a 32-bit float. And that it has 4 decimals after the decimal separator. So there is some accuracy dropped from the floats in the process of storing them in the file.

I have confirmed that the length of the array of the numbers match the expected size of the array when the values are read in as short int so that must be correct. Well, at least the number of bits per number is correct, 16, when in the file.

Now my problem is that I need to read the values from the file and convert them to floats. And I would also like to learn how to do it to the other direction, going from the float to the short int reducing the accuracy to 4 decimals.


How can we do this?
Advertisement
?? I'm not exactly sure what's going on in your post, but here goes:

Are the floats in the file in a fixed point format? You mention that there are four decimals after the radix. If this is the case, then it is simple, either divide the short int by 1000.f or by 1024.f, depending on the scaling factor. To do the reverse, just multiply the float by 1000.f or 1024.f, then truncate the decimal and cast to short int.

Are the floats in the file at half precision? If this is the case, then (by relying on IEEE 754-2008) its just a matter of bit-wise manipulations to move the exponent and mantissa from the half precision format to the single precision format.

Though, I'm fairly certain you're working with fixed point numbers here.
Thanks for the reply.

I will show you what I try to do.

The values are terrain height field values.



http://community.bistudio.com/wiki/Wrp_File_Format_-_4WVR

http://community.bistudio.com/wiki/Talk:Wrp_File_Format_-_4WVR

The discussion page is a bit messy... so this is the documentation that I have for this. The values are 'Elevations' in the former page I linked to.

Those are the pages I got the information from. I try to read the height field from the file and display it in a 3D program.

You can see from those pages that there is some other calculation involved too:

Quote:Elevations
Elevations are expressed as an integral of the gridsize.
Since the gridsize for ofp is a fixed 50 meters, to convert the value into meters:
RealHeight = Elevations[x][y] * 0.05;
see Talk



There are two (in fact three, but the third one doesn't differ on this issue) file formats used for this in the game. This one that I am reading now has unpacked arrays and it is simpler to read. The other one is an optimised format which has packed arrays and I have not done the loading code for that yet. I could take the optimised file and convert it to this unoptimised file format and then compare the height field values from both of the files so I could see if my conversion formulas make the data match the original data.

But help is appreciated. I will have to do some coding until I can post more about this but if you have more ideas now that you have more information about the case, please tell!

Thanks.
The documentation is a bit contradictory in my opinion. It says that the accuracy of the floats used is 4 fractional digits.

But then the instruction to multiply it by 1000 only moves 3 fractional digits to the other side of the decimal separator.

That doesn't make sense to me. Either the accuracy of the floats is 3 fractional digits or the multiplier should be 10000 instead of 1000.

I know for a fact that elsewhere in the game the accuracy of floats indeed is 4 fractional digits so that part of the documentation does make sense.

I know approximately what kind of height values the height fields have in-game so I have an idea whether the values I am getting are in the right range or not.

I guess I need to create some more test files with some clear input values. The "Elevations are expressed as an integral of the gridsize." part of the documentation could be where I am tripping up now.
If they are actually stored as half-floats then I have the perfect thing for that.
See Halffloat.cpp / halffloat.h from this page of my website.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Thanks, I will check that out. It seems you have some other interesting bits in there too...

Currently I am writing code to read the other file format which should contain data which is based on the same input values for the height field but stored as 32-bit floats. Once I have that done then I can compare those 32-bit float numbers to what I get from the other file format after my conversion calculations.

This topic is closed to new replies.

Advertisement