Screen Resolutions

From FreeGameDevWiki

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.

Common Resolutions

The following table gives an overview about common resolutions in use today:

Resolution	Aspect	DPI	Devices
240x160	4:3		GameboyAdvanced
256x192	4:3		NintendoDS
320x240	4:3		GP2x
480x272	~16:9		PSP
480x320	3:2		iPhone
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
1200x900	4:3		OLPC
1280x1024	5:4		common LCD format
1440x900	16:10		common LCD format
1680x1050	16:10		common LCD format
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		30" LCD
1280x720	16:9		HD-TV (720p)
1920x1080	16:9		HD-TV (1080p)
2560x1440	16:9		Apple iMac
2560x1600	16:10		Largest Available Consumer Monitor

Scalable Graphics

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

Scalable Playfield

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.

Padding

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.

Window Mode

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

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.

FOV

(to be written)

DPI

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.