config-featIn this week’s tutorial, we revisit the “Ultimate config.lua” which introduced a more functional config.lua file — one that helped many developers convert their letterbox apps into full screen apps. This time around, we’ll aim to make it better.

1. Simplification

If you recall from the original file, each device “group” was separated into code blocks. For example, the Android block of the file targeted two different sized screens, those with an aspect ratio of less than 1.72 and those with greater. That meant on these devices, it still was not a precise fit. Rethinking the Android portion lead to this simplification:

With a simple calculation, we can determine the exact height of our content area based on a 320 pixel wide area.

A very helpful Corona developer “@aukStudios” has proposed a better way to handle the config.lua — instead of having all of those separate code blocks for different devices, why not just compute them all? The answer, after several revisions, is the following refactoring of the previous version.

All of the separate if statements for different devices have been eliminated down to this one simple block of code.

Let’s consider the logic. For base 320×480 devices, we set a width of 320 and a height of 480. For “tall” devices like the iPhone5 or most Android devices, we want to keep the content area at 320 wide but automatically calculate the height. Using 320 and 480 (1:1.5 ratio), if the aspect ratio is greater than 1.5, we can assume it’s a tall device and make the width 320. For the height, we calculate the height as 320 × the aspect ratio.

The iPhone5 is 640×1136, so we can do this math (height divided by width):

1.775 is greater than 1.5, so we calculate the height to be 320×1.775, or 568, the correct value.

The iPad, in contrast, is a “wide” device, so to keep things to scale, we want the 480 content height to span the height of the screen, with the letterbox regions on the left and right. Mathematically, it works out to 360 points wide:

1.333333 is less than 1.5, so we calculate the width (360) and for the height, we use the fixed value of 480. For simplification, we round off the calculations to whole numbers.

2. Moving Beyond 320×480

We’ve always suggested 320×480 as the “standard” content size, because in days past, that made sense for the original iPhone, iPhone3, and iPhone3GS screen sizes. When the iPhone4 was introduced, it was easy to just double that content size to that device’s 640×960 screen size (and it worked reasonably well on the iPad as well). However, when Apple released the Retina iPad, and other high-definition tablets and phones entered the market, we suddenly found the need to have three versions of all of our app graphics: a “legacy” set for the older devices, a “normal” set for the ~640 pixel wide devices, and an “HD” set for the newest devices.

Today, there are even more high resolution devices which we may want to support, like 1080p TVs and the latest class of tablets which are pushing the HD concept even higher. Fortunately, this means that there are fewer of the small screens to support.

In addition, the “one screen pixel = one content area pixel” concept, from the 320×480 iPhone days, doesn’t make sense anymore, considering the vast array of screen sizes on the market (Samsung alone produces almost 30 different screen sizes).

As a developer, now may be the time to reconsider the old standards and come up with something that makes “doing the math” a bit easier, and one with that represents modern devices. Some developers began doing this quite some time ago.

One suggestion for a convenient and modern content area would be 800×1200. This maintains the core 1:1.5 aspect ratio as 320×480, but it makes the numbers and screen positions conceptually easier to work with. The center point is (400,600) vs. (160,240), 80 pixels is 10% of the content width, etc.

As you probably know, Corona SDK will scale your content up or down as necessary. At the same time, it will dynamically and automatically select the proper resolution images if you set up dynamic image scaling properly.

Using this new content area size of 800×1200, we’ve dropped the “legacy” image set entirely, opting for two suffix schemes that cover the vast majority of modern devices. And thus, the “refactored” config.lua becomes:

In this example, devices with a screen width greater than 1040 pixels will use the larger “@2x” image set, while smaller devices will use the regular non-suffixed images.

In Summary

As you can see, a logical, easy-to-understand content area is essential to multi-resolution development, whether you’re working on a game or a utility app. Since devices will continue to diversify and expand to even higher resolutions, it may be time to adapt to a config.lua that works well with today’s devices while providing some “room to grow” as well.

Taken from: 

Tutorial: Modernizing the config.lua