I’ve read Rob’s article about new config.lua
There he presents version for 320x480 and 800x1200. However when I use second one, everything seems not fitting. I have checked size and on Galaxy SIII which have 1280x720, I got 1423x800 when printed application.content.width and application.content.height. Why there is the difference?
Any suggestions?
Hi @piotrz55,
How are you printing “application.content.height”? This does not appear to be a valid API call. Also, did you change the scale setting to something other than “letterbox” as shown in the tutorial? Can you please show some code, esp. your config.lua file?
Thanks,
Brent
Keep in mind, the config.lua is presented in “Portrait” mode. The SIII is a 720x1280 screen so 1280/720 = 1.7777778 * 800pt wide content area = 1422 display.contentHeight (guess it could round up to 1423) So the numbers are right.
Remember the content area does not have to map 1 to 1 with the screen. That’s why we are suggesting 800x1200 so that people stop thinking in screen pixels. Think of your app in screen space and let Corona figure it out. Since the SIII is a “tall” device (greater than the 1:1.5 ratio that we use for the content area) the config.lua will calculate the height based on the width of 800. For your device that becomes 1423. If you try to run the same app on an iPad it would give you a 1067*1200 content area to work with. That way all your graphics basically are scaled the same, but you just have different real-estate depending on the screen you have.
Mu config.lua
[lua]
– config.lua
–calculate the aspect ratio of the device
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,
},
},
}
print(aspectRatio, application.content.width, application.content.height )
[/lua]
I get the point you are talking about, but if I have background image which has 800x1280 then I have black bars at top and bottom with display.newImageRect(“background.png”, 800, 1280)
If you are not planning on supporting the iPad, your background should be 800x1423 and that’s the values you shoul dbe passing to display.newImageRect(). If you plan on supporting the iPad, the background should be 1067x1423 and loaded in with those values. The extra area is going to bleed off the screen, so you shouldn’t put critical features in there. If you need backgrounds to fit more precisely because of critical background elements, then you could put logic in your code that determines if you need an iPad 1.25:1 friendly background, or a HD 16:9 friendly background or whatever device you want and then load in the precise file.
Ok, I think I get it. However, is there possibility you could elaborate shortly why doesn’t content map 1:1 with screen (physical pixels)? Is this ‘excess’ area hidden under display.screenOriginY (1280 + 2×origin)?
Why not map the content area 1:1 with a screen’s physical pixels? Well the question is “What screen do I use?” Do I use a 640x960 iPhone 4/4s? Do I use a 600x1024 Kindle Fire/Nook? Or a Nexus 7’s 800x1280? A Ouya’s 720x1280?
No matter which screen you pick there’s going to be more screens that are not that size. You have to think in screen dimensions. While you might be comfortable with the screen size of your device, your potential customers screens are going to be all over the place. Let’s base our numbers on something easy to work with. Perhaps 1000 x 1500 may have been a better choice (and you are free to use that if you want) or 600 x 900 or whatever values. Even the 1.5:1 ratio is at this point arbitrary since it’s really based on the 320x480 shape screens which only a few devices have. But it’s between wider devices like the iPads and the HDTV shaped 16:9 screens and keeps the math easy.
So image(s) of what size should I use to fill whole screen on ‘all’ devices? 800x1280 gave me black bars at the top and at the bottom (like letterbox in portrait mode)
I understand that Corona will handle smaller resolutions and scale it accordingly, am I right? 
Yes… meaning, do you want to target something like the iPhone3GS, or an older/smaller Android device around that size? If so, you can build in an additional suffix for lower resolutions, and specify the suffix name how you wish.
I would say that my target is to support as many devices as possible. You know, there are always some “no-name” products with lower resolutions on which apps, for example ‘bussiness’ apps, should look ‘quite’ good. I know there is no ultimate one solution but covering as wide range as possible is really helpful.
In that case, you may wish to add another suffix and calculate the “range” that it should cover. Maybe name it “-legacy” or something: “myImage-legacy.png”, “background-legacy.png”, etc.
@piotrz55, I think most people would rationally want to support the widest range of devices possible, but there comes a time when you have to cut the cord on older technology to move forward. For example in the web development world, many people felt they had to support IE 6 (there are some holdouts today…) but after a few brave folks decided to drop support, more and more followed suit when the found that it really didn’t impact them and by loosing support for something old, they were able to move their website’s forward… a lot… Today even IE7 is rarely supported and many shops are dropping support for IE8. It seems when you get to the 1%-5% market, it’s time to sever the old technology.
If you think about it in terms purely of content area and you want to hold on to the 320x480 grid, that means that on a retina iPhone when you move something by one point you’re actually moving it 2 pixels. In otherwords with a content area of 320x480 and player.x = 10, it’s really 20 pixels to the right of the left edge. When you do player.x = player.x + 1, Corona has to compute that and make it a 2 pixel move. Now scale this to a retina iPad. It becomes x = x + 4. That player.x = 10 is really at pixel 40. That 60 fps smooth animation you want is held back because everything moves by 4 pixels at a time on retina iPads and other HD devices.
But the beauty of this is it’s your choice. You can stick with 320x480 and 3 different sized graphics if you want. It’s not wrong by any stretch of the imagination.
Dear Corona Labs,
can you tell me, if content area do not map 1:1 to physical pixels then what to do with vector objects?!.
If I draw newLine, then if Corona will determine that scaling < 1 then line do not appear on screen at all (if width is 1) or is thinier!!!
Hi @piotrz55,
Yes, this would probably occur if you use a config like 800x1200 and then run on a device like iPhone3GS and try to display a newLine that’s 1 pixel thick. I guess the “workaround” would be to display a line 2 or more pixels thick. 
Or, use the low-to-high method, if that’s preferable to you (smaller content area, and let Corona work up).
Best regards,
Brent
Or, use the low-to-high method, if that’s preferable to you (smaller content area, and let Corona work up)
How to set it up?
Yes, this would probably occur if you use a config like 800x1200 and then run on a device like iPhone3GS and try to display a newLine that’s 1 pixel thick.
Not only devices but simulator too
I guess the “workaround” would be to display a line 2 or more pixels thick.
It won’t help. I wanted to display grid. I made both vertiacal and horizontal ones 3px width. Effect is one are thicker other one thiner.
If there is no other way then for vectors this config is bad way unfortunately 