Quote:
Originally Posted by vitorrd
The mistake lies in the use of the bitwise not, as ~0xFF00 is not 0x00FF but 0xFFFF00FF, therefore any error in the encoding would screw things over.
|
I tested my code with various values (0-255) and each time it returned correctly. If you are referring to someone using value(s) outside of 0-255 for any of the RGB values then yes I am aware this would then return erroneous values. I wrote the code with the understanding that the proper values would always be used; a clamp() call would be a good idea as a safeguard if anyone implements this into a plugin.
For anyone that is unsure of what is taking place:
The RGB holder
1111 1111 1111 1111 1111 1111
R = RGB >> 16
For red we want bits 17 through 24 so a shift of 16 to the right will leave us with only those bits:
0000 0000 0000 0000
1111 1111
G = ( RGB >> 8 ) & ~0xFF00
For green we need bits 9 through 16 so we need to shift right 8 and then the and-not operation to mask bits 9-16. (bits 1-8 now hold green)
RGB >> 8
0000 0000
1111 1111 1111 1111
Then do our bitmask, leaving just the green value
( RGB >> 8 ) & ~0xFF00
0000 0000
0000 0000 1111 1111
B = RGB & ~0xFFFF00
For blue we need bits 1-8 only so a bit-mask for bits 9-24 can be used.
RGB & ~0xFFFF00
0000 0000 0000 0000 1111 1111
__________________