How to correctly handle the multi-resolution mess?

plicatibu · January 2020

Hi.

Sorry for my ignorance in the theme. I'm pretty sure you guys have this resolved it since long.

I have many doubts about how to solve the problem correctly once and for all.

I read the docs in http://docs.giderosmobile.com/automatic_image_resolution.html kindly pointed out by @oleg as well as may topics in this forum about it.

I also read tutorial written by @oleg (https://simartinfo.blogspot.com/p/gideros-2.html).

But the solutions presented don't solve the problems to all available dimensions (please, correct me if I'm wrong).

Below we have some resolutions and their width:height ratio (as real and proportion numbers).

For iOS:

iPhone 4		320x480 	1.50	3:2
iPhone 4 (retina)	640x960		1.50	3:2
iPhone 5		320x568		1.78	16:9 (nearly)
iPhone 5 (retina)	640x1136	1.78	16:9 (nearly)
iPhone 6/7/8		750x1334	1.78	16:9
iPhone 6/7/8 Plus	1242x2208	1.78	16:9
iPhone X / XS		1125x2436	2.17	812:375
iPhone XR / XS Max	1242x2688	2.16	448:207
iPhone XR		828x1792	2.16	448:207
iPad Mini / 1 / 2	768x1024	1.33	4:3
iPad (retina)		1536x2048	1.33	4:3
iPad Pro 3		2048x2732	1.33	4:3
Apple TV		1080x1920	1.78	16:9

For Android devices:

360x640		1.78	16:9
480x800		1.67	5:3
480x854		1.78	16:9 (nearly)
540x960		1.78	16:9
600x800		1.33	4:3
600x1024	1.71	128:75
720x1280	1.78	16:9
768x1366	1.78	16:9 (nearly)
800x1280	1.60	8:5
900x1200	1.33	4:3
1080x1920	1.78	16:9

So it seems to me that I have to generate at least 2 versions of the game. One for screens whose resolution is 16:9 and other for screens whose resolution ration is 4:3.

So I grouped them by resolution ratio.

Joining all 16:9 resolutions, we have all these resolutions:
320x570
360x640
480x854
540x960
640x1136
720x1280
750x1334
1080x1920
1242x2208

For this case I would have:
360x640 -> bg@0.5.png
720x1280 -> bg.png
1080x1920 -> bg@1.5.png
1440x2560 -> bg@2.png

Joining all 4:3 resolutions, we have all these resolutions:
600x800 1.33 4:3
768x1024 1.33 4:3
900x1200 1.33 4:3
1536x2048 1.33 4:3
2048x2732 1.33 4:3

For this case I would have:
768x1024 -> bg@0.5.png
1536x2048 -> bg.png
2048x2732 -> bg@1.33.png

But it won't solve other groups os rations (3:2, 5:3, and others). It clearly states that My solution indeed is more a hassle than a real solution.

I also though in having some 5 or 8 base resolutions, don't take advantage of Gideros support for image automatic resolution and manually handle scaling, but it also doesn't sound as the correct approach.

Please share your magic tricks to efficiently handle this mess of screen resolutions. I promise I won't tell anyone

Thank you all.

hgy29 · January 2020

It is always a mess for me too at some point, but I basically do the following: I select a ‘typical’ ratio such as 1.7, make my canvas logical size accordingly and use letterbox scaling mode.
Then at runtime, I use getLogicalBounds to get the real screen bounds for things like background image or border anchored sprites.

I recently used another system too: my UI library can handle multiple aspect ratio and layout items differently if needed, for example one layout for portrait and another for landscape.

Apollo14 · January 2020

plicatibu said:

So it seems to me that I have to generate at least 2 versions of the game. One for screens whose resolution is 16:9 and other for screens whose resolution ration is 4:3.

You should keep in mind ultra-long screens too! (19:9, etc., they're becoming majority nowadays)

I guess it depends on particular project. In my projects I found that all I can do is to setPosition+YOffset.
My scaling is always == letterbox.

local minX,minY,maxX,maxY=application:getLogicalBounds()
YOFFSET=math.floor(math.abs(minY))
 
--suppose I have a bottom menu buttons 280x280px, and maybe some top gui buttons
--If I had to work with only 1280x720p screens, I'd just do that:
myBottomMenuButton:setY(1000)
 
--but nowadays it's wrong, because there are lots of ultra-long screen users
--so I'd better add YOFFSET to my menu coordinates:
myBottomMenuButton:setY(1000+YOFFSET) --this way my bottom buttons will always be on the bottom
 
myTopMenuButton:setY(0-YOFFSET) --and there won't be ugly black line if user has ultra-long phone

oleg · January 2020

You have to break the game interface into groups
And position them relative to the edges and center of the screen

function content() -- реальні розміри видимого екрана scrX центр centrX, і координати видимості сторін minX
	minX,minY,maxX,maxY=application:getLogicalBounds()
	centrX =application:getContentWidth()/2
	centrY =application:getContentHeight()/2
	scrX=(minX-maxX)*-1
	scrY=(minY-maxY)*-1
 
 
end
content()

I use a Windows player and an APPLICATION_RESIZE event for testing

stage:addEventListener(Event.APPLICATION_RESIZE,function()
 
	content()  --You define the edges of the screen
 
	-- Here you place the game elements around the edges of the screen
         gruop1:setPosition(minX+10,min-10)
         gruop2:setPosition(maX-(scrX/10*2),minY)
         gruop3:setPosition(maX-picWith,minY)
 
end)

Changing the size and proportions of the windows of the player you can see how your game elements are tied to the edges in different proportions of the screen

I set the zoom mode: "fit height"
logical dimensions 1200 * 1920
Background of the game I make height 1200 and width 1200 * 2 (for screens 2: 1)

oleg · January 2020

For this case I would have:
360x640 -> bg@0.5.png
For this case I would have:
768x1024 -> bg@0.5.png

Element proportions do not change, so you don't need to do suffixes for different screen proportions!

I do not use suffixes at all because I do not see any meaning in them

plicatibu · January 2020

Thank you all for sharing your point of views.

@Apollo14 Thanks for the heads up. I used the statistics from this site to check the most used screen resolutions: https://gs.statcounter.com/screen-resolution-stats/mobile-tablet/worldwide/#monthly-201812-202001.

You can edit the chart as you wish. I edited it to show data only for smartphones and tablets in the period between December 2018 to January 2020.

Regarding absolute positioning of the objects, I'm following the recommendations in @oleg 's tutorial. And it is working like a charm.

@oleg Thanks for sharing the snippet for testing the APPLICATION_RESIZE event. I'll implement it for my tests.

My concerns now are: background image size and distortion and effective area where to put objects in screen.

1 - Regarding background image and distortion.
I didn't like the result of using letterbox, because it gets fine for some resolutions but let horizontal / vertical bars in others.

Using many different backgrounds sizes, the stretch gave me the best results (some distortions are so low we won't notice it), but for some resolutions distortion is very noticeable.

Didn't I used enough variations of background images? Maybe.

2 - Effective area where to put objects.

Suppose that my logical dimension be 1024x768 and that my bg.png = 1024x768. If I add another bg@??.png that has 800x480, it implies that it will be areas of logical dimension where I cannot add objects, otherwise they won't show up for users whose devices resolution are 800x400, right?

Picture bellow illustrates what I'm trying to explain.

I think I'm complicating stuffs, but this issue confuses me a lot.

oleg said:

I set the zoom mode: "fit height"
logical dimensions 1200 * 1920
Background of the game I make height 1200 and width 1200 * 2 (for screens 2: 1)

So do you thing it works fine for vast majority of screen resolutions?

I'll give it a try on it, but I have some doubts about it:
- Using the strategy you told us, I understand that we:
* won't need to set image scales (@0.5, @1.5, @2, etc...) in Project properties.
* will use just images designed for the logical dimension.
* won't need to add that delta that takes in account real and logical dimenstions to position sprites. So I can just use, say mysprite.setPosition(100, 200).
Am I right?

- won't sprites be to small for devices whose resolutions are 480x854 and lower?

- a background of 1200 x 2400 won't use too much memory so that those devices whose resolutions are 480x854 and below don't crash? I'm assuming these are low end devices.

Maybe I should ignore low end devices, maybe not.

I know a guy that has a low end device that expends around $100 / month buying digital goods in the games he plays (is him an exception ?).

I'm all ears.

oleg · January 2020

1 - Regarding background image and distortion.
I didn't like the result of using letterbox, because it gets fine for some resolutions but let horizontal / vertical bars in others.

When using my method, there will be no stripes, the background will go beyond the screen and crop on square screens

* won't need to add that delta that takes in account real and logical dimenstions to position sprites. So I can just use, say mysprite.setPosition(100, 200).

No, you must specify the coordinates of the sprite, not absolutely, but relative to the edges of the screen or center
* mysprite.setPosition(maxX+150,CentrY-55)

- won't sprites be to small for devices whose resolutions are 480x854 and lower?

The sprite will automatically scale to fit the screen size

- a background of 1200 x 2400 won't use too much memory so that those devices whose resolutions are 480x854 and below don't crash? I'm assuming these are low end devices.

You can create 3 background sizes @1=1200 * 2400 and @0.5 = 600 * 1200 @0.25=300*600

-Indexes are used on different screen sizes, but with the same aspect ratio!

\

I know a guy that has a low end device that expends around $100 / month buying digital goods in the games he plays (is him an exception ?).

I test my game on very weak devices and everything works fine without multiple sprite size options.
But my weak device has very little memory, so it's more important that the apk file is small, so I don't add extra graphics to the file

ps, You can upload multiple apk files to Google's store for different graphics sizes and Google will automatically give the user an apk for his screen size

Apollo14 · January 2020

I guess it heavily depends on your project. Also you can check how your competitiors did it in their similar games.

antix · January 2020

All of my games use a set resolution and I use letterbox scaling. This is my init.lua file...

-- setup system stuff
stage:setOrientation(Stage.LANDSCAPE_LEFT) -- change to portrait or whatnot
application:setScaleMode('letterbox')
application:setFps(60)
application:setBackgroundColor(0x000000)
 
-- specify set dimensions
WIDTH = 960
HEIGHT = 640
MIDX = 480
MIDY = 320
 
-- get dimensions based on aspect ratio
MINX, MINY, MAXX, MAXY = application:getDeviceSafeArea(true)
 
-- correct values to get actual dimensions
ACTUALWIDTH = MAXX + -MINX
ACTUALHEIGHT =  MAXY + -MINY
 
print('WIDTH', WIDTH)
print('HEIGHT', HEIGHT)
print('MINX', MINX)
print('MAXX', MAXX)
print('MINY', MINY)
print('MAXY', MAXY)
print('ACTUALWIDTH', ACTUALWIDTH)
print('ACTUALHEIGHT', ACTUALHEIGHT)

It is pretty simple and always scales nicely. It gives the actual dimensions of the devices screen so you can resize backgrounds and whatever. Works for me

plicatibu · January 2020

Thanks for sharing. After performing tests using oleg's solution I may give it a try.

oleg · January 2020

plicatibu said:
Thanks for sharing. After performing tests using oleg's solution I may give it a try.

By the way, my method is suitable if you want your game to work in two screen modes portrait and landscape

In my game, the minesweeper , when turning the screen, the game adapts to the size and orientation of the screen:

Also the game adapts to screen proportions from 6 x 4 to 2 x 1
https://play.google.com/store/apps/details?id=ua.razorback456.saper

plicatibu · January 2020

Guys, I'm testing solution proposed by @oleg, but it is not working.

I'm 100% sure the misbehaviour is my fault, but I failed to find out what is causing the problem.

1 - I created 3 background images:
1.1 - br.png (dimensions 2400x1200).
1.2 - bg@0.5.png (dimensions 1200x600).
1.3 - bg@0.25.png (dimensions 600x300).

as shown below.

2 - I created 3 ball images:
2.1 - ball.png (dimensions 400x400).
2.2 - ball@0.5.png (dimensions 200x200).
2.3 - ball@0.25.png (dimensions 100x100).

Also shown below.

You can also see in the image below that all versions of bg and ball files were loaded to player.

3 - Tests procedure:
3.1 - I open player and set device dimensions

3.2 - I run the project to see how it will apear in player (I resize player to fit application dimensions with ALT+F key combination).

3.33 - close the player (to assure I won't forget to run project after changing player's resolution).

I expected that :
3.1 - for device resolutions 240x320, 240x400, 320x480 and 320x568 the image bg@0.25.png (600x300) would be used but instead the image bg@png (2400x1200) was used.

3.2 - for device resolutions 640x960 the image bg@0.25.png (600x300) would be used but instead the image bg@png (1200x600) was used.

3.3 - for device resolutions 900x1200 and 1080x1920 the image bg@0.5.png (1200x600) would be used. OK.

3.4 - for device resolutions 1242x2208 and 1536x2048 the image bg.png (2400x1200) would be used but instead the image bg@png (1200x600) was used.

At the bottom of this post you can see images of all cases I'm citing here.

The problem worries me more is regarding memory usage in low end devices. Correct me if I'm wrong, but for low resolution devices it's expected that they have less memory than the ones with higher resolutions.

Gideros is using the highest resolution images in devices whose resolution are lower (see case 3.1) and for higher resolution, it is using middle size images. Low resolution images were never used.

My understanding is that for small resolutions it would use images @0.25, for middle resolution it would use @0.5 images and for higher resolutions it would use the base images (bg.png and ball.png).

What can I be possibly doing wrong? The configurations of project and player can be seen below:

Following we have all images from cases 3.1 to 3.4.

Thank you all.

hgy29 · January 2020

Would you mind sharing your test project ? I don't see anything wrong in what you did, so let me check/debug it.

oleg · January 2020

@plicatibu See how I resize the screen:

I check different screen proportions.

To check different graphics sizes - you need to restart the player every time.
Well as @hgy29 said - we need to see your code

ps Set parameters local dimensions 1200 *1920 , And the background image size is 1200 * 2400 (2:1)

SinisterSoft · January 2020

It's the same issue I had (with the 'skinned' slots games) when trying to have a common assets folder with some 'default assets' in the assets folder and the linked folder assets taking priority over the ones in the assets folder. This works in the player, but not on export (the original assets overwrite the linked assets, possibly based on the order in the list?). see:
http://forum.giderosmobile.com/discussion/7987/is-it-normal-to-show-the-same-folder-twice-linked-and-not-linked-in-library-panel#latest

plicatibu · January 2020

I forgot to add the source code in the post.

You can see it here:

application:setBackgroundColor(0x000000)
 
local testbg = Bitmap.new ( Texture.new ( "images/bg.png" , true ) )
 
testbg:setAnchorPoint ( 0.5 ,   0.5 )
local halfWidth = application:getContentWidth ( ) / 2
local halfHeight = application:getContentHeight ( ) / 2
testbg:setPosition ( halfWidth , halfHeight )
stage:addChild(testbg)
 
local ball = Bitmap.new ( Texture.new ( "images/ball.png" , true ) )
ball:setAnchorPoint ( 0.5 ,   0.5 )
ball:setPosition( halfWidth , halfHeight )
stage:addChild(ball)

The complete project can be downloaded from
https://www.dropbox.com/s/61k7vorwhkwo1ez/image_size_test.zip?dl=0

plicatibu · January 2020

oleg said:

To check different graphics sizes - you need to restart the player every time.
Well as @hgy29 said - we need to see your code

As I wrote in my original post I always close the player after a test.

oleg said:

ps Set parameters local dimensions 1200 *1920 , And the background image size is 1200 * 2400 (2:1)

I'll set local dimensions to 1200 x 1920 (currently it was set to 1200 x 2400).

Thanks.

plicatibu · January 2020

@oleg I tested again with logical dimensions 1200x1920 and this is the result:

1 - image bg.png (2400x1200) was used in these lower resolutions:

240x320
240x400
320x480
320x568
360x640

1 - image bg0.5.png (1200x600) was used in these mid and high resolutions:

480x800
480x854
540x960
600x800
600x1024
640x960
640x1113
720x1280
750x1334
768x1024
768x1366
800x1280
900x1200
1080x1920
1242x2208
1536x2048

bg@0.25.png was never used and the use of bg.png in high resolution devices didn't happened.

oleg · January 2020

plicatibu said:
@oleg I tested again with logical dimensions 1200x1920 and this is the result:

1 - image bg.png (2400x1200) was used in these lower resolutions:

240x320
240x400
320x480
320x568
360x640

1 - image bg0.5.png (1200x600) was used in these mid and high resolutions:

480x800
480x854
540x960
600x800
600x1024
640x960
640x1113
720x1280
750x1334
768x1024
768x1366
800x1280
900x1200
1080x1920
1242x2208
1536x2048

bg@0.25.png was never used and the use of bg.png in high resolution devices didn't happened.

You did not specify an initial size index

oleg · January 2020

oleg said:

You did not specify an initial size index

ps//The suffix @ 1 should not be added to the drawing name!

ps//You do not need to close the player, just restart the application

plicatibu · January 2020

oleg said:

ps//The suffix @ 1 should not be added to the drawing name!

@oleg Thank you for your time and patience.

At first I didn't added the @1 suffix because the article Automatic Image Resolution don't use it.

I added it as you mentioned and it made no difference. You can see the new version of the project that uses the @1/1 suffix/scale in its properties from here: https://www.dropbox.com/s/4940i8usmvpjz67/image_size_test _v2.zip?dl=0

oleg said:

ps//You do not need to close the player, just restart the application

I know I don't need to close player all the time, but I prefer to do it to avoid forgetting clicking in the start button.

I uploaded a short video that shows I'm using the configuration you recommended and that even though it is not working as expected.

You can see it here, if you want:

(but I believe the use of project version 2 is more appropriate to discover something fishy.)

A I wrote before, I'm 100% sure your method works and that I'm making some silly mistake because you're a very experiente developer and told me it works for your projects.

I just can't see what I'm doing wrong or what I should have done and I didn't.

Regards.

oleg · January 2020

@plicatibu Yes, i have the same mistake

I think it's a bug gideros @hgy29

hgy29 · January 2020

oleg said:
@plicatibu Yes, i have the same mistake

I think it's a bug gideros @hgy29

Will look into it

oleg · January 2020

I have scaled the opposite, it works a little better

@1=600*300
@2=1200*600
@4=2400*1200

plicatibu · January 2020

@oleg I tested with @1, @2 and @4 as you told me and fir all resolutions until 800x1200 it seems the most appropriate images (low and mid resolutions) were used by Gideros.

From 900x1200 on Gideros used the high resolution images.

Results are much better now.

Thank you for your time and guidance.

hgy29 · January 2020

hgy29 said:

oleg said:
@plicatibu Yes, i have the same mistake

I think it's a bug gideros @hgy29
Will look into it

There was indeed a bug, image scales were sorted by an always 0 value instead of being sorted by scale, leading to this error. I fixed it in source code.

SinisterSoft · January 2020

@hgy29 On Android I wonder if it may help aab files (when they are split) if the different scale images were in the various folders within the resources folder. That way when google is making the various apk files it will use files appropriate for that machine - reducing the size of the apk in each case. It would mean the resources folder sub folders would have to be searched for images though by Gideros.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

How to correctly handle the multi-resolution mess?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

How to correctly handle the multi-resolution mess?

Comments