Handling various screen resolutions for mobile game is frequent topic. You have finnished your great new game and suddenly lot of problems appear. Part of game is not visible here or it is ugly stretched there or there are some ugly black belts. It is best to think about handling this already in the beginning of development.
In this tutorial I will present method that works for me and is quite easy to implement. I will use Phaser engine - great engine by Rich Davey from Photonstorm.com. In the bottom you will also find link to test project.
My requirements for final solution were:
- no black belts,
- avoid stretching as much as possible,
- universal solution I can use in future games (both portrait or landscape).
In past when I was handling different resolutions there were two edge cases: iPhone which is long and narrow and iPad which is short and wide. I will take these two devices as limits, but the solution will handle also resolutions beyond them.
Creating test image
First, let's decide on our default resolution. I will set it to 1280 x 800. Later we will see, we are not fixed to this. But what is important is, that aspect ratio for this resolution is 1.6. Let's create test image with this resolution like this:
As far as we are displaying this on devices with aspect 1.6, we are happy. Now, what happens if we want to display this image on iPhone? iPhone 4 has resolution 1136 x 640. If we scale above image down proportionally, saving aspect ratio then it will shrink to 1024 x 640, so we are missing 112 pixels (1136 - 1024). As a result we have black belts on each side, each 56 pixels wide. Or we can stretch the image, but then we are sacrificing aspect and it does not look good.
We can also go in opposite direction and ask: how big would be iPhone full screen image if we wanted to scale it so, that height is 800? Answer is: it has to be scaled from 1136 x 640 to 1420 x 800. So, let's adjust our test image like this:
If we now scale this image down from height 800 to 640 while preserving aspect we will go from 1420 to 1136 in width. On iPhone you will see additional space. This additional space is 70 pixels on image, but as it is scaled down on iPhone it will be only 56 pixels on real screen.
Now, let's do the same for iPad resolution. It is 1024 x 768 in landscape. To fill the width with green part of our image (1280 pixels) we have to scale it down to 1024 (80%). To preserve aspect it means we also have to scale down height by 80% from 800 to 640. We ended with black belts again! This time they are horizontal in top and bottom in total width 768 - 640 = 128 pixel (64 pixels each).
If we go in opposite direction (how high the image has to be to cover whole screen without stretching?) we end with resolution 1280 x 960. This scaled down by 80% will give us 1024 x 768. Test image for iPad looks like this:
In next step we will merge both test images. I added circle somewhere in the middle. It will visually indicate whether image is stretched or not. Final test image is like this:
We have test image. With it we can handle any device with aspect from iPhone's 1.775 (1136 / 640) through default 1.6 (1280 / 800) to iPad's 1.333. If we get device with aspect over 1.775 or below 1.333 we will stretch the final image to avoid black belts. For example, device will have resolution 1920 x 1080. It is aspect 1.777, so we will have to stretch the image a little. But it is already visually hardly noticeable.
The grey parts of test image will be never displayed on any resolution. In every case only the blue part or red part will be displayed ... or none of them if aspect is 1.6.
So it is good to design your full screen backgrounds like this and place some non-important content into blue and red areas as it may be displayed full, partly or not at all. Just for an example, look at this island image (by Tomas Kopecky from littlecolor.com) with test image over it:
The game will take part in the middle area. Blue and red areas will not be visible on some devices.
Changing default resolution
I think it is clear from the discussion, that aspect ratios are more important then absolute width and height. So, we can leave default resolution, as 1280 x 800 is still quite a big for HTML5 game. Let's say we start new game and we are deciding on resolution. As far as our new default resolution will keep aspect 1.6 we are OK. So, we will choose default resolution to 800 x 500. It is 62.5% of 1280 x 800. We can easily scale down whole test image with this value and we will get template for our new default resolution (of course, this will not recalculate or rewrite numbers on the image - there will be still 1280, 800, ...!).
The blue areas will not be 70 pixels on each side more, but 70 * 62.5% = 44 pixels (rounded up). And red areas will shrink from 80 pixels in height to 80 * 62.5% = 50 pixels.
Let's write some code!
It is time to write some code. I will use Visual Studio and typescript. I will not show here adjustment in index.html and app.css file as you can see it in final project.
After you create new project, go to app.ts and replace all generated content with this:
This will call our Game class which is derived from Phaser.Game. Add game.ts file and put this into it:
In constructor we are calling static method calculateScreenMetrics() in ScreenUtils class which is inside Utils module. This method takes default resolution for game as well as enum value which says whether the game will run in landscape or portrait. The returned object contains lot of useful information:
- windowWidth, windowHeight - dims of window the game will run in,
- defaultGameWidth, defaultGameHeight - our default resolution we passed into calculation,
- maxGameWidth, maxGameHeight - we can pass these values or it will be calculated for us in the method. If calculated by method then pixel limits are calculated from iPhone to iPad. In other words: if we pass as default 1280 x 800, the values calculated here will be 1420 x 960 (which is dimension of our original test image). If we pass 800 x 500 then result is 888 x 600,
- gameWidth, gameHeight - values to pass to Phaser.Game constructor - dimensions of game before scaling to fill window,
- scaleX, scaleY - how much to scale along x and y to fill window. As far as the window dimension is between iPhone and iPad aspect the scaling will be uniform,
- offsetX, offsetY - how many pixels (in the game dimensions) from the top left corner the central area starts. Actually, offsetX is width of left blue area and offsetY is height of top red area on the screen. As only red or blue (or none) area is displayed, one or both of the values will always be zero.
Now, we can call parent (Phaser.Game) constructor with calculated values for gameWidth and gameHeight. If window has aspect 1.6 then it will be called with default values.
In this example I am adding only one state, that will set ScaleManager values and load our test image. Add boot.ts file:
In init() method we are using Phaser's USER_SCALE method for scaling game to window. We also use here scaleX and scaleY values we previously calculated. The rest of the boot.ts file just loads test image and displays it:
Most important piece of code remains. Our reusable class for calculating screen metrics. Add screenutils.ts file. It starts with ScreenMetrics class. I already described all members above, so I will not repeat it here, only show listing:
Next definition of enum, that says whether game is in portrait or landscape follows:
And finally class ScreenUtils that contains calculateScreenMetrics() method:
First, we take window dimensions from browser:
Then we check if it makes sens for landscape / portrait game. For landscape the width should be higher than height. This should handle situation when landscape game starts in portrait. But I highly recommend to recalculate metrics and call ScaleManager's setGameSize() method when leaving incorrect orientation (this is not part of this example project):
After that we check if optional parameters on max width and height were provided. If not, we will calculate it by ourselves. Here are absolute values from our original test image used. But only as ratios to calculate how much to prolong default width for iPhone and default height for iPad:
Here comes calculation of game width and height and also calculation of offset in case blue or red area is visible (if window aspect differs from 1.6). Part of my original code is commented out as it turned to be duplication of code in the end:
Last values we have to calculate are scale values for ScaleManger:
Finally, we store all values for later use and return result:
We are finished. Let's see it in work. In Firefox if you press ctrl+shift+I you will open debug tools window. Locate this icon and press it:
Do not get confused with numbers on the image. We first created test image with 1280 x 800 in this article. But then we decided on default resolution 800 x 500 for new game and scaled test image 62.5% down. Of course, the scaling did not overwrote original numbers on the image for us! Green area is 800 x 500 (see test.png image in project's assets folder).
You see only inner green part as we used dimensions with 1.6 aspect. You will get the same result for 1600 x 1000, but this time the game scale values for x and y will be 2.0. Now expand the window horizontally to 888 x 500. For this resolution you will get maximum of blue areas and this resolution has aspect of iPhone (888 / 500 = 1136 / 640 = 1.775) ... ok, there is small rounding 1.776 vs 1.775 as ScreenUtils is setting size to whole numbers and multiplies of 2. But, no stretching! No black bars!
Now, expand window more to 1200 x 500. Aspect 2.4 is over max supported aspect (1.775 for iPhone). As we do not have any additional graphics beyond blue areas, we have to stretch horizontally. Notice, that this resolution is extreme and was used here just for testing purpose.
You can also play with height. Set dimensions to 800 x 600. It is iPad aspect and full red areas are visible. Adding more height would result in vertical stretching.