A few hundred years ago, I started writing a color picker for a "game" was I building -- and game that's a direct rip off of a bunch of other games already out there, but hey. It was more or less functional (and it looked pretty), but under the covers, it wasn't as elegant as it could be.

So I started looking into bitwise operations -- those arcane and frightening invocations that do pure magic with numbers -- and learned a thing or 10. (That's a little bit of binary humor right there! [That was terrible.])

Specifically, bitmasks using the bitwise AND operator (&). Here, take a look at what I've thrown together so far:

To "use," just click anywhere within the colored block thingy (including the solid blocks near the bottom) and drag; the text fields (and the color chip) will update accordingly.

Yes, I'm painfully aware that there are a few billion of these things already out there: I have a bad habit of reinventing the wheel. It's fun. I hope, in the next iteration, to have HSL sliders (and perhaps a prettied-up the interface -- though that might have to wait).

So back to bitmasks and bit shifting and all that stuff: I've recently learned that, essentially, a 32-bit representation of a color (in Flash, anyways) contains 8 bits each for the alpha, red, green, and blue components. Not news to anyone who's done anything with colors before, I'm sure.

By shifting bits and applying a bitmask, you can isolate just the component you want (in this example, A, R, G, or B). Say we wanted the red component of the color represented by the integer 4294864129 (which, by the way, is a lovely shade of orange).

In binary, 4294864129 is 11111111111111100110110100000001. When shifted 16 (2^4, or even 8*2) bits to the right, we get the decimal value -2 (11111111111111111111111111111110):

11111111111111100110110100000001 >> 16 // -2

In order to convert that value into something usable (for our purposes, something in the range of 0-255), we need to apply a bitmask of 255 (0xFF in hexadecimal):

4294864129 >> 16 & 0xFF // 254-2               & 255  // 254

The mask basically looks at the relevant portion of our integer and returns a new integer where the "on" bits match up:

11111111111111111111111111111110 // 4294864129                        11111111 // 255

Because all but the first bit matches up, our new integer is 254, or 0xFE in hexadecimal. 254 is a perfectly valid number for representing our red component -- and the correct number, given our example!

(I'm leaving out all kinds of stuff about the two's complement and other stuff regarding binary representations of negative numbers -- mostly because I'm still fuzzy on it.)

And there you have it! My one-night's worth of study regarding bit shifting and bitmasks! It's entirely probable that I've misunderstood aspects of this stuff, and that most of what you've just read is all wrong. All I know is that in my brain, all this stuff is starting to make sense!