About the display object behaviour in project

Solar2D Advanced Graphics
#1

I’m not sure if this is a bug of display.

Some screen settings in config.lua in certain devices will make the display object behave differently.

When I create the display rect with display.contentWidth and display.contentHeight, the rect may not be able to cover the full screen

config.lua

[lua]

local screenWidth = 640

local heightRatio = display.pixelHeight/display.pixelWidth

local screenHeight = screenWidth*heightRatio

application = 

{

    content = 

    {

        width = screenWidth,

        height = screenHeight,

        fps = 60,

        antialias = true,

        xAlign = “center”,

        yAlign = “center”,

    },

}

[/lua]

main.lua

[lua]

local bg = display.newRect(display.contentWidth * 0.5, display.contentHeight * 0.5, display.contentWidth * 2, display.contentHeight * 2)

local rect = display.newRect(0, 0, display.contentWidth, display.contentHeight)

rect.anchorX = 0

rect.anchorY = 0

rect:setFillColor(1, 0, 0)

[/lua]

When I set the screenWidth in config.lua to 320, 640 or 1080 and run the code in iPhone 6, a white line will present at the bottom of the screen.

Is there any suggestion to avoid this?

Thanks for the help

#2

Yes, do not use calculations in config.lua.  You will hit rounding issues on devices.

#3

https://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
This is the suggestion from Corona website, which suggested to use calculation.

And I have try the following height:

    1) math.floor

    2) math.ceil

    3) round the height (by using math.floor(height + 0.5))

    4) 1137 (numerically = math.floor)

    5) 1138 (numerically = math.ceil)

Some of the above setting works in iPhone 6, BUT will cause the display problem on iPhone 6 Plus

So I want to know if any suggestion to avoid this.

#4

That suggestion is 4 years old and NOT recommended as it causes scaling issues.

Just use a static canvas and store to variables that equate to your width and height.  Use those throughout your app to allow for various different screen sizes.

I use these (and these work on ALL devices)

--screen constants \_originX, \_originY = display.screenOriginX, display.screenOriginY \_W, \_H = display.contentWidth - (\_originX \* 2), display.contentHeight - (\_originY \* 2) \_centreX, \_centreY = \_originX +\_W/2, \_originY + \_H/2
#5

The modernizing method works for some apps, but it causes problems for others and we are no longer recommending it.

Instead, use a fixed content area and then use the constants display.screenOriginX, display.screenOriginY and display.actualContentWidth, display.actualContentHeight.

display.screenOriginX, Y represent the true left, top corners regardless of the aspect ratio of the device.  display.actualContentWidth, display.actualContentHeight the actual right, bottom of the display.  Depending on the aspect ratio and orientation of the device, display.screenOriginX or display.screenOriginY will likely have a negative number (while the other is 0). This represents the content area of the screen that’s outside the width/height box you defined in config.lua. If you’re centering your box, display.contentCenterX, display.contentCenterY will be the center of the screen.

This is easier to work with in the end for most games than the modernizing version. If you’re building a business app, in particular a portrait one, I would offer a different suggestion.

Rob

#6

Thanks for all replies.

Actually we are focusing on business app so we want to find a better solution.

We will check if Sphere Game Studios’s solution is suitable for use

#7

If you’re doing a business app, perhaps you should consider the “adaptive” scaling method instead of letterbox. You don’t provide any height or width. Corona will give you a width and height that varies by device.  An iPhone 4 and 5 will be 320 x appropriate length, the iPhone 6 will be 375x667, the plus models will be 414x736 and the iPads 768x1024.

That way you can build screens that work best for phones vs. tablets. A widget.newSwitch() will visually be the same size on all devices, but you get more real estate to work with.

If you don’t want to do adaptive but stay with letter box, assuming a portrait app, do this in your config.lua:

application = { content = { width = 640, height = 960, fps = 60, xAlign = "center", yAlign = "top", }, }

With this configuration 0 for .y will be the very top and display.actualContentHeight will be the bottom. Most business apps you fill content down from the top. Now the question is how you want iPad and other tablet behavior to occur. In this case I’m still centering the content area horizontally so 0 may not be the left edge and you would still need to use display.screenOriginX to find the left edge. You could xAlign to “left” to get 0 to be the left edge and use display.actualContentWidth to get the right edge. 

The problem here is that display.contentCenterX and display.contentCenterY will no longer be the center of the screen. They are the center of the content area. You would need to subtract display.screenOriginX and display.screenOriginY to get back to the true center of the display. But many business apps don’t care about the center of the screen too much.

Rob

#8

Rob & Sphere,

I am getting ready to release an app soon; and have a config.lua based on the modern-config-lua  mentioned in your responses above

local w, h = display.pixelWidth, display.pixelHeight local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.floor( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.floor( 800 \* aspectRatio ), scale = "zoomEven", --"letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, }, }

so, this will cause rounding errors?

Is this due to newer devices mostly?   I have had no issues on the Ipad2, iPhone 6S plus, using this config.lua. when testing my app.

Thanks for any insight possible.

Bob

#9

Hi Bob,

IMHO the “math in config.lua” approach was always problematic and I’ve discouraged doing so from the very beginning that it (oddly) gained popularity… especially when a static content size, choice of either “letterbox” or “zoomEven”, and the APIs which can be used to offset/align objects to screen edges accomplish 95% of any situation you’d ever need (“adaptive” filling out the remaining 5%, as it’s extremely useful in cases like biz/utility apps).

Take care,

Brent

#10

Bob, if you’re ready to release, your config.lua is working for you, I wouldn’t change it. You’re likely going to set your development quite a bit if you do. Now if you’re having problems that may be related to positioning things, then you might want to consider it. We don’t know what your game is and how this applies.

There won’t be rounding errors. Lua’s numbers are a double float so it will hold quite a bit of precision. If anything it would be too precise.

Where you might run into problems is I think the Samsung Galaxy S8 has an extreme aspect ratio. It’s 18.5:9 instead of most other phone’s 16:9.  If you’ve followed our recommendation to have a 570x360 shaped background which fills both 16:9 and the 4:3 iPad screens) (1425x900 in your case for an 800x1200 content area), then you won’t have enough background to fill the difference. Based on the 570x360 background, for the S8, you actually need a 658x360 background (1645x900 if my math is right for your 1200x800 content area).

Rob

#11

Brent & Rob,

Thanks to both of you for sharing your knowledge and experience!

I ‘might’ stick with the config as I have it for this app, and begin using the fixed settings as mentioned in your responses above, for my other apps.

Thanks

Bob

#12

Yes, do not use calculations in config.lua.  You will hit rounding issues on devices.

#13

https://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
This is the suggestion from Corona website, which suggested to use calculation.

And I have try the following height:

    1) math.floor

    2) math.ceil

    3) round the height (by using math.floor(height + 0.5))

    4) 1137 (numerically = math.floor)

    5) 1138 (numerically = math.ceil)

Some of the above setting works in iPhone 6, BUT will cause the display problem on iPhone 6 Plus

So I want to know if any suggestion to avoid this.

#14

That suggestion is 4 years old and NOT recommended as it causes scaling issues.

Just use a static canvas and store to variables that equate to your width and height.  Use those throughout your app to allow for various different screen sizes.

I use these (and these work on ALL devices)

--screen constants \_originX, \_originY = display.screenOriginX, display.screenOriginY \_W, \_H = display.contentWidth - (\_originX \* 2), display.contentHeight - (\_originY \* 2) \_centreX, \_centreY = \_originX +\_W/2, \_originY + \_H/2
#15

The modernizing method works for some apps, but it causes problems for others and we are no longer recommending it.

Instead, use a fixed content area and then use the constants display.screenOriginX, display.screenOriginY and display.actualContentWidth, display.actualContentHeight.

display.screenOriginX, Y represent the true left, top corners regardless of the aspect ratio of the device.  display.actualContentWidth, display.actualContentHeight the actual right, bottom of the display.  Depending on the aspect ratio and orientation of the device, display.screenOriginX or display.screenOriginY will likely have a negative number (while the other is 0). This represents the content area of the screen that’s outside the width/height box you defined in config.lua. If you’re centering your box, display.contentCenterX, display.contentCenterY will be the center of the screen.

This is easier to work with in the end for most games than the modernizing version. If you’re building a business app, in particular a portrait one, I would offer a different suggestion.

Rob

#16

Thanks for all replies.

Actually we are focusing on business app so we want to find a better solution.

We will check if Sphere Game Studios’s solution is suitable for use

#17

If you’re doing a business app, perhaps you should consider the “adaptive” scaling method instead of letterbox. You don’t provide any height or width. Corona will give you a width and height that varies by device.  An iPhone 4 and 5 will be 320 x appropriate length, the iPhone 6 will be 375x667, the plus models will be 414x736 and the iPads 768x1024.

That way you can build screens that work best for phones vs. tablets. A widget.newSwitch() will visually be the same size on all devices, but you get more real estate to work with.

If you don’t want to do adaptive but stay with letter box, assuming a portrait app, do this in your config.lua:

application = { content = { width = 640, height = 960, fps = 60, xAlign = "center", yAlign = "top", }, }

With this configuration 0 for .y will be the very top and display.actualContentHeight will be the bottom. Most business apps you fill content down from the top. Now the question is how you want iPad and other tablet behavior to occur. In this case I’m still centering the content area horizontally so 0 may not be the left edge and you would still need to use display.screenOriginX to find the left edge. You could xAlign to “left” to get 0 to be the left edge and use display.actualContentWidth to get the right edge. 

The problem here is that display.contentCenterX and display.contentCenterY will no longer be the center of the screen. They are the center of the content area. You would need to subtract display.screenOriginX and display.screenOriginY to get back to the true center of the display. But many business apps don’t care about the center of the screen too much.

Rob

#18

Rob & Sphere,

I am getting ready to release an app soon; and have a config.lua based on the modern-config-lua  mentioned in your responses above

local w, h = display.pixelWidth, display.pixelHeight local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.floor( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.floor( 800 \* aspectRatio ), scale = "zoomEven", --"letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, }, }

so, this will cause rounding errors?

Is this due to newer devices mostly?   I have had no issues on the Ipad2, iPhone 6S plus, using this config.lua. when testing my app.

Thanks for any insight possible.

Bob

#19

Hi Bob,

IMHO the “math in config.lua” approach was always problematic and I’ve discouraged doing so from the very beginning that it (oddly) gained popularity… especially when a static content size, choice of either “letterbox” or “zoomEven”, and the APIs which can be used to offset/align objects to screen edges accomplish 95% of any situation you’d ever need (“adaptive” filling out the remaining 5%, as it’s extremely useful in cases like biz/utility apps).

Take care,

Brent

#20

Bob, if you’re ready to release, your config.lua is working for you, I wouldn’t change it. You’re likely going to set your development quite a bit if you do. Now if you’re having problems that may be related to positioning things, then you might want to consider it. We don’t know what your game is and how this applies.

There won’t be rounding errors. Lua’s numbers are a double float so it will hold quite a bit of precision. If anything it would be too precise.

Where you might run into problems is I think the Samsung Galaxy S8 has an extreme aspect ratio. It’s 18.5:9 instead of most other phone’s 16:9.  If you’ve followed our recommendation to have a 570x360 shaped background which fills both 16:9 and the 4:3 iPad screens) (1425x900 in your case for an 800x1200 content area), then you won’t have enough background to fill the difference. Based on the 570x360 background, for the S8, you actually need a 658x360 background (1645x900 if my math is right for your 1200x800 content area).

Rob