I sqw and I tried this suggestion on *PISTACHIO BRAINSTORMIN** on how to make a good and adaptive screen ration. For every different screen size, let's say I put the perfect circle as a Texture in LibGDX and played it on screen. Here's the blueberry image example and it's perfectly rounded:

enter image description here

When I played it on the Google Nexus 7, the circle turn into a slightly oblonng shape, resembling as it was being flatten a bit. Please observe this snapshot below and you can see the blueberry is almost but slightly not perfectly rounded:

enter image description here

Now, when I tried the suggested code for aspect ratio, the perfect circle retained but another problem is occured. The problem is that I expecting for a view on center but instead it's been moved to the right offset leaving with a half black screen. This would be look like this:

enter image description here

Here is my code using the suggested screen aspect ratio code:

Class' Field

// Ingredients Needed for Screen Aspect Ratio
private static final int VIRTUAL_WIDTH = 720;
private static final int VIRTUAL_HEIGHT = 1280;
private static final float ASPECT_RATIO = ((float) VIRTUAL_WIDTH)/((float) VIRTUAL_HEIGHT);
private Camera Mother_Camera;
private Rectangle Viewport;


    // Camera updating...

    // Reseting viewport...
    Gdx.gl.glViewport((int) Viewport.x, (int) Viewport.y, (int) Viewport.width, (int) Viewport.height);

    // Clear previous frame.
    Gdx.gl.glClearColor(0, 0, 0, 1);


        Mother_Camera = new OrthographicCamera(VIRTUAL_WIDTH, VIRTUAL_HEIGHT);

Was this code useful for screen aspect ratio-proportion fixing or it is statically dependent on actual device's width and height?

**see http://blog.acamara.es/2012/02/05/keep-screen-aspect-ratio-with-different-resolutions-using-libgdx/#comment-317*


2 Answers 2


I see that you've already accepted an answer, but I feel I can add to it. I have written a blog post about this here. The gist of it is as follows:

enter image description here

"After a bit of research, I’ve come to the conclusion that most Android phones that I want to target have a 480×800-ish resolution. I’ve also noted that the smallest aspect ratio of any Android phone (held in landscape orientation) is 4:3, that is Android phones don’t get any ‘squarer’ than 4:3.

With this data in mind, I created a virtual game screen of 800×600. This means my game logic acts under the impression that the game is always running in a resolution of 800×600. All positions and velocities are absolute to that resolution. The game logic calls the render-helper class to render and load textures. This render-helper class scales the virtual game canvas to fit on the actual device screen. The textures are scaled by the same class at load time using the Bitmap.createScaledBitmap function. Drawing position coordinates are also scaled similarly. The scale is determined by:

Scale = Actual Screen Width / Virtual Screen Width.

In devices with wider screens, some of the virtual screen bleeds out vertically. Alternatively, I’d have to horizontal display black bars on squarer screens, which is plain horrible. To deal with this vertical overflow, I just draw the HUD elements relative to the vertical offset. This offset can be calculated using:

Offset = ((Scale * Virtual Screen Height) - Actual Screen Height)/2."

  • \$\begingroup\$ Most of the screens said that they hate screen view with the black margins/borders just to make the screen proportional without distorting the original shape, especially to perfect circles and squares. So you mean to say this is the only solution so that it will be independent from pixels of the actual screen size, meaning, you can drag while the sprite (blueberry) stays closely to the finger in any different screen resolutions (HVGA to HD)? \$\endgroup\$ Dec 5, 2012 at 11:44
  • 1
    \$\begingroup\$ Touch input is another, different matter. It can also be handled efficiently via this system. What the "virtual screen" does, is the decoupling of the "game space" with the "screen space". This will allow you to scale the game from 1920x1080 to 240x320 and everything in between. \$\endgroup\$
    – ApoorvaJ
    Dec 5, 2012 at 11:51
  • 1
    \$\begingroup\$ This method scales the sprites uniformly by the float "Scale", which I've indicated in the answer. Thus no distortion of proportion occurs. I suggest you take a look at my original blog post and try a basic implementation. Also, I don't understand what you mean by "spacer". I use Android.Graphics instead of OpenGL, but I think there will be a way to do this in OpenGL too. \$\endgroup\$
    – ApoorvaJ
    Dec 5, 2012 at 11:59
  • 1
    \$\begingroup\$ Let's say I use the LibGDX engine and I set it to black as the main background color under render() method. Next, some mathematical calculations to adjust the original screen view from the original screen size. And then, if the screen view is smaller than the screen size, it automatically display most in center and leaving it a black border (or if you change to green via Gdx.gl.glClearColor(0,1,0,1), then you have green border) and that's what you called "spacer." My boss and lead programmer suggested after he saw a sample game from our competitor that uses "spacer" to prevent overstretching. \$\endgroup\$ Dec 5, 2012 at 12:05
  • 1
    \$\begingroup\$ @TredeciesNocturne , I think this deserves a separate question. The short answer is viewers (at least on mobile platforms) want an aspect ratio that their device has. This means no visible black bars or offset margins. This is perfectly possible to do on most kinds of games. In summary, the implementation can vary. The most important thing is to keep the scaling process unnoticable to the user. \$\endgroup\$
    – ApoorvaJ
    Feb 8, 2013 at 20:30

I figure it out on how to stay center or inside the screen visibly (regardless of the device's screen aspect ration) by changing the value crop.x and crop.y as possible(basically set at 0). Regardless of the calculations to fit what's best for the screen and the whole game view, it will do.

crop.x = 0; //  I recommend this coordinate.
crop.y = 0; //  Default is 0 so that it will stay at bottom. It's a bit advance if you
            // put it on top leaving a "spacer" on it. Specify the Y-coordinate calcu-
            // lately.
  • \$\begingroup\$ Nice answer, David. However, I would suggest also to accept @ApoorvaJ's idea because it really helps you more and you might learn this another aspect ration for the viewer's pleasant to their eyes. That would also be depend on your next app project. \$\endgroup\$ Feb 7, 2013 at 11:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .