Wow, nvm - just figured it out.
Have alpha be first, not last.
But if someone could confirm that and/or check the above code I'd appreciate it.
I don't think you want to be dividing by 0xff, 0xffff, and 0xffffff, but rather by 0x100, 0x10000, and 0x1000000. In particular, 0xff00 / 0xff = 0x100 = 256, which is not in the range of 0 to 255. You can also speed things and use the shift right (>>) operator rather than divide:
unsigned int red = (hex & 0x00ff0000) >> 16;
VernonDozier
Posting Expert
5,527 posts since Jan 2008
Reputation Points: 2,633
Solved Threads: 711
Oh, you're right.
But actually, I dropped the system of using different members for red, green, blue, and alpha. I'm just using a single hex value as a member to save space.
Edit:
Just wondering, would this be any faster:
unsigned int red = (hex << 8) >> 16;
//or is it:
unsigned int red = (hex << 8) >> 24;
It would be the second one:
unsigned int red = (hex << 8) >> 24;
Which one is faster is a great question, one that I don't know the answer to but that hopefully others will.
VernonDozier
Posting Expert
5,527 posts since Jan 2008
Reputation Points: 2,633
Solved Threads: 711
Think about 64-bit portability (why not?): hex << 8) >> 24 does not work if sizeof(unsigned int) > 4.
Make user input argument safety in 100% portable manner, for example:
rzb::color::color(unsigned int hex)
{
m_alpha = (hex & 0xFF);
m_blue = ((hex>>=8) & 0xFF);
m_green = ((hex>>=8) & 0xFF);
m_red = ((hex >>8) & 0xFF);
}
ArkM
Postaholic
2,001 posts since Jul 2008
Reputation Points: 1,234
Solved Threads: 348