Screen resolution can vary a lot, especially in the Free Software, where you are not only targeting one platform, but dozens, everything from a wrist watch to a super computer might end up running your software. So its worth to consider, especially for 2D games, which resolutions should be supported and how the game can handle the wide varity of available resolutions.
The following table gives an overview about common resolutions in use today:
|320x240||4:3||GP2x, HTC Wildfire|
|640x480||4:3||numerous PDA use this resolution|
|800x480||5:3||ASUS Eee PC, Nokia N800|
|1024x600||~16:9||ASUS Eee PC 1000|
|1024x768||4:3||common LCD format|
|1280x1024||5:4||common LCD format|
|1440x900||16:10||common LCD format|
|1680x1050||16:10||common LCD format|
|1600x900||16:9||common LCD format, often found on 17" laptops these days|
|1600x1200||4:3||common LCD format|
|1366x768||~16:9||common resolution of HD-TVs, even so its not actually an official HD-TV resolution|
|1368x768||~16:9||common resolution of HD-TVs, even so its not actually an official HD-TV resolution|
|1920x1200||16:10||common LCD format|
|2560x1600||16:10||Largest Available Consumer Monitor|
The easiest solution to this problem is to use fully scalable graphics that adopt to the screen size. Most FPS 3D games use this solution as it can be accomplished with very little extra work. There are however a few things to keep care of:
- HUD elements must be positioned flexible so that they are properly displayed in different aspect ratios
- HUD elements must be provided in a high enough resolution to not pixelate on larger screens
Another solution, most used for third person games or strategy games, is the scalable playfield. Here the graphics stay the same size, but the visible area is enlarged. So the player can see a larger part of the gaming world on his screen. HUD elements stay the same size in this mode and special care must be taken that menus and other non-game screens also allow size changes.
When using the padding solution, the graphics stay again the same size, but the view isn't enlarged, instead black borders are added around the screen. This is the most simplest solution, as it doesn't need to scale anything, the resolution is stays fixed. While on some platforms the padding will be automatically done when switching into a non-supported fullscreen resolution, some other platforms, such as the OLPC, require the padding to be done manually.
Especially for small puzzle games an easy solution is to simply run the game in a window instead of fullscreen, this works well, however only on displays having the same DPI.
Fullscreen mode is not as problemless as it sounds, especially under Linux with LCD displays it happens quite often that non-standard display modes might not be properly supported. For example ScummVM provides only fixed ratio scalers, meaning the maximum resolution a 320x200 game can be played at is 960x720, that resolution however might not display properly on some LCDs.
(to be written)
DPI refers to dots per inch or to say it another way, it gives you the size of the pixels, the larger the DPI value, the smaller the pixels. While in the past the DPI of monitors has been mostly constant around 72dpi this is slowly changing. Meaning displaying a picture with a fixed resolution on two screens no longer has the same real world size. The OLPC for example provides 200dpi while LCD displays often have around 100dpi. This can cause quite some issues when the graphics in a game are not scalable, as elements that have been easily readable on a 72dpi screen, can get impossible to read on a 200dpi screen.