Because it is not a valid (or good) float value.
EDIT: Bad example. Better example below.
Storing multiple bytes in one container can be achieved as:
But mapping a float to chars and the reverse is not done through a union.Code:#include <iostream> #include <boost/array.hpp> int main() { boost::array<unsigned char, 4> e; e[0] = 0xFF; e[1] = 0x00; e[2] = 0xFF; e[3] = 0x00; std::cout << std::hex << (int)e[0] << (int)e[1] << (int)e[2] << (int)e[3] << std::endl; }
Last edited by Elysia; 12-19-2008 at 06:52 AM.
Originally Posted by Adak
If you would assign it a more normal value like 50.0f wouldn't it still be 50.0f after converting to chars and back since it is the exact same memory? Or does the memory change in some way when you reassign the chars and try to get a float from it? I thought this was the purpose of unions. I realize you can't expect to just pass in any color and expect a good float but something that starts as a good float would not get messed up like that right?
Floats are not expressed the same as chars. They work differently. So while you might expect it to work with integers, it will give you a messed-up float value.
Also, I messed up the example (don't know what I was thinking), sorry.
Here is a better example:
Output:Code:#include <iostream> union something { float fv; unsigned char sv[4]; }; int main() { something e; e.sv[0] = 0xFF; e.sv[1] = 0x00; e.sv[2] = 0xFF; e.sv[3] = 0x00; std::cout << "Float: " << e.fv << std::endl; std::cout << "Chars: " << std::hex << (int)e.sv[0] << ", " << (int)e.sv[1] << ", " << (int)e.sv[2] << ", " << (int)e.sv[3] << std::endl; }
Float: 2.34184e-038
Chars: ff, 0, ff, 0
Another example:
Output:Code:#include <iostream> union something { float fv; unsigned char sv[4]; }; int main() { something e; /*e.sv[0] = 0xFF; e.sv[1] = 0x00; e.sv[2] = 0xFF; e.sv[3] = 0x00;*/ e.fv = 50.0f; std::cout << "Float: " << e.fv << std::endl; std::cout << "Chars: " << std::hex << (int)e.sv[0] << ", " << (int)e.sv[1] << ", " << (int)e.sv[2] << ", " << (int)e.sv[3] << std::endl; }
Float: 50
Chars: 0, 0, 48, 42
Last edited by Elysia; 12-19-2008 at 06:52 AM.
Ok but I'm not interested in assigning random values to chars and then trying to convert to float.The starting point is a valid float value. Can you redo the test but with a float that gets converted to chars[4] and back?
Yeah, that's the second example.
The example is good because you can mess with it. Assign a float or to the chars, it doesn't matter. It will print out the data in both at the end so you can see what happens.
The data will be "fine", if you will. If you put it 50.0f, it will still contain 50.0f as long as you make sure the data is intact. But this is not really a good use of a union, and I do not see why you need one at all.
If you just want to store 4 bytes worth of data inside a "container", I also posted an example on that.
using a float would cause problems with accuracy. Due to the inevitable rounding errors associated with any floating point operation in a discrete environment (which all binary based computers are, and probably most if not all others) you'd never be guaranteed to get the exact colour back that you put in.
Using bit manipulation on an integer data type to store the 4 8 bit values would make more sense.
So instead of using 4 ints to store the colour data, use a single unsigned int (32 bits, exactly enough).
Again, this comes back to the question: why do you need to store the data inside a big variable instead of an array?
1x 4-byte var vs 4x 1-byte vars.
No all you are doing is assigning a float value and printing it. If you would assign back exectly the same values to the chars, would it still print 50.0f for the float, that is the question to me. And btw those values printed from the chars looks as valid color values.
Output:Code:#include <iostream> union something { float fv; unsigned char sv[4]; }; int main() { something e; e.sv[0] = 0x00; e.sv[1] = 0x00; e.sv[2] = 0x48; e.sv[3] = 0x42; //e.fv = 50.0f; std::cout << "Float: " << e.fv << std::endl; std::cout << "Chars: " << std::hex << (int)e.sv[0] << ", " << (int)e.sv[1] << ", " << (int)e.sv[2] << ", " << (int)e.sv[3] << std::endl; }
Float: 50
Chars: 0, 0, 48, 42
So again, yes, it works this way. But it is a poor use of a union, and the question is, why would you need it when you can use an array?
Rounding errors could mess it up yes. I could round off the floats myself before I work with them in this way though.
Bit operations on ints is something I havn't done but the classes I have worked with that uses it were dead slow compared to arrays as an example.
The main reason is that the bitmap is already defined in memory so no double memory load from an additional array. Also while working with each pixel I have the value in the same place using the same loops I use to loop through the bitmap pixels.
I am afraid... I do not get it.
From what you explain, it would matter little if it's an array or a big variable.
Of course, you can also use pointers to "treat" the bitmap as one big array, as well.
But unfortunately, these kinds of things sound more like C solutions rather than C++ solutions, so I'm afraid there is little I can help with.
Game programming is not something I know.
What range of colors do you need for the depth? You mentioned black to white, so that's RGB(0,0,0) to RGB(255,255,255). Are you wanting only shades of gray? Obviously, there are more possible float values than there are color values, so you'll need to normalize the float values either way. Why can't you figure out the min and max float values ahead of time?
Or, is your problem the mapping of a float value between 0.0 and 1.0 to an RGB value that will make sense from a color spectrum depth perspective?
Mainframe assembler programmer by trade. C coder when I can.
Don't be afraid... but do get it
Nope no way of getting min/max beforehand, each pixel can be different in what kind of surface thickness lies behind it. It needs to be accurate so I can't approximate things.
I'm only working from black to white and the values will be clamped between 0.0 and 1.0. I will be able to map it to a color no problem.
