Handling different resolutions.

[Linux-SWAT]

Hi !

When developing a game, how to handle different resolutions if you want the application to be displayed on different screens/resolutions ?

Are different sizes of sprites used ?

How to handle different screen ratios ?

 

[mjohansson]

I dont know how to change resolution ingame, its surprisingly complicated it seem.

I guess you mean 2D games since you talk about sprites and there are no difficulties with 3D except screen ratio perhaps?

float pixel_to_gl_X = (float) 2.0/(screen_width/pif), pixel_to_gl_Y = (float) 2.0/(screen_height/pif);

were 2.0 is the openGL -1 to 1 range, from left border to right, or lower border to top screen border.

and "pif" is pixel factor were 1.0 is one pixel in game = 1 pixel on screen and 2.0 would mean 1 pixel ingame is rendered with 4 pixels on screen (2x2).

then I used the normal size of the images in pixels as coordinates and multiplied with the pixel_to_gl_ for respective height or width value when creating the polygons to render. That naturally takes care of aspect ratio also unless you want to modify it so its not square pixels, then you could add a new factor to multiply width or height with when creating polys to render if dynamic or in the above variable declaration for example if only static is needed.

 

[slaeshjag]

I usually handle it with tiles in a few different sizes, 32x32, 48x48 etc, and then let the amount of visible tiles vary a little between screensizes. When the difference becomes too great, it steps up the tile size. As long as you make sure your UI knows its place with varying resolutions, it works quite well. Especially if you center the "baseline" for the tiles around common resolutions like 800x480 for 32x32, 720p for 48x48 etc.

 

[Linux-SWAT]

Sounds like both of you have a different method.

Dynamic and static.

How does the resize is handled ? Pre-calculation is suppose, then loaded from memory ?

What about the game scene, when you want it to be 4:3 or 16:9 etc ?

 

[mjohansson]

I had a system that stored tilemaps in sectors were a sector was the display size, then it rendered 9 sectors tiles, and the sector a tile was linked to had to be recalculated for different resolutions, I made a function that did that.

That was very fast for rendering and collision detection since you didnt have to go through a hole maps tiles to check stuff you just went through whatever tiles were linked to current 9 sectors, that meant maps had no size limits for performance wise.

The sprites alwasy rendered square and 1x1 pixels, unless you wanted otherwise, and how much content that fit on the screen is what you ended up seeing, OSD and menus ofcourse used cordinates corresponding to screen.

So how to handle differnt size screens is a design choice, do you want 1x1 pixels or double pixels or is it ok to scale freely to adjust a pre determined game world size to screen? How does it influence the game to see more or less of the game world dpending on what resolution and aspect ratio a display have? You can draw black bars to cover up, but you cant add physical screen to display more.

 

[Linux-SWAT]

If the screen is shorter on a device and I don't want to be able to shoot enemies who are supposed to be outside the screen (in larger screens). Also not rendering this outside is better.

How do I think that (not in a matter of code)?

 

[PokeParadox]

I prescale sprites based on a scale factor of the native resolution and the current resolution

 

[Linux-SWAT]

Doesn't scaling may cause nasty aliasing sometimes ?

 

[PokeParadox]

It can do. But you can scale in different ways. And if you are prescaling. The only hits are initial load time and ram usage. But if you manage this correctly they might not be an issue.

Examples:

http://projectinfinity.org.uk/doku.php?id=devblogsokeparadox:you_win_some_you_lose_some#pokescaler

http://projectinfinity.org.uk/doku.php?id=devblogsokeparadox:smooth_criminal#smoothing_filter

 

[Linux-SWAT]

Is it actually zoom in or out ?

 

[mjohansson]

If the screen is shorter on a device and I don't want to be able to shoot enemies who are supposed to be outside the screen (in larger screens). Also not rendering this outside is better.

How do I think that (not in a matter of code)?

If your using openGL then calculating the screen position could give you a TRUE or FALSE value for determining if an enemy can be hit or not, like:

xpos = ( enemy_X - camera_X ) * pixel_to_gl_X;

if( xpos < -1.0 || xpos > 1.0 ){enemy_can_be_hit = false;}

else{enemy_can_be_hit = true;}

There are always a 1000 ways to solve any coding problem, as you make things happen and recode and recode you will build up your own prefered ways of doing things and finding out how to optimise or when optimisation is not wanted in favor of simple and easy to deal with code.

 

[PokeParadox]

Is it actually zoom in or out ?

Yes in penjintwo its all object oriented so only the rendering is scaled the physics is the same. All render objects and position objects have access to the scale factor.

 

[Linux-SWAT]

@mj, well it's more calculation, but at least, it's a working solution.

@pp, I'm not sure to understand :/ .

 

[foxblock]

I usually go the lazy way and code my game to a very specific resolution then either use the scaling of the graphics card/monitor when using SDL_Fullscreen or implement a simple scale2x (or 4x) algorithm.

Advantage for this is basically simpler code (you just don't care for the resolution), disadvantage is that you don't really get resolution options...

For Project4 I actually draw all graphics by code, so scaling becomes a non-issue. SDL also has an event that gets called when you resize the window, so reacting to that is easy (though usually you want to limit this to certain aspect ratios)

So yeah I also would be interested in how to do this properly, myself.

One problem that always comes to mind though is the amount of information shown on screen. This has to be constant over all resolutions in most games (especially puzzle games where some puzzles rely on visible or hidden information).
This becomes tricky as Linux SWAT pointed out with multiple aspect ratios and stuff.

Especially with sprite-based games offering multiple resolutions might add a lot of (boring) work (creating multiple versions of the same sprite). One might go for very high-res graphics and scale them down for any resolution, this seems to be the easiest option to me, however these graphics need to be crafted very carefully. This does not work if you are going for the standard indie game SNES look though.

Simply scaling sprites up usually is not an option when going outside integer scale factors.

 

[PokeParadox]

@mj, well it's more calculation, but at least, it's a working solution.


@pp, I'm not sure to understand :/ .

Hmm OK. I'll try to write up an example later.

 

[PokeParadox]

Well I typed this ver quickly on my lunch break. I've not included any code samples because that would have taken longer, but hopefully it explains how I handle different resolutions.

http://projectinfinity.org.uk/doku.php?id=devblogsokeparadox:revisiting_scaling

 

[sebt3]

When I started what became shmuppan, I was planning to support caanoo and pandora.

So what I have put into place is using GL(es) scalling coupled with a texture scalling using scale2x at upload time.

Because of the difference in aspect ratio, I planned to use to have short unplayable zone to accomodate with the distorsion.

But as I sold my caanoo (for money reason) I dropped all this and did all at pandora resolution...

 

[Linux-SWAT]

@pp I have to think about that, how the objects define the gamezone, not the contrary.

 

[Rockthesmurf]

If the target device only needs to run at one resolution, at build time you can create assets specific for the device, we do this when possible, create the assets at 5X (for us this means 2400x1600 screen size) then resize with nice filter.


At runtime, we pick the best resolution assets that are available, in terms of what is visible on screen, we have no relationship between the texture dimensions and the on screen sprite dimensions. A sprite has a target size (and a bunch of UV coordinates).


In terms of controlling how much is displayed on screen that is done by setting up an appropriate camera, ignoring aspect ratio, you can set up a camera to have an orthographic region of 800x480 and that will be the amount of stuff that fits to the screen regardless if you are running at 480x320, 800x480, 2048x1536 etc.


With regards to aspect ratio, that is solved based on game requirements, in some cases, a stretched image maybe okay, in which can your 800x480 camera on an 800x600 screen will be fine (everything will be vertically stretched), alternatively, you can either:


1. Do a proportional scale that fits the 800x480 to the screen, allowing extra to be seen, so a 800x480 game running on an 800x600 screen will show an extra 120 pixels above/below the screen.


2. Same as above, but constrain so some of the image is cut off, so the 800x480 game run on an 800x600 device would have an orthographic region on the X of 100 to 700 and a Y of 0 to 600. This means the 800x480 game will not display 200 pixels from the left/right of the screen.


3. Use borders, so basically like 1. but instead of showing more game, show border.


Sometimes you can use a combination, so allow a little non aspect correct stretch and allow a little extra to be visible.


Once you know what you want to do, it is easy (small amount of code) to set up appropriate viewpoint and projection matrices for the required camera.