While there are some similarities between these two images, they hardly look the same, too much information is missing. If you try to display a large resolution image on a small resolution CRT, you'll end up with similar results. Typically, columns and lines are either averaged together or simply removed. The greater the difference in resolution size, the greater the loss, the more profound the effect.

But what happens if you reverse the situation, if you display a small resolution image on a large resolution CRT? This happens all the time and it's where everything gets interesting, especially when you factor in CRT refresh rates.

Notice here that the aspect ratio is all wrong. Recall, that the aspect ratio tells you how much wider an image is than it is tall. If you measured your CRT, its width and height, then you would find that it is 1.3 times wider than it is tall. This is because CRTs traditionally have an aspect ratio of 4:3. This is also why CRT manufacturers typically only give you the diagonal measurement for their monitor, for if you know the aspect ratio is 4:3 you can calculate its exact dimensions.

The above picture has an aspect ratio of 32:12. It is 2.6 times wider than it is tall, a far cry from 1.3. If we correct the aspect ratio, then we get the following.

Now our original image is displayed with the correct shape; it has an aspect ratio of 4:3. But notice here that it's only taking up half our screen. It's exactly half the size of our original.

On the above CRT, what we are basically seeing is that if we display a 16x12 image in a 32x24 resolution, we end up with a perfect duplicate, albeit one of a different size. But why?

If you'll recall, both Windows and Linux use square pixels by default. There is a very good reason for this. If everyone uses square pixels, images are never distorted, even if they are drawn on top of each other or overlapping (which, of course, is exactly what happens in a GUI environment). This isn't because square pixels are unique, or even better, they are all just the same shape, square. Technically speaking, you could choose any pixel shape, so long as every one used that pixel shape, there would be no distortion. Since the 16x12 image uses square pixels and the 32x24 resolution uses square pixels, if we display our 16x12 image on a 32x24 resolution, no distortion takes place. So, with this in mind, we now know that we could also draw our 16x12 image in a 20x15, 24x18, or a 28x21 resolution, or in any other resolution that uses square pixels, and never distort our image. With a little algebra, we can see why this is true.

Known:

y_crt
x_game
y_game
4 : 3 = x_crt : y_crt = x_game : y_game

Unknown:

x_crt

Solve for x_crt in terms of x_game, y_game, and y_crt:

x_crt / y_crt = x_game / y_game
x_crt * y_game = y_crt * x_game Cross multiply
x_crt = (y_crt * x_game) / y_game Solve for x_crt

From the above formula we can see that when we set the display's number of pixels per line to 32, our display's pixel shape exactly matches our game's pixel shape, that is it's square (before our display's pixel shape was rectangular). Note, the aforementioned modes were calculated using this formula, as shown below.

x_crt = (24 * 16) / 12 = 32
x_crt = (21 * 16) / 12 = 28
x_crt = (18 * 16) / 12 = 24
x_crt = (15 * 16) / 12 = 20

We'll use this exact same trick later on to correctly display 224 line games in a 240 line resolution.

For whatever reason, many arcade games use rectangular pixels. This makes perfect emulation quite tricky, especially on Windows and Linux where pixels are square by default. So if we want to perfectly emulate games, we are going to have to do something to make up for this discrepancy. The most obvious, and probably the most popular technique, is to just translate the image's resolution into a popular GUI resolution, like 640x480 or 800x600. While at times this process can be lossless, more often than not, it isn't. If the display's pixel shape is a integer multiple of the image's pixel shape, then theoretically there should be no loss, otherwise, compromises must be made.

Below the pixels were stretched to fit the screen. Notice that some information was lost. It's impossible to tell you how much information gets lost each time you stretch an image to fit a screen, as it depends upon the pixel shape of the original image and the resolution the image is being translated to. Not to mention, there are many techniques for stretching an image, and they differ vastly in terms of losslessness and processing demands.

When we divide the columns and lines of a 16x12 resolution by two, we end up with pixels that are a perfect factor of our original, in this case 4. Every 16x12 pixel is exactly equal to four 32x24 pixels. Similarly, if we tripled the resolution, then every 16x12 pixel would be equal to every nine 64x48 pixels.

While the above translation works perfectly, it's not the most efficient method, especially in terms of processing demand. Notice that in the above image, half of the lines are perfect duplicates. So instead of doubling the number of pixels used, we could leave the columns as they originally were at 16 and doublescan the 12 original lines, which would leave us with a 16x24 resolution, pictured below.

Now we have a lossless duplicate of our original. The image has the exact same shape (a 4:3 aspect ratio) and it takes up the entire screen. Since the above CRT has the exact same refresh rate as our original 12 line per 60 second CRT, the game will also be in perfect vertical synchronization. But while the image is a perfect duplicate of our original at the pixel level, you may notice that there are some subtle differences between the two displays, namely the size of the scanline. On the 24 line per 60 second CRT the scanline is roughly half the size.

Before moving forward, you should now understand that (1) integer stretching the number of lines affects the size of the image's scanline (2) integer stretching the number of columns has no effect on the image at all (3) if the display's pixel shape differs from the image's pixel shape the image's aspect ratio will be incorrect, unless the display's pixel shape is an integer multiple of the image's pixel shape.