• 11
• 9
• 10
• 9
• 10

# Different Resolutions

This topic is 970 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm making a 2D game and for the 50 billion different resolutions and aspect ratios out there I was wondering what do you guys do for your graphics?

I know there are things like letter boxing or scaling to fit (which would distort my images). But I'm just wondering what other people have done or what a solid approach is?

##### Share on other sites

there are a number of ways to handle it.

1. whatever graphics you're using might do it for you automatically. for example, dx9 3d scales to whatever resolution you tell it automatically, however their d3dxSprite API does not.

2. draw at a single resolution, then strecthblit the results to the desired screen size.

3. use text and blit routines that convert to the current screen size on the fly.

i tend to prefer option 3.    the slick thing to do is select a graphics package, then write wrapper routines for its text and sprite routines that convert from virtual to screen coordinates. also write wrapper routines to convert mouse input from screen to virtual coordinates. choose a virtual coordinate system big enough to last you well into the future. back in the mid 90's, i chose 10000x10000 as a virtual coordinate system.  so you draw text and sprites to a virtual 10000x10000 pixel screen that the wrapper routines convert to screen coordinates on the fly. once you've written your text, sprite, and mouse wrapper routines, you now have a device independent graphics API you can use for all your projects.

but of course, being lazy, i started my last few projects hard coded at 1600x900. so my wrapper routines for those projects use a virtual 1600x900 screen size, not 10000x10000. as a result, it doesn't scale up quite as nicely as 10000x10000 would.

sounds like you haven't started yet, in which case i'd advise wrapper routines and a 10000x10000 virtual screen - unless devices will exceed that in the next 5-10 years.

note that mouse input wrapper also implies touch input wrapper, joystick input wrapper, etc. IE any input that usually arrives as screen coordinates must be converted to virtual before processing.

an example:

your virtual screen is 10000x10000.  you draw some text using virtual coordiates: so you say text(1000,1000,"click here!"), which draws at 1/10 screen width and 1/10 screen height from the upper left corner of the screen.  then when you check input, you do something like if isin(x,y,1000,1000,2000,1500) dostuff(). where 1000,1000,2000,1500 are bounding box virtual coordinates for the click area/hotspot/button, and x,y are the mouse click point converted to virtual coordinates.

both strechblit and wrapper routines are the same basic thing, the real difference being whether you draw everything then scale, or scale everything as you draw. implementing stretchblit can sometimes be easier, depending on the graphics package in question. but wrapper routines can yield better results, as individual text and blit routines can sometimes scale more accurately and with better looking results than simply stretching the whole screen to fit. also, generally speaking, scaling down tends to look better than scaling up. and obviously, scaling as little as possible looks best.

note that with stretchblit, you'll still need wrapper routines to convert input from current screen size to whatever screen size you draw in before strectblitting.  so with stretchblit, your native drawing resolution is equivalent to your virtual screen size when using wrapper routines for drawing text and sprites.

Edited by Norman Barrows

##### Share on other sites

I should have probably explained a bit more. I'm wondering how should I handle different resolutions in relation to pixel art and mobile devices.

I know that if I do not scale by a integer value my graphics will look bad. I'm also concerned with cases were I scale my graphics and then my game play areas are effected

This is a good example of what I'm talking about:

Lets say I draw everything at a 16:9 resolution (640x360) and someone with a weird resolution comes along 5:3 (800x480)

My gut reaction would be scale up

800/640 = 1.25

480/360 = 1.33333333

If I scale things up to fit then they are not going to look very good.

If I round up to the nearest integer value (2) and scale. My graphics should look good but this is where I'm kind of lost as of now.

Because 640x360 scaled by 2 is 1280x720, which is way bigger then 800x480.

Causing cut off on both vertical and horizontal sides, also this makes everything seemed zoomed in. Plus this could effect the game play I believe, as the player might not be able to "see" as much as someone where there device scales well. Which is why I feel totally lost at this point

##### Share on other sites
In that case, moving to Mobile & Console.

There are several questions about it, enough that I'm thinking I should add it to the FAQ.

There is no universal ideal method.  You need to figure out what specifically works for your game.

In addition to those Norman mentioned above, a common method is to have several different aspect ratios and scales, to do UI layout based relative to key points, and display the game in a way that best fits your game.

You might have a small 6" display with a small number of dots, or a large 11" display with a large number of dots. You might have a small 6" display with an enormous number of high resolution dots, or a giant 11" tablet with a small number of dots. You might have something in between. There are small phones that have over 500 pixels per inch; there are large tablets with under 90 pixels per inch. Your display may be portrait, or landscape, or even square.

For UI elements, the first thing to figure out is how big a finger touch is. For your game and your controls a UI element on a specific screen might be anything.  Consider that if you're on a Droid Turbo you've got 565 pixels per inch on a 5.2 inch screen. But on a 10.1" tablet with 800x600 resolution you've got about 90 pixels per inch.  So in those cases the small screen icon needs to be about five times bigger than the big screen's icon in order to take the same physical space.

Once you've figured out how big you need the icons, you need to figure out where to put them. Fixed layouts are easy, but often dynamic layouts are better for the player.  It is common to start in one of several key areas and spread out from there.  For example, starting in any of the four corners and then traveling horizontally or vertically out.  Or starting in the bottom center spreading out horizontally. You need to take care to avoid overlapping. If you're going up from the bottom left, try to not also go down from the top left.

Then you've got to do something to keep the game fair for the playing board.  In single player games it doesn't make much difference, but multiplayer games being able to see a bigger view of the field can be very important.  You need to decide how to make it fair when one person has a 640x480 screen and another has a 2560x2480 screen, playing against each other.  One player has more than 20 times more dots, do you show them 20 times the playing field? Or do you scale the playing field so they both see about the same number of items?  One player has a 3:2 display, another 4:3, another 16:9, is your game best by showing black bars, or is it better to show the content in that direction? The choices are highly dependent on the type of game you are playing.

The questions are basically the same for each app, but the answers variable by project:  Do the touchable things need to be a certain physical size (such as fingertip sized) rather than a certain pixel size? Do the UI buttons need to be in an absolute position or a relative position? Do the players need to see the same count of items, or the same quality of items? When screens are different, do the players need to have the same amount of content visible?

##### Share on other sites

As mentioned above, there are many ways to handle this. One way we dealt with this at a video game company I worked at was work in a fixed-height coordinate space. Instead of having all of your coordinates match up to pixels, come up with some arbitrary fixed height value (test it out though). The fixed height will be the domain of your screen's coordinate space. The width would vary between screen sizes, and you could find it by multiplying your fixed height value by the aspect ratio. That said, make sure all of your fullscreen background artwork produced with the height of your fixed-height value, and its width being whatever it is multiplied by your most extreme aspect ratio (most-likely 16:9, if working in landscape). Then, the sides would just be clipped on screens with fuller aspect ratios, most-notably the 4:3 aspect ratio. You'd design most of your UI in the middle of the screen, making sure it fits nicely in 4:3. You could attach certain UI elements to the edges of the screen so that they hug the sides regardless of fullscreen or widescreen aspect ratios. 9-slicing will be a huge part of this as well. A good deal of your panels and other large UI elements would most-likely be percentage-based if you want them to scale with the screen. The beauty here is that your UI is no longer resolution-dependent, and mostly not aspect-ratio dependent. You could get more creative, and have different resolution images for different resolution devices. For example, high-res iamges for Quad HD and 4K displays (many mobile devices are going Quad HD today). You could use lower-resolution versions of your images for lower-resolution devices --something I highly recommend. Lower-resolution devices are generally older devices as resolutions have been increasing almost every year. These older devices won't have the memory, or the GPU bandwidth to support these higher-resolution textures, so I'd suggest having some sort of content pipeline in place that automatically cooks up low-end builds with lower-resolution images.

Regarding having multiple resolutions of your game's assets, I'd use PC games as an example. With varying hardware and screen resolutions, gamers can usually lower graphical settings, such as texture resolutions, if there isn't enough resources to go around.

You can also use techniques mentioned above alongside this process.

##### Share on other sites
I have thought about this for a bit and trying to figure out what to do. As of now what I got:

So I have a min and max aspect ratio. Where my min aspect ratio is 3:2 and my max aspect ratio is 5:3
I draw all of my sprites, background, HUD elements, etc geared towards the 5:3 ratio. The resolution of this ratio also engulfs all of my other aspect ratios.

When it comes to the devices and graphics, I determine the scale factor by doing
xScale = deviceResWidth / TARGET_RES_WIDTH_53;
yScale = deviceResHeight / TARGET_RES_HEIGHT_53;

and scale it up or down based on this value.
Then when it comes to the logic and playing field these things are all geared towards the 3:2 resolution. Allowing everyone to be on the same playing field, no pun intended.

My other thought was to maybe just draw all the sprites geared towards the 3:2 resolution. Then have the backgrounds (maybe HUD too) drawn to the 5:3 resolution.
Then each one gets scaled accordingly

xScale = deviceResWidth / TARGET_RES_WIDTH_32;
yScale = deviceResHeight / TARGET_RES_HEIGHT_32;

xScaleBackgrounds = deviceResWidth / TARGET_RES_WIDTH_53;
yScaleBackgrounds = deviceResHeight / TARGET_RES_HEIGHT_53;



##### Share on other sites

I am a little bit confused how your solution looks right now but if I understood you correctly you "scale" your objects drawn "in the world" according to the aspect ratio of the game.

> You do realize that is what a projection matrix is for?

This is how every game works since 1947(not really). I don't really understand the problem with aspect ratio because there is none.

The screen is independent from the actual game and should have no influence on it. It is just a windows with which you can view into the videogameworld.

Just set up a proper projection matrix calculating in the screen size of the current device and let your gpu do the work for you.

##### Share on other sites

Sounds like your worried about graphic degradation during real time drawing routines. One way to combat this would be to resize during the buffer process; that way you can use a more complex filter without hurting performance.

##### Share on other sites

I don't really understand the problem with aspect ratio because there is none.

There can be a problem.  Here's a picture with four different screen sizes and aspect ratios.  (1440x900, 1200x800, 1280x800, 800x600)

The difficulty is that each person gets a different view.

It is not something that can be easily solved with scaling, since different aspect ratios mean that one player will be able to see more to the sides or more to the top and bottom.

In some games there is no particularly advantage or disadvantage to being able to see a different size field of view. If you are playing a turn based game or a single player game, or if each player's view makes no real difference, then feel free to show whatever fits on the screen.

In other games, like the example in the picture, more screen real estate means a big advantage in what you can select or activate. The player with the smallest screen (red) can only see a few units and will be surprised as more come on the screen. The green and purple players can select a bunch of buildings while seeing the same area as the red view, each has their own slightly different size; it is only 80 pixels difference, but if that means seeing units on the edge of the screen 80 pixels earlier, that is an advantage. And the lucky player with the full view of the area can see not only the battle and select all the buildings, but gets an even bigger advantage of watching other units walk in from the edge long before anyone else.

Some games use the dreaded black bars, although that isn't always bad.  Go back a decade or two and games like the Warcraft series (the thing the "world of" was based on) drew a beautiful decorative trim around the screen that was used for the UI buttons, no matter their screen sizes everyone was shown exactly the same view of the world that was potentially scaled.  Several of Westwood's RTS games back in the day had a similar technique to keep it fair.  The physical size could vary, but all players had exactly the same opportunity to view the same logical size view of the world.

If the size of a view port becomes something that provides a real advantage to certain players or a disadvantage to others, it is something that needs to be considered.