Making Physics Based Side-Scroller Part 4: Screen Sizes and Resolutions

http://overlap2d.com/making-physics-based-side-scroller-part-4-screen-sizes-and-resolutions/

 

Today we are going to do a bit boring, but  important screen size and resolution management using Overlap2D inner workings on a bit low level.  Previously our Test Plarformer was running on fixed size 1280×800 which is a nice big size for a phone or tablet. I thought in this tutorial we will add 2 additional sizes 800×480 and 480×320 (we can’t add a bigger size, because well, we should have thought about it earlier when creating the initial project, and made a bigger images)

 Before you go any further, please update your overlap2d-runtime to the latest.
If you are just starting, go to Part 1 first.

Agenda

In this tutorial we are going to:

1. Create 2 new Overlap2D resolutions
2. Fix our 9patch button pixel problem for 480×320
3. Create a PlatformerResourceManager class
4. Find closes resolution match from available sizes for current screen size
5. Fix Problems with different speeds on different resolutions
6. Test with different sizes and enjoy

 

Creating new resolutions in Overlap2D

This one is easy so let’s get over with this quick. Run your Overlap2D and open the project you were working on. In the right top corner click “Create New” button, which will open up a dialog to create new resolution. New resolution creation will calculate relative sizes of texture and create a new atlas pack with images of new sizes packed in it. Usually you want to have more then one size of textures because smaller devices need smaller textures and have low memory, this means if you load into memory smaller png files for smaller screens, your game will be more optimized.

When dialog is opened you have to put inside new width and new height for your resolution, and change a base side for your resolution. When you have a platformer, you want more of the world from left and right be available for players with wider screens. while not compromising on the top and bottom parts (so players with all screen sizes will see same height, but different width) This means our height is our base, we are going to base all resolutions on height.

Create 2 resolutions this way both based on height, one – 800×4800 and other 480×320. It is up to you what to put in the “name” field. But I usually put the exact sizes with “x” in between for easier readability. It’s kind of an ID for your resolution. When done from the top right drop down you can switch between availible resolutions, and see how your game will look on them. Should look nice and scaled.

 

Problem with resizing 9patch buttons.

Remember we had 2 screens, one for game and other for UI? switch to our UI screen and then open up the 480×320 resolution. First thing you notice is that our button that was looking good before is kinda messed up now (If you used same images as I, and same numbers, the left side of button will be kind of gradient-ish) The explanation here is following:

As you know 9patches work by specifying the “repeat” part on them with a black pixel line on sides. That is done using draw9patch tool provided with android SDK. Because our button is so small, the repeat area is small too. When resizing Overlap2D tries to do it’s best to recalculate the 9patch areas, but sometimes when the difference is half of pixel, it has to decide to choose a whole pixel or no pixel. so on low resolutions you might get a black 9patch line to be a pixel left then it was needed. This has to be fixed by hand.

Find your overlap2D project files, and head tot he assets/480×380/images folder, this is where you will find our 9patch button image, if you look at it close our black line is slightly longer to the left by one pixel on both bottom and top. Open this image with draw9patch tool (which is in your android sdk tools folder) drag and drop your image there, and fix the line size to be only over the area that needs to be repeated (or just delete one pixel on the left using shift +click on it) When it looks good, save it, and close draw9patch tool. With your image being okay, you need Overla2pD to repack it. To do this, open your project, open 480×320 resolution, and while being on it, click Repack button on the top right side of the screen. It will take some time, and your button should look all good now.

So, that’s a neat trick you need to know if you plan to use overlap2d and 9patch UI items for production projects.

Do not forget to press Ctrl+E to export your new assets to your Java project assets folder.

 

Creating new resource manager

The Overlap2D resource manager was a good home to us, but from now on we need more flexibility. Run your Eclipse or Intellij, open up the project and create new class called PlatformerResourcemanager. Extend it from our good old ResourceManager, so it will have all of old functionality.

Several things we need to do now, Have a method that will load all the stuff we need, and also figure out what resolution fits our needs. Our screen size is decided either from size of your device screen, size of your computer screen app is full screenned, or size of the window if it is windowed. In our case size of the window is written in DesktopLauncher.java you can always figure out that size by calling libgdx method Gdx.graphics.getWidth() or getHeight(). Our mission is to decide which one of our 3 pre-created resolutions are best fit to the current screen size, for example if screen size is 750×460 then the closest match is 800×480, we need close match so stretching of screen will be minimal and we will have maximum quality for minimum memory.

 

Find closest resolution match from available sizes

Here is the main concepts you need to know. List of possible resolutions is in the file project.dt create by the editor. You load it by calling loadProjectVO() method of the ResourceManager, it then will return  you ProjectInfoVO type of object that has originalResolution in it which is your (orig) and it also has ArrayList of resolutions for other resolutions you created (in our case 2). Each resolution is a ResolutionEntryVO which has name, width, height and base. We are going to compare resolutions only by height, compare them to our current screen height, and find the one that has the minimum delta difference. And remember it somewhere.

Here is the full code for entire class:

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

packagecom.underwater.testplatformer;   importcom.badlogic.gdx.Gdx; importcom.uwsoft.editor.renderer.data.ProjectInfoVO; importcom.uwsoft.editor.renderer.data.ResolutionEntryVO; importcom.uwsoft.editor.renderer.resources.ResourceManager;   /** * Created by CyberJoe on 11/9/2014. */ publicclassPlatformerResourceManagerextendsResourceManager{       publicResolutionEntryVO currentResolution;       publicfloatstageWidth;       /**      * Inits all resources needed for this game      */     publicvoidinitPlatformerResources(){         // Loading project configuration file that keeps list of available resolutions         loadProjectVO();           // figure out the best resolution from the list of available resolutions for the existing screen size         currentResolution=getBestResolutionMatch(getProjectVO());           // Game stage width should be dynamic based on screen size, so if you have wider screen, instead of stretching         // It will be just more level visible for player.         stageWidth=Gdx.graphics.getHeight()/currentResolution.height*Gdx.graphics.getWidth();           // Sets working resolution, so init all resources will load in to memory resources of that resolution/size only         setWorkingResolution(currentResolution.name);           // loads into memory all needed assets         initAllResources();     }         /**      * This method finds the closest match from the available texture resolutions generated by overlap2d      * that are closest in size to the current screen size. The comparison goes by height.      *      * @param projctInfoVo      * @return ResolutionEntryVO      */     publicResolutionEntryVO getBestResolutionMatch(ProjectInfoVO projctInfoVo){         floatdeltaSize=Math.abs(projctInfoVo.originalResolution.height-Gdx.graphics.getHeight());         ResolutionEntryVO result=projctInfoVo.originalResolution;           for(inti=0;i<projctInfoVo.resolutions.size();i++){             floatnewDeltaSize=Math.abs(projctInfoVo.resolutions.get(i).height-Gdx.graphics.getHeight());             System.out.println(newDeltaSize);             if(deltaSize>newDeltaSize){                 deltaSize=newDeltaSize;                 result=projctInfoVo.resolutions.get(i);             }         }           returnresult;     }   }

Now when our class is ready we need to use it properly.

First of all we need to change our TestPlatformer class, create method to this:

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

publicvoidcreate(){           rm=newPlatformerResourceManager();         rm.initPlatformerResources();           inputMultiplexer=newInputMultiplexer();           gameStage=newGameStage(rm);         menuStage=newMenuStage(rm,gameStage);           inputMultiplexer.addProcessor(gameStage);         inputMultiplexer.addProcessor(menuStage);           Gdx.input.setInputProcessor(inputMultiplexer); }

Next step modify our Menu and Game stages to get the RM instead of creating a new one, and use it properly. The usage is slightly different, because game stage uses physics and menu stage does not.

for Game stage, we need to change constructor to start like this before loading the scene:

 

1 2 3 4 5

super(newStretchViewport(rm.stageWidth,rm.currentResolution.height));         this.rm=rm;         // This will create SceneLoader instance and configure all things like default resource manager, physics e.t.c         initSceneLoader(rm);         sceneLoader.setResolution(rm.currentResolution.name);

And the MenuStage is even easier:

 

1 2 3

super(newStretchViewport(rm.currentResolution.width,rm.currentResolution.height));         SceneLoader sl=newSceneLoader(rm);         sl.setResolution(rm.currentResolution.name);

Don’t forget to modify constructor parameterss and add some class variables if needed. (If something is off, compare with the source code on the github:

https://github.com/azakhary/platformer_tutorial

This should be enough to get this going,  now, if you go to your DesktopLauncher.java and change window size to something like 800×480 and then run the project, it should run using smaller textures, and look awesome. The only problem you notice is that things kinda go faster, sheep runs faster, jumps higher, platforms go further e.g. This is all because we had some numbers before that we used as is, without taking into account our stage size.

 

Scaling other variables according to resolution

We have several places we hard-coded numbers before, which needs to be fixed. This is Player controller that has fixed numbers for gravity, jump speed and max speed of movement. Then it is MovingPlatform class that has platform margin and speed both hardcoded and also loaded from custom vars. All this variables are number of pixels in one way or another, and when you work with other resolutions, you stage is different size, so number of pixels changes too. Overla2D although knows for how much. It keeps track of current multiplier for each resolution in any composite item. There are two variables, mulX and mulY each is saying how much the resolution is bigger on each axis. All you have to do is multiply your hard-coded values with this numbers. Gravity for example is a value of pixels on Y scale so it has to be multiplier by mulX and move speed of player is a value on X scale so it has to be modified by mulY. usually mulX and mulY are the same number, but when you have different aspect ratios they start to differ.  mulX or mulY values are “1” when your loaded resolution is “orig”. so plan your inital numbers according to the orig resolution.

Here are the code snippets:

 

1 2 3

moveSpeed=220f*item.mulX;         gravity=-1500f*item.mulY;         jumpSpeed=700f*item.mulY;

 

 

1 2 3 4

if(item.getCustomVariables().getFloatVariable("platformSpeed")!=null)             moveSpeed=item.getCustomVariables().getFloatVariable("platformSpeed")*item.mulY;         if(item.getCustomVariables().getFloatVariable("platformMargin")!=null)             margin=item.getCustomVariables().getFloatVariable("platformMargin")*item.mulY;

Run game now, and things should move on the same speeds and margins irrelevant of your screen size.

Other thing to try is to set your screen size to 900×480 for example. This will be a wide screen for 800×480 resolution. Our button will be still on the left. But you can see that more of the world is visible from left/right sides. That is because of this line we have in our PlatformerResourceManager:

 

1 2 3

// Game stage width should be dynamic based on screen size, so if you have wider screen, instead of stretching         // It will be just more level visible for player.         stageWidth=Gdx.graphics.getHeight()/currentResolution.height*Gdx.graphics.getWidth();

And this line in GameStage (but not MenuStage, compare the difference to understand it better)

 

1	super(newStretchViewport(rm.stageWidth,rm.currentResolution.height));

And that is it for today!

Enjoy running this on different resolutions/window sizes/devices. Next time we will get back to improving game again, but I thought this size/resolution thingie was important and might have been confusing!

As always, compare source codes with mine on github or ask in forums.