| Suppose
our theoretical game wasn't designed to run horizontally.
That is, it was instead designed to run on a vertically mounted
monitor and that the picture below represents this vertical
game in action (again, just bare with me here). |
|
|
| What
would happen if we tried and to run this game on our horizontally
mounted 12 line per 60 second CRT shown below? |
|
|
|
| Though
the above modeline works perfectly on our CRT if it is mounted
vertically, if we try to use it on the same CRT mounted horizontally,
we run into a bunch of problems. |
|
|
If
you carefully compare the image above to our original picture
(shown below), you will notice something curious. Namely,
the top two rows of pixels and the bottom two rows of pixels
are missing from our game. What happened to them?
Well, if you try to run a vertical game
on a horizontally mounted monitor, the axis switch, the
columns become rows and the rows become columns. So our
vertical 16x12 game actually becomes a 12x16 game. That
is, the 16 columns become 16 rows, and the 12 rows become
12 columns. Since our theoretical 12 line per 60 second
CRT only displays 12 lines of data and our game now
needs 16 lines, 4 lines of data are missing (16 lines -
12 lines = 4 lines). Consequently, after we've centered
our game, we find that the two top rows of pixels and the
two bottom rows of pixels aren't there. |
|
|
If
you'll recall, our 12 line per 60 second CRT takes
4 seconds to draw each line of data. If we wanted it to
display 4 more lines of data, we could logically deduce
that it would need 16 extra seconds to refresh its display
(4 lines x 4 seconds/line = 16 seconds).
So if we wanted to display the 4 missing
lines of our game, we would need to increase the time it
takes for our CRT to refresh its screen by 16 seconds. This
would give our CRT the time it needs to display all 16 lines
of data.
Though changing the refresh rate would
allow us to display the 4 missing lines of data, it would
also put our game out of vertical synchronization. When
an arcade game's frames per second don't match the CRT's
refresh rate, the game is said to be out of vertical synchronization
(or vsync for short). A game out of vsync can tear, appear
jerky during game play, or perform poorly. Consequently,
it's always a good idea to keep a game in vertical synchronization,
if at all possible.
As you'll recall, the faster a CRT can
scan a horizontal line, the more lines it can display in
the same amount of time. With this in mind, if we wanted
to display the 4 missing lines of our game, and we wished
to keep the refresh rate constant, then we would need to
increase our CRT's horizontal scanning rate. With a little
arithmetic we can see that if we change the scanning rate
of our CRT from 4 seconds/line to 3 seconds/line we will
be able to display all 16 lines in the same 48 seconds (48
seconds / 16 lines = 3 seconds/line) and in doing so keep
our game in vsync, as 16 lines x 3 seconds/line + 12 seconds
of blanking lines = 60 seconds. Obviously, this is a better
solution than changing our CRT's refresh rate. Unfortunately,
many monitors don't support multiple horizontal scanning
rates; that is, different speeds for scanning a horizontal
line. These monitors are fixed at a particular scanning
frequency. On fixed frequency CRTs, one must frequently
choose between either a perfect image or correct vsync.
As there is no single best solution for such CRTs, the choice
remains one of personal preference.
Lucky for us, our theoretical 12 line
per 60 second CRT turns out to support multiple horizontal
scanning rates, so we can configure it to display 16 lines
of data in perfect vsync, as pictured below. |
|
|
While
the above CRT now displays all 16 lines of our game, you
may notice that something still looks wrong. The image appears
to be "squashed." In truth it's too wide. The
aspect ratio is incorrect and needs to be adjusted. |
|
|
Known:
y_crt = (3/4) (x_crt)
x_game = (3/4) (y_game)
y_crt = (y_game)
Unknown:
x_crt
Solve for x_crt in terms
of x_game:
x_crt = (4/3) (y_crt)
Define x_crt in terms of y_crt
x_crt = (4/3) (y_game) Substitute
y_game for y_crt
x_crt = (4/3) ((4/3) (x_game)) Substitute
(4/3) (x_game) for y_game
x_crt = (16/9) (x_game) = x_game/0.5625 = (1.77) (x_game)
|
|
| With
a little algebra we can now see that in order to display a
vertical game on a horizontal CRT, we need to multiply the
number of columns by 1.77 (or divide by 0.5625). This will
give us the number of display pixels we need to use so that
our game has the correct aspect ratio. Since our game run
vertically has 12 columns, if we multiply that number by 1.77,
we get approximately 21. So if we configure our theoretical
CRT to display 21x16 at 1 refresh per 60 seconds, we'll end
up with the following. |
|
|
We
now have a lossless duplicate of our original vertical game
running perfectly on our horizontally mounted CRT. But while
the image is a perfect duplicate at the pixel level, you
may notice that there are some subtle differences between
the two displays, namely the direction of the scanline.
On the vertical CRT the scanline goes from top to bottom
and on our horizontal CRT the scanline goes from left to
right. Obviously, there is also some wasted space, as vertical
games run horizontally don't take up the entire screen (naturally
this all applies to horizontal games run vertically). |
|
|
