Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Android game resolutions

  • You cannot reply to this topic
7 replies to this topic

#1 MatejaS   Members   -  Reputation: 287

Like
0Likes
Like

Posted 27 April 2015 - 06:00 AM

Hello guys,

I'm making a retro pixel art game for Android using LibGDX.

Now I'm in the middle of getting it to work on different resolutions.

I've read about Viewport-s and I know there are lots of questions about this, but mine is a bit different.

I'm not asking for an implementation, but for the way the "professionals" do it.

Stretching is not an option because my graphics are pixel art and would look bad when stretched.

So there are two things I can do:

1. letterboxing - it seems like the simplest thing to do, but do other games actually do this? Would the player not like to see letterboxes?

2. making the world larger - as my game is a horizontal scroller type of game, I can add more vertical content such as show more ground / sky, but I don't want players with bigger screens to be able to see more (to the right) than those with smaller screens.

 

And whatever I decide, I still need a base resolution, a "safe area"... What should it be?

 

Thanks for your replies,

MatejaS



Sponsor:

#2 Olof Hedman   Crossbones+   -  Reputation: 3561

Like
5Likes
Like

Posted 27 April 2015 - 06:44 AM

Welcome to developing for mobile devices smile.png

Unfortunately it doesn't have a universal solution, specially if you try think about all devices (there are even devices with square screens!)

 

Stretching never looks good, so no-one uses that (I hope)

I think the most common way is your no2, show more of the world, just as you say, make sure to show parts that doesn't affect the gameplay. (too much)

Some games, rather then letterboxing, adds "decoration" outside. I think this works best with puzzle style games.

 

As for what base to use, I'd recommend using an aspect ratio around 16:9 as a base, since many of the most popular phones use that.


Edited by Olof Hedman, 27 April 2015 - 06:45 AM.


#3 Richard Wepner   Members   -  Reputation: 118

Like
4Likes
Like

Posted 27 April 2015 - 09:25 AM

So you're thinking about how to fill the entire screen on any device with any aspect ratio, and you have a side scrolling game (maybe even an endless runner), right?
If by "stretching" you mean scaling without keeping the aspect ratio, yes, that should never be an option - at least in my opinion.
 
It seems you already know that, but you'll need to set up your viewport/camera to always show the same amount of ingame content along the horizontal axis, since players with larger screens would see more of the environment otherwise.
That implies you'll need to fill the vertical space with something. This could be a solid color, a frame/border, more "ingame content", like the ground or the sky, some UI stuff, or a combination. Without knowing your game, I guess "more ingame content" could be a good option for your game.
If you're game is controlled by simple taps anywhere on the screen, or by horizontal swipes, you should consider to have a larger area at the bottom for the players finger, so he doesn't hide to much of the game. Angry Birds is a good example, since it has a big area at the bottom, which can be used for tapping. "Oh My Giraffe" on the other hand - even though it's a game I like - let's you either hide a big part of the left or of the right side, since you move the giraffes head by moving your finger on the screen. Not to mention the differences for left and right handed people...
 
You should also take a look at what similar games do. Jetpack Joyride sounds like a very similar one, and it does what I suggested you to do.
 
I also wrote about the topic of how to handle different aspect ratios. I tried to write as general as possible, so it should be applicable for any game, and there are some more examples as well. ;)

#4 MatejaS   Members   -  Reputation: 287

Like
0Likes
Like

Posted 27 April 2015 - 12:00 PM

Thank you very much Olof and Richard!



#5 MatejaS   Members   -  Reputation: 287

Like
0Likes
Like

Posted 27 April 2015 - 03:51 PM

I was thinking about this topic and I realized that by using Richard's method (which is IMO the best), I'll need to scale the content to fit the device.

That wouldn't be a problem if my games weren't pixel art.

But they are, and scaling pixel art by a factor not a whole number, such as 2/3, is not good because it will look ugly...

I've found some information on these sites:

http://www.badlogicgames.com/forum/viewtopic.php?f=11&t=15293

https://www.allegro.cc/forums/thread/612318

 

Is this a problem? And if it is, is there a workaround?



#6 L. Spiro   Crossbones+   -  Reputation: 18195

Like
5Likes
Like

Posted 27 April 2015 - 10:38 PM

As you may easily imagine this has been answered at-length many times.

http://www.gamedev.net/topic/667937-screen-resolution-map-size/#entry5225705

 

 

L. Spiro



#7 MatejaS   Members   -  Reputation: 287

Like
0Likes
Like

Posted 28 April 2015 - 03:13 AM

Thanks for the link L.Spiro!

 

Richard, now that I have thought about it, I think the formula for the screen height on your blog is incorrect.

It says: ContentHeight = ContentWidth * (ScreenWidth / ScreenHeight),

but shouldn't it be ContentHeight = ContentWidth * (ScreenHeight / ScreenWidth) ?

Also, when I calculate the height, then what?

I guess I should scale to fit the device, but as I said, I don't want to scale by something such as 2.25...

Based on Spiro's link, I assume I should find a base (constant) width that is a denominator of all the screen sizes? That's pretty hard with all the resolutions..



#8 LoneDwarf   Members   -  Reputation: 359

Like
0Likes
Like

Posted 28 April 2015 - 11:59 AM

For me the problem is mostly just the UI as my games are 3D these days. For 3D it's a simple FOV and viewport. I use the stretching option and it looks fine. Used it in 2D games also. Now I am sure there are some really small or large devices that don't look 100% but it's a reasonable solution. While some people will rage over this, you need ask yourself how much time you have to spend on this and how much of the market you want to please. I used this method on my Tank Recon games and they have over 10 million downloads to date. So they have seen plenty of different devices.

 

For fonts I use freetype to rasterize the fonts when the game first runs based on the screen size and cache them using local storage. Check your license for the font to be sure it allows for this. Fonts just don't scale well.

 

First I define a reference resolution, last game was 1280x720. All art is created using this resolution and all screens are built in that resolution. This resolution was chosen based on the most common resolutions on the market at the time and then rounded up somewhat so that most scaling would be down. Then I make a scale factor that is the real screen size (at run-time) divided by the reference screen size. The smallest scale is taken.

 

Vector3f vScale = vScreenSize / vRefSize;
float fScale = (vScale.x < vScale.y) ? vScale.x : vScale.y;

 

Now this scale factor is applied uniformly to all sprites in my UI. I have an asset manager that will just apply this when I request a sprite. For a 2d game you will need to use this scale factor to adjust your world units.

 

At this point all the sprites and fonts are scaled based on the screen size. Next is the layout. I design the screens vertically and somewhat relative spacing. The layout units are normalized to the screen size (0-100%). I use helper functions like these:

 

s32 hDipToPixels( float fPercent )
{
    return s32(fPercent* ((float)vScreenSize.x / 100.0f));
}
s32 vDipToPixels( float fPercent)
{
    return s32(fPercent* ((float)vScreenSize.y / 100.0f));
}

 

Here is a small taste of how I use the layout. This somewhat sugar coats it as there are more complicated cases where I will have to use more procedural layout. Still I don't think you can get away without it and it's not worth solving IMHO. I have to say I like this method and will continue to use it.

 

s32       navBottomMargin        = ui.vDipToPixels( 1.0f );
s32       topMargin            = ui.vDipToPixels( 1.8f );
s32       pauseLeftMargin        = ui.hDipToPixels( 1.0f );
s32       healthLeftMargin    = ui.hDipToPixels( 1.0f );
s32       healthTopMargin        = topMargin;

s32       shieldsRightMargin    = ui.hDipToPixels( 1.0f );







PARTNERS