Game Development Reference
In-Depth Information
Out of those 128 characters, 95 are printable (characters 32 to 126). Our bitmap font contains
only printable characters. The first row in the bitmap font contains the characters 32 to 47, the
next row contains the characters 48 to 63, and so on. ASCII is only useful if you want to store
and display text that uses the standard Latin alphabet. There's an extended ASCII format that
uses the values 128 to 255 to encode other common characters of Western languages, such
as ö and é. More expressive character sets (for example, for Chinese or Arabic) are represented
via Unicode and can't be encoded via ASCII. For our game, the standard ASCII character set
suffices.
So, how do we render text with a bitmap font? That turns out to be really easy. First, we create
96 texture regions, each mapping to a glyph in the bitmap font. We can store those texture
regions in an array as follows:
TextureRegion[] glyphs =
new
TextureRegion[96];
Java strings are encoded in 16-bit Unicode. Luckily for us, the ASCII characters we have in our
bitmap font have the same values in ASCII and Unicode. To fetch the region for a character in a
Java string, we just need to do this:
int
index = string.charAt(i) - 32;
This gives us a direct index into the texture region array. We just subtract the value for the space
character (32) from the current character in the string. If the index is less than 0 or greater than
95, we have a Unicode character that is not in our bitmap font. Usually, we just ignore such a
character.
To render multiple characters in a line, we need to know how much space there should be
between characters. The bitmap font in Figure
9-7
is a
fixed
-
width font
, meaning that each glyph
has the same width. Our bitmap font glyphs have a size of 16×20 pixels each. When we advance
our rendering position from character to character in a string, we just need to add 20 pixels. The
number of pixels we move the drawing position from character to character is called
advance
.
For our bitmap font, it is fixed; however, it is generally variable depending on the character we
draw. A more complex form of advance calculates the advance by considering both the current
character we are about to draw and the next character. This technique is called
kerning
, if you
want to look it up on the Web. We'll use only fixed-width bitmap fonts, as they make our lives
considerably easier.
So, how did we generate that ASCII bitmap font? We used one of the many tools available
on the Web for generating bitmap fonts. The one we used is called Codehead's Bitmap Font
file on your hard drive and specify the height of the font, and the generator will produce an image
from it for the ASCII character set. The tool has many options that are beyond the scope of our
discussion here. We recommend that you download CBFG and play around with it a little.
We'll draw all the remaining strings in our game with this technique. Later, you'll see a concrete
implementation of a bitmap font class. For now, let's get back to creating our assets.
With the bitmap font, we now have assets for all our graphical UI elements. We will render them
via a sprite batcher using a camera that sets up a view frustum that directly maps to our target
resolution. This way, we can specify all the coordinates in pixel coordinates.
