Asset dimensions problem

[Abdo23]

I’m making a game based on the iPhoneX resolution. I created a shape that I need to fit 8 copies of it on the screen. I did this calculation in order to get the right width of the shape:

2436(iPhoneX landscape width) / 8 = 305

So, I made the width of my shape 305. And after putting it on the screen it looked like this:

I positioned it like this:

object.x = object.width

In my vector drawing app ( Affinity Designer ) it looks like this with the exact same dimensions:

Clearly, the image looks much bigger on the simulator screen and it won’t fit 8 of them together. I’m also 100% sure that I use pixel units in Affinity Designer. What is the problem here?

[schizoid2k]

Have a look at this page.

Check out the width, height, and scale parameters of your config.lua.

[nick_sherman]

In Corona you don’t place objects based on the pixel dimensions of the screen, you place them based on the ‘content area’ as defined in config.lua.

display.actualContentWidth and display.actualContentHeight give you the number of ‘units’ visible on screen based on the config.lua setting, and any extra space resulting from wide phones or tall tablets. You would then divide the actualContentWidth by 8 to give you the required width to put into display.newImageRect to fit exactly 8 across the screen.

This also means you don’t need to worry about exporting the exact right size from affinity designer, you just specify in display.newImageRect what size you’d like it to be.

[Abdo23]

@nick\_sherman

In Corona you don’t place objects based on the pixel dimensions of the screen, you place them based on the ‘content area’ as defined in config.lua.

display.actualContentWidth and display.actualContentHeight give you the number of ‘units’ visible on screen based on the config.lua setting, and any extra space resulting from wide phones or tall tablets. You would then divide the actualContentWidth by 8 to give you the required width to put into display.newImageRect to fit exactly 8 across the screen.

This also means you don’t need to worry about exporting the exact right size from affinity designer, you just specify in display.newImageRect what size you’d like it to be.

Ok, the content area in my app is the default 320x480. The display.actualContentSize = 692.90 

692 /8 = 86.5

object.x = object.width * i

Here is how it looks like:

[roaminggamer]

1. I don’t know why people still use 320x480.  It has many issues, not the least of which is rounding problems.  Better to go with 640x960

(The only thing this resolution has going for it is that ‘in the head’ calculations are easy if you are making a grid based game and use a grid size of 40 or 32, leading to grids of 8x12 or 10x15 respectively.)

2a. Your horizontal content space (480) will NOT fill the screen in letterbox mode and landscape orientation.  There will be gaps on the left and right.

2b. The vertical content space (320), will be perfectly edge-to-edge fitting.

3. If we ignore the stupid notch (I hate that thing).  The right way to create 8 shapes that will fill the width of the screen is:

   – original width and height of your art, whatever you made it. local origWidth = 300 local origHeight = 40 – calculate exact width for 8 blocks to fill screen local targetWidth = display.actualContentWidth/8 – Calculate new height as ratio of original width and new width multiplied by old height – We do this to maintain the original aspect ratio of the art. local targetHeight = (targetWidth/origWidth) * origHeight – calculate left edge of screen local curX = display.contentCenterX - display.actualContentWidth/2 – choose y position local curY = display.contentCenterY – place 8 blocks left to right, aligned to their left edges. for i = 1, 8 do local tmp = display.newImageRect( “img path”, targetWidth, targetHeight ) tmp.anchorX = 0 tmp.x = curX tmp.y = curY curX = curX + targetWidth end

This may still have gaps because you’re using a tiny content resolution.  Try it and find out.

[nick_sherman]

@roaminggamer

3. If we ignore the stupid notch (I hate that thing). 

What on earth were they thinking?

[Abdo23]

@roaminggamer

-- original width and height of your art, whatever you made it. local origWidth = 300 local origHeight = 40 -- calculate exact width for 8 blocks to fill screen local targetWidth = display.actualContentWidth/8 -- Calculate new height as ratio of original width and new width multiplied by old height -- We do this to maintain the original aspect ratio of the art. local targetHeight = (targetWidth/origWidth) \* origHeight -- calculate left edge of screen local curX = display.contentCenterX - display.actualContentWidth/2 -- choose y position local curY = display.contentCenterY -- place 8 blocks left to right, aligned to their left edges. for i = 1, 8 do local tmp = display.newImageRect( "img path", targetWidth, targetHeight ) tmp.anchorX = 0 tmp.x = curX tmp.y = curY curX = curX + targetWidth end

This may still have gaps because you’re using a tiny content resolution.  Try it and find out.

I tried this and here is the result:

Now I wanted to add the safe area to the calculation so that the object starts where the notch ends, so I made this change:

local curX = display.contentCenterX - display.safeActualContentWidth/2 \<- safe

And here is the result:

It seems like it didn’t take the notch into account, so I did this:

local curX = display.contentCenterX - display.actualContentWidth/2 + (173/2) --added half the size of the object

[rob]

Why continue to use 320x480?

1. Apple still does. It’s their point system.

2. Google is DPI based, and a core 2" screen is 160 dpi * 2" = 320. Of course higher resolution screens means a higher dpi, but like Apple, 320 point screens are waning, but it’s still a good scale to work with.

3. Corona Widgets are designed for a 320x480 content area.

Rob

[roaminggamer]

@Abdo23

• Didn’t see a question in that last post. 
• Suggestion: Can I suggest you use the borderless view (1125x2436)?
  • I never use the framed views and I think at one time the iPhone X view had an issue.  It is probably fine, but may be worth trying to be sure.
  • View -> Borderless -> iPhone @3x 1125x2436

@Rob -

1. What!?  Feels so archaic.  I must just be biased.

2. Noted.

3. Yes!  I keep forgetting, widget.* is somewhat dependent on 320x480 as a basis.  (I use SSK2 easyIFC so I often forget about widget.* details, except when I find myself needing a slider which SSK no longer supports.)

[roaminggamer]

@Abdo23

The algorithm I wrote above works perfectly and as expected.  I can only guess you’re doing something differently from me.

Did you make a tiny standalone project to explore this or are you doing this in your game? 

Advice: Never debug ideas in an existing project.

Here is a stand-alone example showing it working:

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/05/fitAnyDevice.zip

I have a handy stand-alone project just for this kind of debugging:

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/askEdStarter.zip

[rob]

This might help with the Apple stuff a bit:

https://www.paintcodeapp.com/news/iphone-6-screens-demystified

https://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions

But all that said, your content area is your content area. If you want a 1x1 go for it. If using a 16:9 content area works better than a 3:2, go for it. Maybe it makes sense for you to do 1080x1920 and really modernize your settings. That’s cool too.

Just understand that Apple seems to be stuck in this 320 point world and the impact it has on widget.* (and really only just a few are not scalable).

Rob

[roaminggamer]

This example accounts for the notch and treats the screen as if it ends at the notch edge:

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/05/fitAnyDevice_removeNotch.zip

Note: When you run this, there will be a gap between the black art of the notch and the first blue block. 

Why?  Probably because the simulator is approximating the frame.  You need to run this on a PHYSICAL device to test it.

Note 2 : All this nonsense is why I HATE notches (not just Apple is guilty of this).

(Personally I would ignore the notch, or define a broad fixed-size safe-area.  Relying on your ability to cope with every possibility of insets will be a challenging task.)

[Abdo23]

@roaminggamer

This example accounts for the notch and treats the screen as if it ends at the notch edge:

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2018/05/fitAnyDevice_removeNotch.zip

Note: When you run this, there will be a gap between the black art of the notch and the first blue block. 

Why?  Probably because the simulator is approximating the frame.  You need to run this on a PHYSICAL device to test it.

Note 2 : All this nonsense is why I HATE notches (not just Apple is guilty of this).

(Personally I would ignore the notch, or define a broad fixed-size safe-area.  Relying on your ability to cope with every possibility of insets will be a challenging task.)

Taking what Rob said into account I think I will stick with 320x480. Anyways, everything is working fine now.

Thanks a lot. Appreciate all your effort

[schizoid2k]

Have a look at this page.

Check out the width, height, and scale parameters of your config.lua.

[nick_sherman]

In Corona you don’t place objects based on the pixel dimensions of the screen, you place them based on the ‘content area’ as defined in config.lua.

display.actualContentWidth and display.actualContentHeight give you the number of ‘units’ visible on screen based on the config.lua setting, and any extra space resulting from wide phones or tall tablets. You would then divide the actualContentWidth by 8 to give you the required width to put into display.newImageRect to fit exactly 8 across the screen.

This also means you don’t need to worry about exporting the exact right size from affinity designer, you just specify in display.newImageRect what size you’d like it to be.

[Abdo23]

@nick\_sherman

In Corona you don’t place objects based on the pixel dimensions of the screen, you place them based on the ‘content area’ as defined in config.lua.

display.actualContentWidth and display.actualContentHeight give you the number of ‘units’ visible on screen based on the config.lua setting, and any extra space resulting from wide phones or tall tablets. You would then divide the actualContentWidth by 8 to give you the required width to put into display.newImageRect to fit exactly 8 across the screen.

This also means you don’t need to worry about exporting the exact right size from affinity designer, you just specify in display.newImageRect what size you’d like it to be.

Ok, the content area in my app is the default 320x480. The display.actualContentSize = 692.90 

692 /8 = 86.5

object.x = object.width * i

Here is how it looks like:

[roaminggamer]

1. I don’t know why people still use 320x480.  It has many issues, not the least of which is rounding problems.  Better to go with 640x960

(The only thing this resolution has going for it is that ‘in the head’ calculations are easy if you are making a grid based game and use a grid size of 40 or 32, leading to grids of 8x12 or 10x15 respectively.)

2a. Your horizontal content space (480) will NOT fill the screen in letterbox mode and landscape orientation.  There will be gaps on the left and right.

2b. The vertical content space (320), will be perfectly edge-to-edge fitting.

3. If we ignore the stupid notch (I hate that thing).  The right way to create 8 shapes that will fill the width of the screen is:

   – original width and height of your art, whatever you made it. local origWidth = 300 local origHeight = 40 – calculate exact width for 8 blocks to fill screen local targetWidth = display.actualContentWidth/8 – Calculate new height as ratio of original width and new width multiplied by old height – We do this to maintain the original aspect ratio of the art. local targetHeight = (targetWidth/origWidth) * origHeight – calculate left edge of screen local curX = display.contentCenterX - display.actualContentWidth/2 – choose y position local curY = display.contentCenterY – place 8 blocks left to right, aligned to their left edges. for i = 1, 8 do local tmp = display.newImageRect( “img path”, targetWidth, targetHeight ) tmp.anchorX = 0 tmp.x = curX tmp.y = curY curX = curX + targetWidth end

This may still have gaps because you’re using a tiny content resolution.  Try it and find out.

[nick_sherman]

@roaminggamer

3. If we ignore the stupid notch (I hate that thing). 

What on earth were they thinking?

[Abdo23]

@roaminggamer

-- original width and height of your art, whatever you made it. local origWidth = 300 local origHeight = 40 -- calculate exact width for 8 blocks to fill screen local targetWidth = display.actualContentWidth/8 -- Calculate new height as ratio of original width and new width multiplied by old height -- We do this to maintain the original aspect ratio of the art. local targetHeight = (targetWidth/origWidth) \* origHeight -- calculate left edge of screen local curX = display.contentCenterX - display.actualContentWidth/2 -- choose y position local curY = display.contentCenterY -- place 8 blocks left to right, aligned to their left edges. for i = 1, 8 do local tmp = display.newImageRect( "img path", targetWidth, targetHeight ) tmp.anchorX = 0 tmp.x = curX tmp.y = curY curX = curX + targetWidth end

This may still have gaps because you’re using a tiny content resolution.  Try it and find out.

I tried this and here is the result:

Now I wanted to add the safe area to the calculation so that the object starts where the notch ends, so I made this change:

local curX = display.contentCenterX - display.safeActualContentWidth/2 \<- safe

And here is the result:

It seems like it didn’t take the notch into account, so I did this:

local curX = display.contentCenterX - display.actualContentWidth/2 + (173/2) --added half the size of the object

[rob]

Why continue to use 320x480?

1. Apple still does. It’s their point system.

2. Google is DPI based, and a core 2" screen is 160 dpi * 2" = 320. Of course higher resolution screens means a higher dpi, but like Apple, 320 point screens are waning, but it’s still a good scale to work with.

3. Corona Widgets are designed for a 320x480 content area.

Rob