Hi, I am newbie in Corona SDK app development. As of now I am developing business app using Corona SDK only for Android devices. My problem is, I am not able to set background Image for my app. Background image is going out of the android device display area. I am attaching my project . Please help me…
Hi @adity3
Your background is bigger than your content area. Your config.lua is giving you a 320 x 480 area to work with. Your background is 380 x 570, which is 60 pixels wider and 90 pixels higher than your screen area. The background is going to “bleed” off the screen. Now if your config.lua supported other screen sizes like an iPad, which at this scale would be a 360x480 device you would get more of the image width wise since it would use 360px of the image’s width. If you changed to something like a Samsung S3 for Android, that screen at this scale would be more like 320 x 570 and you would get the full height of the image but still loose 60px of the width.
If you’ve read suggestions about making the background 360x570 (not much reason to make it 380, since the iPad is the widest device and only needs 360), this only works if background elements can bleed off the screen without hurting the UI. There are too many different screen shapes to possibly build a background like this that will work on all of them. You would have to have dozens of background images and try to pick the right one.
What I would do in your case, if the white area on the right, the teal box and the logo are important to you to be on screen all the time, is to make them separate elements and load them in and position them based on your screen shape and just have a solid blue-gray background.
It might be helpful to read a couple of blog posts to help you understand the problem better and offer some solutions on how to solve this for different screen shapes:
Read this one first: http://www.coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/
as it has important concepts for how this all works. Then read the follow up to it, where we improve things:
http://www.coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
Its important to point out that in the 2nd blog post, “Step 2” is a great concept and should make people’s lives a little easier, however it’s not advice everyone should follow. If you plan to use some widgets like the pickerView or ads, moving from a base 320x480 content area will create some additional work for you. Step 2 should be considered optional if you can move away from the smaller screen area.
You need to use
display.newImageRect("bg.png", display.contentWidth, display.contentHeight)
instead of
display.newImage("bg.png", true)
when using dynamic scaling.
It says so in the docs for display.newImage() http://docs.coronalabs.com/api/library/display/newImage.html
The width, height values can be adjusted to whatever size you need. I find that I very rarely need to use newImage() rather than newImageRect. Can anyone point out any advantages to it?
@Rob Miracle, we used the example from http://www.coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/ the other day when trying out something in graphics 2.0
It completely messed the app up. If we reverted config.lua back to using fixed width and height it worked. No idea what was happening when using the aspect ratio method, but every time you refreshed the simulator the app looked different, even for a very simple scene with just one (medium sized) image.
I presume it’s due to some bugs that need working out in graphics 2.0, but thought I’d mention it in case the config.lua example will need updating again soon.
I’ll see if I can get the latest G2.0 DP and test it. The only reason it wouldn’t work is if display.pixelHeight and display.pixelWidth are not returning the expected values. Can you do a print and see if they are what you are expecting?
Thanks
Rob
For now, use a fixed value for your content area values while I investigate this.
Thanks Rob… I got the basic concepts of Dynamic Scaling. But I have to do more practice on it. Once again thanks a lot for you help.
I want to know one thing more is that Corona Enterprise is currently available only on Mac.
For Window it is available or not?
Thanks
display.pixelWidth and display.pixelHeight are both showing the correct values, however display.contentWidth and display.contentHeight are different every time the simulator restarts.
I’ve just built a test with these 2 files, so you can see that display.contentWidth and display.contentHeight are different each time. I should point out that this was using graphics 2.0 build 107, so maybe it’s been fixed in the last few days.
config.lua
local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.ceil( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.ceil( 800 \* aspectRatio ), scale = "letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, }, }
main.lua
print(display.pixelWidth, display.pixelHeight) print(display.contentWidth, display.contentHeight)Config.lua gets processed before main.lua. Printing the values out in main.lua doesn’t really demonstrate the problem. This should be fixed in an upcoming 2.0 build.
I was under the impression that config.lua is where main.lua gets the display.contentWidth, display.contentHeight values from to begin with?
Either way, hopefully this has helped someone somewhere fix a bug 
It does. display.contentWidth and display.contentHeight are populated from the width/height values in the content table in config.lua. The issue is with display.pixelHeight and display.pixelWidth. In the main trunk, these two values are picked up before config.lua is processed. In the current G2.0 build, they are populated after config.lua is processed, so we can’t calculate the aspect ratio off of those values. This should be addressed in the next build as .pixelHeight and .pixelWidth will be set prior to config.lua’s processing.
Ok I get it now, that also explains why .pixelHeight and .pixelWidth appeared to be correct when I printed them.
Hi @adity3
Your background is bigger than your content area. Your config.lua is giving you a 320 x 480 area to work with. Your background is 380 x 570, which is 60 pixels wider and 90 pixels higher than your screen area. The background is going to “bleed” off the screen. Now if your config.lua supported other screen sizes like an iPad, which at this scale would be a 360x480 device you would get more of the image width wise since it would use 360px of the image’s width. If you changed to something like a Samsung S3 for Android, that screen at this scale would be more like 320 x 570 and you would get the full height of the image but still loose 60px of the width.
If you’ve read suggestions about making the background 360x570 (not much reason to make it 380, since the iPad is the widest device and only needs 360), this only works if background elements can bleed off the screen without hurting the UI. There are too many different screen shapes to possibly build a background like this that will work on all of them. You would have to have dozens of background images and try to pick the right one.
What I would do in your case, if the white area on the right, the teal box and the logo are important to you to be on screen all the time, is to make them separate elements and load them in and position them based on your screen shape and just have a solid blue-gray background.
It might be helpful to read a couple of blog posts to help you understand the problem better and offer some solutions on how to solve this for different screen shapes:
Read this one first: http://www.coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/
as it has important concepts for how this all works. Then read the follow up to it, where we improve things:
http://www.coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
Its important to point out that in the 2nd blog post, “Step 2” is a great concept and should make people’s lives a little easier, however it’s not advice everyone should follow. If you plan to use some widgets like the pickerView or ads, moving from a base 320x480 content area will create some additional work for you. Step 2 should be considered optional if you can move away from the smaller screen area.
You need to use
display.newImageRect("bg.png", display.contentWidth, display.contentHeight)
instead of
display.newImage("bg.png", true)
when using dynamic scaling.
It says so in the docs for display.newImage() http://docs.coronalabs.com/api/library/display/newImage.html
The width, height values can be adjusted to whatever size you need. I find that I very rarely need to use newImage() rather than newImageRect. Can anyone point out any advantages to it?
@Rob Miracle, we used the example from http://www.coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/ the other day when trying out something in graphics 2.0
It completely messed the app up. If we reverted config.lua back to using fixed width and height it worked. No idea what was happening when using the aspect ratio method, but every time you refreshed the simulator the app looked different, even for a very simple scene with just one (medium sized) image.
I presume it’s due to some bugs that need working out in graphics 2.0, but thought I’d mention it in case the config.lua example will need updating again soon.
I’ll see if I can get the latest G2.0 DP and test it. The only reason it wouldn’t work is if display.pixelHeight and display.pixelWidth are not returning the expected values. Can you do a print and see if they are what you are expecting?
Thanks
Rob
For now, use a fixed value for your content area values while I investigate this.
Thanks Rob… I got the basic concepts of Dynamic Scaling. But I have to do more practice on it. Once again thanks a lot for you help.
I want to know one thing more is that Corona Enterprise is currently available only on Mac.
For Window it is available or not?
Thanks
display.pixelWidth and display.pixelHeight are both showing the correct values, however display.contentWidth and display.contentHeight are different every time the simulator restarts.
I’ve just built a test with these 2 files, so you can see that display.contentWidth and display.contentHeight are different each time. I should point out that this was using graphics 2.0 build 107, so maybe it’s been fixed in the last few days.
config.lua
local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.ceil( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.ceil( 800 \* aspectRatio ), scale = "letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, }, }
main.lua
print(display.pixelWidth, display.pixelHeight) print(display.contentWidth, display.contentHeight)Config.lua gets processed before main.lua. Printing the values out in main.lua doesn’t really demonstrate the problem. This should be fixed in an upcoming 2.0 build.