Game Development Reference
In-Depth Information
We can do better—at the expense of losing a few colors—which is totally OK, since displays
usually have a limited range of colors that they can emit. Instead of using a float for each
component, we can use an unsigned integer. Now, if we use a 32-bit integer for each
component, we haven't gained anything. Instead, we use an unsigned byte for each component.
The intensity for each component then ranges from 0 to 255. For 1 pixel, we thus need 3 bytes,
or 24 bits. That's 2 to the power of 24 (16,777,216) different colors. That's enough for our needs.
Can we get that down even more? Yes, we can. We can pack each component into a single
16-bit word, so each pixel needs 2 bytes of storage. Red uses 5 bits, green uses 6 bits, and
blue uses the rest of 5 bits. The reason green gets 6 bits is that our eyes can see more shades
of green than of red or blue. All bits together make 2 to the power of 16 (65,536) different colors
that we can encode. Figure
3-24
shows how a color is encoded with the three encodings
described previously.
Figure 3-24.
Color encodings of a nice shade of pink (which will be gray in the print copy of this topic, sorry)
In the case of the float, we could use three 32-bit Java floats. In the 24-bit encoding case,
we have a little problem: there's no 24-bit integer type in Java, so we could either store each
component in a single byte or use a 32-bit integer, leaving the upper 8 bits unused. In case of
the 16-bit encoding, we can again either use two separate bytes or store the components in a
single short value. Note that Java does not have unsigned types. Due to the power of the two's
complement, we can safely use signed integer types to store unsigned values.
For both 16- and 24-bit integer encodings, we also need to specify the order in which we store
the three components in the short or integer value. Two methods are usually used: RGB and
BGR. Figure
3-23
uses RGB encoding. The blue component is in the lowest 5 or 8 bits, the
green component uses up the next 6 or 8 bits, and the red component uses the upper 5 or 8
bits. BGR encoding just reverses this order. The green bits stay where they are, and the red and
blue bits swap places. We'll use the RGB order throughout this topic, as Android's graphics APIs
work with that order as well. Let's summarize the color encodings discussed so far:
A 32-bit float RGB encoding has 12 bytes for each pixel, and intensities that
ï?®
vary between 0.0 and 1.0.
A 24-bit integer RGB encoding has 3 or 4 bytes for each pixel, and
ï?®
intensities that vary between 0 and 255. The order of the components can
be RGB or BGR. This is also known as RGB888 or BGR888 in some circles,
where 8 specifies the number of bits per component.
A 16-bit integer RGB encoding has 2 bytes for each pixel; red and blue have
ï?®
intensities between 0 and 31, and green has intensities between 0 and 63.
The order of the components can be RGB or BGR. This is also known as
RGB565 or BGR565 in some circles, where 5 and 6 specify the number of
bits of the respective component.
