HTML and CSS Reference
Figure 13-5. 4:3 screen coordinates expressed as absolute and aspectRatio
A more robust and friendly approach to this problem is to define your layouts not in absolute values, given a
specific resolution, but rather in normalized layouts based on aspectRatio . Or, more specifically, instead of defining
the position of a screen element as [50, 200], you would define it as [0.001, 0.23].
Basically, for all two-dimensional rendering, you use a normalized coordinate system, in which one corner
represents the origin (0, 0), and the opposite corner diagonally represents the extents of the screen, in terms of aspect
ratio (1.33, 1.77, and so on).
For example, let's say that you use a normalized coordinate system in which the bottom-left of the screen is (0,
0), the x coordinate increases to the right, and the y coordinate increases upward. The y coordinate of the top of the
screen is defined as 1.0. The x coordinate of the right side of the screen is the screen's aspect ratio. Thus, on a 4:3
screen, these are the coordinates of the four corners of the screen, as shown in Figure 13-5 . In this simple example,
this means that y = 0.5 is always the vertical center of the screen,, and that x = aspect/2 is always the horizontal center
of the screen, regardless of physical screen size.
For drawing to the canvas, you'll need to adjust your final draw function to convert properly from normalized
space to canvas space. For instance, instead of simply calling drawImage with your xy coordinates, you would need to
pass in the values modified by the aspect ratio.
The main benefit of this process is that it allows you to reduce the number of quantized layouts that you have
to design for your game. Previously, when you were working in pixels as the unit of positioning, you needed a layout
definition for almost every combination of screen sizes. (To be fair, using a quantized bucket of layouts would get you
close, but you'd have no way of responding to edge cases.) Using a normalized coordinate system, however, lets you
define a handful of layouts, each targeting a specific aspect ratio. At worst, you'd need to support one file for each of
the unique aspect ratios listed in Table 13-1 for each orientation (portrait or landscape).
One thing to keep in mind is that even with a normalized coordinate system, you still quickly run into problems
regarding the size of the images you're trying to render. The previous technique can properly position them, but if
you've authored your sprite to be 64×64 pixels, it may still be incorrect in terms of screen resolution.
In general, anytime your canvas resolution, or dpi, changes, you're going to find a discrepancy with your content.
In reality, the previous sections are designed to be simple solutions to a very complex problem. The real problem
you're trying to solve for two-dimensional games is how to scale your individual sprites/images to match the proper
dimensions and dpi for your target screen.
If you considered a world where resources were free, then you would see that the solution to this problem is to
have a version of your two-dimensional content that exactly matches the resolution of the device on which it's being
experienced: smartphone, tablet, laptop, desktop, television, watch. The issue with this is that there tends to be an
unlimited number of resolutions and form factors on which to experience your content, and drafting pixel-perfect
versions of your content can be overly expensive.