quote:
Originally posted by DJeX
^ But it don't write the color of the box it writes a number like -256438
Well, that IS the colornumber though; a color is nothing more then a number...
A colornumber can be written in roughly two ways: signed and unsigned. -256438 is obviously a signed number (it can have a negative sign or a postive sign, while an unsigned number is always positive)
First, what is a color:
A color is made out of different components. The most known is Red Green and Blue. Each of those values can be from 0 to 255. So to represent all these 3 values in 1 number you simply add them together in a binary way: you "concatenate" the Blue value to the Green value which you "concatenate" to the Red value...
In hexadecimal it looks must simplier to explain: a RGB color is a number between 0 and FFFFFF.
the first FF is the Red value, the second FF is the Green value and the third FF is the Blue value (exactly the same as with HTML colorcodes
) But together they form the hexadecimal number FFFFFF (being absolutely white). Now, when you convert this number to a decimal format you'll get: 16777215 because this comes from R * 2^0 + G * 2^8 + B * 2^16. So an RGB color uses a maximum of 24bits.
Though, the actual color used by windows consists of 4 individual values. so instead of a maximum of FFFFFF (hexadecimal) you can have FFFFFFFF (hexadecimal), or a maximum of 32bits. But the principle is just the same of course...
Signed/Unsigned:
To store numbers, the computer needs some memory locations. But of course using to much memory space isn't very efficient. That is why you have certain types of numbers. eg, a "byte" uses 1 byte, meaning you can use a number from 0 to 255. a "word" uses 2 bytes (the numbers 0 to 65535), a "double word" uses 4 bytes (the numbers 0 to 2^32-1), etc...
These are all positive numbers of course. So the PC needs to have a system where you can store negative numbers as well. This is where the signed/unsigned system comes into place.
With signed numbers you need to offer 1 bit up for the state of the sign. This leaves one bit less for the actually number:
If you take the space of 2 bytes (a "word"), you can have the number from 0 to 65535 (16bits), thus this will always be positive. Now, offer up 1 bit for the sign and you'll be left with only 15bits for the actual number, so now the number can go from -32767 to +32767 (but still there are 65536 possible numbers of course, just as before as it still uses 16bits in total)
So there you have it, the difference between a signed number and an unsigned number. In most programming languages, the signed number system is used by default.
Though, you can easly convert one into the other. eg: to convert a number in the range -32767 to +32767 (thus 16bit) to the range 0 to 65535, you add
32767 to the signed number: -32767
+ 32767 (signed range) = 0 (unsigned range)
To conclude:
The same happens with that number you got; it is a 32bits number, signed.
You know that an unsigned 32bits number goes from 0 to 2^32-1, thus from 0 to 4294967295.
(^32 because there are 32bits to be used. And -1 to compensate for the number 0)
So, a signed 32bits number goes from -2^31+1 to +2^31-1, thus from -2147483647 to +2147483647
(^31 instead of ^32 because there is 1 bit used for the sign. And +1/-1 to compensate for the number 0)
So to get your unsigned 32bit number (the true raw colornumber) you must add 2^31+1 to that number:
-256438 + 2^31+1 =
-256438 + 2147483649 =
2147227211
To work with it:
Now, instead of storing the number as a signed number and then calculate the unsigned number from it when you read it again, you could also store it directly as a unsigned number of course. There are functions for that in each programming language, thus including C++
Also, some functions do accept a signed number and will correctly interpret/convert it to the correct value automatically, so you don't need to do anything at all. This can depend on the programming language and/or the type of function you use the number for.
Hope I made some sense...
/ 
