Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
How to correctly handle the multi-resolution mess? — Gideros Forum

How to correctly handle the multi-resolution mess?

plicatibuplicatibu Member
edited January 2020 in Game & application design
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 o:)

Thank you all.

Comments

  • hgy29hgy29 Maintainer
    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.
  • Apollo14Apollo14 Member
    edited 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) :D

    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
    > Newcomers roadmap: from where to start learning Gideros
    "What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
    “The more you do coding stuff, the better you get at it.” - Aristotle (322 BC)
  • olegoleg Member
    edited 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)
    image.png
    834 x 537 - 353K

    Likes: MoKaLux

    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
    +1 -1 (+1 / -0 )Share on Facebook
  • 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

    Likes: MoKaLux

    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
    +1 -1 (+1 / -0 )Share on Facebook
  • 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.
    multi_ratio_multi_resolutions.png
    660 x 383 - 75K
  • olegoleg Member
    edited 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
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • Apollo14Apollo14 Member
    edited January 2020
    I guess it heavily depends on your project. Also you can check how your competitiors did it in their similar games.
    > Newcomers roadmap: from where to start learning Gideros
    "What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
    “The more you do coding stuff, the better you get at it.” - Aristotle (322 BC)
  • 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 ;)

    Likes: MoKaLux, plicatibu

    +1 -1 (+2 / -0 )Share on Facebook
  • Thanks for sharing. After performing tests using oleg's solution I may give it a try.
  • olegoleg Member
    edited 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
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • 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.

















    01_bg_multiresolution.png
    369 x 226 - 26K
    02_bg@0.5_multiresolution.png
    376 x 210 - 23K
    03_bg@0.25_multiresolution.png
    363 x 213 - 26K
    04_ball_multiresolution.png
    372 x 208 - 36K
    06_ball@0.25_multiresolution.png
    359 x 213 - 25K
    05_ball@0.5_multiresolution.png
    369 x 211 - 36K
    07_images_loaded_to_player_multiresolution.png
    309 x 219 - 8K
    08_config_multiresolution.png
    498 x 597 - 7K
    09_player_orientation_multiresolution.png
    496 x 379 - 35K
    player_240x320_multiresolution.png
    336 x 299 - 9K
    player_240x400_multiresolution.png
    416 x 299 - 30K
    player_320x480_multiresolution.png
    496 x 379 - 29K
    player_320x568_multiresolution.png
    584 x 379 - 62K
    player_640x960_multiresolution.png
    976 x 699 - 130K
    player_900x1200_multiresolution.png
    616 x 509 - 42K
    player_1080x1920_multiresolution.png
    976 x 599 - 151K
    player_1242x2208_multiresolution.png
    1120 x 680 - 190K
    player_1536x2048_multiresolution.png
    1040 x 827 - 113K
  • hgy29hgy29 Maintainer
    Would you mind sharing your test project ? I don't see anything wrong in what you did, so let me check/debug it.

    Likes: oleg

    +1 -1 (+1 / -0 )Share on Facebook
  • olegoleg Member
    edited 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)
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • 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
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
  • plicatibuplicatibu Member
    edited 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
  • 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.
  • @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.
  • olegoleg Member
    edited 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
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • olegoleg Member
    edited January 2020
    oleg said:


    You did not specify an initial size index

    image
    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
    777.PNG
    883 x 718 - 103K
    777.PNG 103.4K
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • 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.
  • @plicatibu Yes, i have the same mistake

    I think it's a bug gideros @hgy29
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • hgy29hgy29 Maintainer
    oleg said:

    @plicatibu Yes, i have the same mistake

    I think it's a bug gideros @hgy29

    Will look into it

    Likes: oleg

    +1 -1 (+1 / -0 )Share on Facebook
  • I have scaled the opposite, it works a little better

    @1=600*300
    @2=1200*600
    @4=2400*1200
    image
    1111.PNG
    951 x 800 - 120K
    1111.PNG 119.9K
    my games:
    https://play.google.com/store/apps/developer?id=razorback456
    мій блог по гідерос https://simartinfo.blogspot.com
    Слава Україні!
  • @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.

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    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.
    +1 -1 (+5 / -0 )Share on Facebook
  • SinisterSoftSinisterSoft Maintainer
    edited 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.

    Likes: oleg

    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
    +1 -1 (+1 / -0 )Share on Facebook
Sign In or Register to comment.