487idea to use normalized screen coordinates. Normalized coordinates range from
zero to one along one of the two axes (but not both—see below), and they can
easily be scaled into pixel-based measurements corresponding to an arbitrary
screen resolution. This allows us to lay out our overlay elements without wor-
rying about screen resolution at all (and only having to worry a litt le bit about
aspect ratio).
It’s easiest to defi ne normalized coordinates so that they range from 0.0
to 1.0 along the y-axis. At a 4:3 aspect ratio, this means that the x-axis would
range from 0.0 to 1.333 (= 4 / 3), while at 16:9 the x-axis’ range would be from
0.0 to 1.777 (= 16 / 9). It’s important not to defi ne our coordinates so that they
range from zero to one along both axes. Doing this would cause square visual
elements to have unequal x and y dimensions—or put another way, a visual
element with seemingly square dimensions would not look like a square on-
screen! Moreover, our “square” elements would stretch diff erently at diff erent
aspect ratios—defi nitely not an acceptable state of aff airs.
10.4.4.2. Relative Screen Coordinates
To really make normalized coordinates work well, it should be possible to
specify coordinates in absolute or relative terms. For example, positive co-
ordinates might be interpreted as being relative to the top-left corner of the
screen, while negative coordinates are relative to the bott om-right corner. That
way, if I want a HUD element to be a certain distance from the right or bott om
edges of the screen, I won’t have to change its normalized coordinates when
the aspect ratio changes. We might want to allow an even richer set of possible
alignment choices, such as aligning to the center of the screen or aligning to
another visual element.
That said, you’ll probably have some overlay elements that simply cannot
be laid out using normalized coordinates in such a way that they look right at
both the 4:3 and 16:9 aspect ratios. You may want to consider having two distinct
layouts, one for each aspect ratio, so you can fi ne-tune them independently.
10.4.4.3. Text and Fonts
A game engine’s text /font system is typically implemented as a special kind of
two-dimensional (or sometimes three-dimensional) overlay. At its core, a text
rendering system needs to be capable of displaying a sequence of character
glyphs corresponding to a text string, arranged in various orientations on the
screen. A font is oft en implemented via a texture map containing the vari-
ous required glyphs. A font description fi le provides information such as the
bounding boxes of each glyph within the texture, and font layout information
such as kerning, baseline off sets, and so on.
10.4. Visual Effects and Overlays