Android Optimal resolution for mobile apps

kupo15

Member
It seems that no matter how experienced you are, resolution decisions are always tricky to solve. I've been working with desktop games forever and got that down pat but now I'm exploring mobile devices and wow, picking the proper resolution is a nightmare and much more tricky! This topic is specifically geared towards standard "static" apps instead of games. Think calendars, wishlists, memos, facebook etc... Things that mostly deal with text...not things like Flappy Bird, runners etc..

What are your go-to resolutions for developing these kinds of apps? I read that 1280x720 is the most common resolution these days. However, my S8 has 1480x720, 2220x1080,2960x1440. Someone's Galaxy Tab A 10.1" is 1920x1200. Who knows what other crazy resolutions other devices have.

I also read that developing in 360x640 is popular because it easily and evenly scales up to 720 and 1080. If that provides me with enough space its something I'm going to look into.

The main question I have is regarding these odd sizes. Upon further inspection, these odd sizes are standard resolutions just with a little extra space:


So even developing at 360x640 will still contain black bars equal to that last column on both sides. What do you do about this and these black bars? I never see these black bars on any apps I've downloaded. How do they manage this? Is this where design comes into play? Like, are they designing for the standard resolution and using the extra space as a bleed edge/overscan and don't put anything important in those areas? Or perhaps they shift the window up, double the blackbars on the bottom and cover it with a navigation bar?

If 360x640 is too small for my app, then even using a res of 960x540 won't go evenly into the common 1280x720 format and the text will be blurry I think. I'm viewing this app as a pixel art game where there is no tex interpolation because its mostly text based.
 

NightFrost

Member
I don't program for Android, but resolution matters are the same on desktop, with displays of various sizes existing. Productivity programs though, I would think they approach the resolution from other direction. They check the display resolution and pick that up as the view resolution, and the UI elements would get some size adjustment so they're not too small on larger resolutions. A spreadsheet for example has potentially thousands of rows and columns, but only the part that is seen is wat fits into the view, whatever size that may be. Of course productivity stuff isn't written with GMS, probably C++ (or whatever is used on Android) so there's no rooms, no views, just the display and the data. Only things that need to simulate real world measurements would work a little differently. A document editor simulating an A4 paper for example, might do something like "this is the display width, and text is set to this point size, and when I take them through this formula I know what size text should be so it simulates writing on A4." And they don't need to worry about turning fonts into sprites and blurry upscaling, they'd use ttf files directly to draw their text. Well, I would assume none of the OS UI stuff is pixel based, I'd think they're some sort of draw instruction based (vectors) so they scale effortlessly to any size.
 

kupo15

Member
I don't program for Android, but resolution matters are the same on desktop, with displays of various sizes existing. Productivity programs though, I would think they approach the resolution from other direction. They check the display resolution and pick that up as the view resolution, and the UI elements would get some size adjustment so they're not too small on larger resolutions. A spreadsheet for example has potentially thousands of rows and columns, but only the part that is seen is wat fits into the view, whatever size that may be. Of course productivity stuff isn't written with GMS, probably C++ (or whatever is used on Android) so there's no rooms, no views, just the display and the data. Only things that need to simulate real world measurements would work a little differently. A document editor simulating an A4 paper for example, might do something like "this is the display width, and text is set to this point size, and when I take them through this formula I know what size text should be so it simulates writing on A4." And they don't need to worry about turning fonts into sprites and blurry upscaling, they'd use ttf files directly to draw their text. Well, I would assume none of the OS UI stuff is pixel based, I'd think they're some sort of draw instruction based (vectors) so they scale effortlessly to any size.
Ahh that makes sense that they would be vector based. Didn't think about that.

I'm trying to make a wishlist program so its not exactly full on productivity program, but its not like a game either. More inbetween but I guess closer to game. So I would still have to figure out resolution and layout design based on phones that don't scale evenly with the res I build it at. Those devices will have blackbars, what should be done with that? Apps like chess.com has their game part but also menu navigation that is very much like what I'll be doing. It seems like the logical solution is to cover that portion up with the navigation bar or maybe treat it as a bleed edge and just extend the background?

Perfect example, like how do dating apps manage their resolution with devices that don't fit into their aspect ratio perfectly? That's not a game but also isn't productivity apps either.

Like take this app I found


The red top and the navigation bar and android nav bar at the bottom. Cleverly designed to hide the blackbars due to resolution conflict? Or maybe there is no resolution conflict for my phone but they decided to design the layout to have them included for all devices and treat it like a bleed edge in case there was? I wish it was easier to disable fullscreen mode for android to keep the android UI displayed

Here are three screenshots from chess.com app on three different phones.

Left Moto G6 Next Left Iphone8 Right 3 S8 (1480x720 - 2220x1080 - 2960x1440)

 
Last edited:

kupo15

Member
You should look at stuff like this if not already.
This tells you which resolution to optimise your game for wich to sacrifice.
https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions
Cool thanks! So it looks like targeting the top 5 would be a reasonable plan

1. 1080x1920
2. 750x1334
3. 720x1280
4. 1440x2960
5. 1440x2560

Takeaway from building the app at 360x640

1. This will scale up perfectly to 1 and 3 and 5.
2. 1440x2960 will scale up 4x perfectly width-wise but leave me with 200px black bar on the top and bottom
3. The second most popular res will be the worst to scale. Scale up at 2x which will leave a black bar width of 15 of each side, blackbar height 27 on top/bottom

How does this sound as a plan. Design the app at 360x640. Intentionally leave a bleed edge/overscan of ~8px on left and right and 50px top and bottom. I'll cover up the blackbars with some graphic that extends the background so its not a start black
 

RangerX

Member
You can always mix the strategies! I dont know why people rarely talk about it. I think your plan is pretty good.
Slightly different view sizes, overscan, etc. As long as your game looks good in the end and that the gameplay isnt negatively impacted.
 

Rayek

Member
I finally discovered an almost perfect solution to keep pixel art from distorting. No need for exact scaling, or dealing with exact resolution at non-decimal values.

This week I decided to work on a personal small pixel art game project over the holidays. And I did a bit of research on avoiding pixel distortion and related screen size issues with letter boxing. I watched Pixelated Pope's suggestions once again, but felt there ought to be a better method rather than having to endure all these limitations.

Then I happened upon these two articles:
https://medium.com/@michelotti.matthew/rendering-pixel-art-c07a85d2dc43
https://colececil.io/blog/2017/scaling-pixel-art-without-destroying-it/

I did a quick test. This is a zoomed-in screengrab of a zoomed-in viewport (get it? ;) )

pixeltest.png

Notice on the left, aliased original pixels which are distorted due to a non-decimal awkward zoomed 480x270 viewport resolution. The pixels look dreadfully distorted in places.

On the right, the version with the pixel art shader, which adds subtle anti-aliasing to all the edges. When viewed at the 1:1 resolution of the original viewport resolution, it scales up wonderfully well, and no visual pixel distortion occurs

Advantages of this method:

- pixel art looks great at any zoom level. No more visible pixel distortions. Pixels look square no matter what.
- rotating pixel art no longer results in very jaggy looking edges. Rotated sprites look very fine with no aliasing at all or ripped apart pixels due to nearest neighbour resampling.
- a camera zooming in and out does not cause ugly pixel distortions and jittering.
- viewport resolution becomes pretty much inconsequential: the pixel art is rendered visually non-distorted at any resolution.
- no longer is a fixed sized screen resolution required. Letter boxing can be avoided by providing simple logic to decide at what size the viewport should be rendered and displayed on any screen size and ratio.
- no discernible performance hit (according to what I read).

Disadvantage of this method:
- takes a bit more setup on the coding side.
- ever so slightly softer look. It is very subtle, but when set side by side a purist might notice. My wife did not, btw. (not implying she is a purist, of course...). On a retina screen no-one is going to notice this.
- the shader did not work with opengl 2. 3 is required.

PS I tested this in Godot, because I don't know how to work with custom shaders in GM, unfortunately, and I found a cookie-cutter ready example online for Godot. But this should be just as feasible to implement in GMS.

Source for the shader code (pure opengl shader code is in one of the referenced articles above):
https://github.com/CptPotato/GodotThings/tree/master/SmoothPixelFiltering

Perhaps someone can convert the code to GMS? Seems like a no-brainer to me. Unless someone can convince me why NOT to do this, I think this solves the viewport resolution and non-distorting pixel art conundrum.
 

rIKmAN

Member
- the shader did not work with opengl 2. 3 is required.

Perhaps someone can convert the code to GMS? Seems like a no-brainer to me. Unless someone can convince me why NOT to do this, I think this solves the viewport resolution and non-distorting pixel art conundrum.
That’s a shame, GMS2 only supports GLSL v1.

The info on this page of the manual links to some OpenGL ES Shading Language Quick Reference Cards and says only the last two cards are applicable to GMS2. The last two cards are v1.0 cards.
 

kupo15

Member
That is really interesting and cool stuff @Rayek ! Thanks for the info. Now you got me into a think again haha darn it! I'm still early but I've been developing with the pixel format in mind, not that I'm doing pixel art though. But a question I can't answer is, if my app is developed at 360*640 but my text is huge and scaled down to fit it, am I really developing at 360*640 and should I be developing at a slightly higher res? I guess I won't truely know until I reach out to artists to help with UI to. But then if I need to switch I will have a lot of coor altering to do. But I guess I also plan and am open to a drastically different design when more professional art comes along so it'll get redone anyway. At least I have the base code in place
 

RangerX

Member
Cool Rayek but that having blur instead of distortion is still ruining pixel art.
Its moving the problem around although it looks "less worse". Proper scaling always wins 100 times over all the possibles compromises in my opinion.
 

Rayek

Member
@RangerX I have done a number of side by side comparisons, and only with very obvious contrasting colours can I discern a minute anti-aliasing difference between a non-decimal enlarged version and the distorted non-aliased version in regards to sharpness. Yet the pixels of the distorted version just look wrong, while the version using the shader renders the pixels visually spot on without distortion.

More importantly, today I discovered one more advantage of this technique: when the screen is scaled 'properly', NO anti-aliasing is applied! No difference in quality compared to the older 'proper' scaling method!

So the best of both worlds: scaling a 480x270 screen by 2 or 3 or 4 times results in pixel perfect scaling with this method, just as before. At the same time, zooming in/out or scaling at a factor which completely distorts the pixels, the pixel art still looks nigh on perfect to the user's eyes.

In short, this shader approach allows for the best of both worlds, and the old method still works as before - in which case no quality degradation occurs. But it is of course impossible to cater for all screens, and in those cases when the user views the game at a non-optimal screen resolution, the pixel art quality is 99.9% retained, and letter boxing and visual pixel distortion can still be avoided.

What is not to like? Only advantages to this method, no disadvantages (excepting the opengl 3 requirement). The anti-aliasing only kicks in when it is needed at non-optimal screen resolutions or when zooming in or out programmatically.

I am however unsure whether this is achievable in GMS, since I learned that it only supports OpenGL V1 shaders. Which means the point is moot anyway for GMS devs, it seems.
 
Last edited:

kupo15

Member
I am however unsure whether this is achievable in GMS, since I learned that it only supports OpenGL V1 shaders. Which means the point is moot anyway for GMS devs, it seems.
This is so sad. Hopefully this can get supported soon! I see this feature as a great option for pixel art devs. They can give the option to the player if they want a letterbox or 99.9% quality. Plus the improved zooming capabilities are good.
 

kupo15

Member
I don't program for Android, but resolution matters are the same on desktop, with displays of various sizes existing. Productivity programs though, I would think they approach the resolution from other direction. They check the display resolution and pick that up as the view resolution, and the UI elements would get some size adjustment so they're not too small on larger resolutions. A spreadsheet for example has potentially thousands of rows and columns, but only the part that is seen is wat fits into the view, whatever size that may be. Of course productivity stuff isn't written with GMS, probably C++ (or whatever is used on Android) so there's no rooms, no views, just the display and the data. Only things that need to simulate real world measurements would work a little differently. A document editor simulating an A4 paper for example, might do something like "this is the display width, and text is set to this point size, and when I take them through this formula I know what size text should be so it simulates writing on A4." And they don't need to worry about turning fonts into sprites and blurry upscaling, they'd use ttf files directly to draw their text. Well, I would assume none of the OS UI stuff is pixel based, I'd think they're some sort of draw instruction based (vectors) so they scale effortlessly to any size.
You should look at stuff like this if not already.
This tells you which resolution to optimise your game for wich to sacrifice.
https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions
Well now I don't know what to do about resolution anymore lol Its not exactly the same as desktop because I feel like there is more control. I came across an interesting thing that happens with mobile, you can't rely on the actual resolution numbers to plan for in that resolution list.

Galaxy S10 : 1080x2280
Actual window size: 1080x2024

G3 Vigor: 1080x1920
Actual window height is less than 1920

The nav bars are taking away height and I assume its different height depending on the resolution. Is my 360x640 the correct ratio to target anymore? I get black bars with the Vigor that I didn't anticipate.

Should I be developing at some strange resolution like 270x506? I'd rather get black bars on the sides than the top I think
 

Mool

Member
I use (in praxis) for GUI Layer

Code:
gui_init(1280, 720, true, false);
and for Game (app_surf): 1280px x 736px

It looks good on my 1 080px x 2 160px phone and all other i have tested.

You shouldn´t care that much. I really hadn´t any user that blamed me for my resolution. (and i have a lot)

BTW if u have a 18x9 phone you get asked by android if u want to use 18:9. 90% of apps i downloaded didnt support 18:9 and u have 2 black bars.

Mool
 

Rayek

Member
An alternative approach is to expand the viewport to accommodate the screen aspect ratio varieties out there. The viewport will show a bit more or less of the game world, of course. It depends on the game whether this is acceptable or not.

The GUI elements should be positioned relative to the edges of the screen in this case.
 

kupo15

Member
You shouldn´t care that much. I really hadn´t any user that blamed me for my resolution. (and i have a lot)
Oh ok, so perhaps I should be caring more about responsive design than resolotion
An alternative approach is to expand the viewport to accommodate the screen aspect ratio varieties out there. The viewport will show a bit more or less of the game world, of course. It depends on the game whether this is acceptable or not.

The GUI elements should be positioned relative to the edges of the screen in this case.
Oh changing the viewport sounds like a great idea, viewPORT! haha I've been thinking so much about the game window and boxing myself into that, the port isn't something I ever thought about. I'll have to check that out and look into it. I'm making an app in the realm of whatsapp, venmo etc... so its not a game and this would be good. But don't games auto launch in fullscreen on mobile and wouldn't the viewport auto adjust to the phone window?

Should I be shifting everything over to the GUI layer instead of the normal draw event as well? I should still be adjusting the surface things are drawn on to match the phone screen. I think keeping things on the GUI layer will auto correct the size difference and keep things the same size compared to the draw event

If I shift things over to the GUI layer than won't viewports not do anything anymore?
 
Last edited:

kupo15

Member
I use (in praxis) for GUI Layer

Code:
gui_init(1280, 720, true, false);
and for Game (app_surf): 1280px x 736px

It looks good on my 1 080px x 2 160px phone and all other i have tested.

You shouldn´t care that much. I really hadn´t any user that blamed me for my resolution. (and i have a lot)

BTW if u have a 18x9 phone you get asked by android if u want to use 18:9. 90% of apps i downloaded didnt support 18:9 and u have 2 black bars.

Mool
Thanks, now I understand what to do and am on my way to implementing it. One last question related to all this:

How exactly is one supposed to use the display_get_dpix(y) functions? My understanding is that the pixel densities of phones are a way of creating a higher resolution by using a lower resolution...something like that. For example: The S10 has ~550 ppi density. From what I read, android uses PPI "buckets" and this ~550 falls under the 4x scaling bucket. This means that the actual resolution is not 1440 x 3040 pixels, but rather 360 x 760?

Does this function only apply to the GUI layer? Are there displays that have different densities in the x/y direction? I'm curious as to why there is an x/y version of this

I read that in the world of mobile developing, you should be designing for a display scale of 1x which relates to ppi (S8 has a scale of 4x because its a high density display but then downgrades to ~550)

So how would one use the get_dpi value to figure out the scaling for devices to design an app at the 1x scale? Compare the value to the different buckets and reduce the GUI display "surface" by that scale?

https://blog.prototypr.io/designing-for-multiple-screen-densities-on-android-5fba8afe7ead <--shows the buckets
https://buildfire.com/screen-size-resolution-importance/
https://blog.fluidui.com/designing-for-mobile-101-pixels-points-and-resolutions/
 

Yal

🐧 *penguin noises*
GMC Elder
I think the idea with the DPI functions is that you can optimize your graphics for size, as in, you might not want your text too small or people can't read it. Considering the size difference between a 1920x1080 phone screen compared to a 1920x1080 FullHD TV, using only display pixelage as a measure of how to scale your graphics might be too limited. Pixel density gives you that missing measure that ties a pixel's size to a real-world size measurement.
 
Top