<< PREV | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | NEXT >>
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.


y_crt = (3/4) (x_crt)
x_game = (3/4) (y_game)
y_crt = (y_game)



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).

<< PREV | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | NEXT >>