A Perfect Config.lua file?

Getting Started Newbie Questions
#1

So far, the coding for my game is going alright. However, my greatest concern is keeping objects in their proper places for different devices. I understand they have different screen widths, aspect ratios, etc, and I want to know how I can set up my game to appear as best as possible for each device. All of my objects are placed using a set of calculated globals from roaminggamer’s SSK2, with a few examples being:

local floor = display.newRect(centerX, bottom, fullw, fullh / 1.75) floor.fill = \_BRIGHTORANGE\_ local enemyBase = display.newRect(left + fullw / 15, bottom - fullw / 4, 40, 75) enemyBase.fill = \_RED\_ local playerBase = display.newRect(right - fullw / 15, bottom - fullw / 4, 40, 75) playerBase.fill = \_GREEN\_ local spawnBox = display.newRect(centerX, bottom, fullw / 2, 40) spawnBox.fill = \_WHITE\_ spawnBox.anchorY = 1

But after trying the game out on different devices, I became frustrated over the change in appearance over each device. I believe the answer lies in the config.lua file. How can I build a config.lua file that suits my needs? (Note: My config.lua is the default)

Also, here are two pictures: the one with the floating green and red rectangle for the iPhone 5 (the mispositioned one), and the right one for iPad Air (the one that works in this case).

I would refer to the Ultimate Config.Lua File tutorial, but I get a 404 error when I visit the page. In fact, a lot of old, yet valuable tutorials on Corona’s blog give me a 404 error.

#2

Ironically we just had a discussion on this topic.

The thread is here

#3

Hi @sdktester15,

You mean this one? I’ve stated elsewhere that I, personally, heavily discourage this practice. I firmly believe it causes more confusion than clarity… the biggest reason is not so much in the “theory” behind it, but that people use it without any real comprehension of what’s going on and how to use it properly, so it’s like somebody trying to fire a heavy automatic gun without any knowledge of how guns work. However, that’s my opinion and you can continue trying to use it if you’d like.

As for other tutorials now gone, we occasionally take some down when they are definitively outdated, offer bad advice (today versus when they were written years ago), or when they have been replaced by a more modern guide. If you can cite some of the topics which you want to explore, perhaps I can help guide you to more modern resources.

Take care,

Brent

#4

Hmmm… I read the thread @graham07, and I saw the advice that @Brent Sorrentino gave. (Or at least how he codes) 

Its just the problem comes to having these formulas for positioning them correctly on some devices, while positioning them incorrectly on others.

top + fullh / 10 96 + fifth \* j

Should I return to using pixels instead of fractions of screen height and width?

Also, even if I did return to using pixels, it would still be mispositioned because I have content near the corners of the device.

#5

Hi @sdktester15,

Yes, if you take anything like a “full width”, meaning the edge-to-edge pixel distance on all devices, that will vary because some devices are wider than others. So then doing division on that will make your objects position incorrectly. That’s why I choose to work in a predictable “letterbox” content area, and then push things like UI elements toward the edges of the screen (as I outlined in another post).

Another option, which some prefer, is to use “zoomEven” scale mode. Have you used that before and do you understand how it works?

Take care,

Brent

#6

First of all, what do you mean by push things toward the edges of the screen? I assume this is to fill the black bars sometimes left behind by letterBox’s scaling.

Second of all, I have not used zoomEven. But it seems to fill the width, but cause content to bleed off of the top and bottom.  

I can see the advantages of letterBox in some cases. So, I guess I would use pixels to move them. But at the same time I had some problems with pixels.

Uuhhh… this is so frustrating.  <_<

Hmm… I guess a solution could be to position objects based on the position of other objects.

object1.x, object1.y = 100, 150 object2.x, object2.y = object1.x, 250

Do you think this would be a good practice?

#7

I think you may be making it more complicated than it needs to be. :slight_smile:

Generally, if you want to work in a more predictable content area, it’s based on two choices:

  1. Use “letterbox” and then “fill” the letterbox bars (if any) with content, or push objects like UI toward the actual screen edges using the tips I mentioned in the other post.

  2. Use “zoomEven” and know that your screen will be entirely filled BUT you will have some content bleed off the edge when the aspect ratio differs.

Using #1, you can also push game objects (not just UI) toward edges. And yes, you could use a “relational” thing too, positioning objects relative to some parent object so that they all stay aligned.

Brent

#8

I guess I will stick with letterBox, I have never had any problems with it. Also, I think the relational positioning would work since none of the sizes of anything in my game will change depending on the device with the exception of backgrounds.

#9

In most games, there are game objects where the distance between them is important, then there are objects that can move based on the shape of the screen these are typically buttons, joystick controls, scores, life bars, basic UI bits… Then there is the background which needs to be designed to fill the screen regardless of the device.

If your game objects need to be the same distance apart, you cannot use a dynamic config.lua but if you’re building a card game where the various stacks of cards can spread out or move closer together  based on real estate a dynamic config.lua can help you. This needs to be the very first decision you make when deciding what to do. You of course, can make either one work, but you’re likely going to need  to do more work to make a card game where it’s okay to spread the cards out with a fixed config.lua and it’s a pain in the rear to make a angry birds type game function with a dynamic config.lua.

Next, your non-game objects, i.e. your UI bits usually need to be positioned near edges of the screen. The dynamic config.lua guarantees that 0, 0 will be the top, left corner and that display.contentHeight, display.contentWidth is guaranteed to be the bottom, right corner. Lets day you have a fire button you want 50 px away from the bottom, right. You simply position it at:  display.contentWidth - 50, display.contentHeight - 50. Want the life bar 50 px from the top, left, simply set them to 50, 50. Done. With a fixed config.lua, you have to use display.screenOriginX, display.screenOriginY and add those values to any object that needs to be near the edge of a screen and use display.actualContentWidth and display.actualContentHeight to get to the right and bottom of the screen. (you still need to add the screenOrigin* values to your right and bottom positioned items). Normally you want these items to move based on the shape of the screen.

Finally the background should be large enough to cover the full width of a 16:9 device understanding that on a tablet, part of the wide-side will be off screen. We call this “bleed” in developer terms. On the other size, the background has to be large enough to cover the full height of a tablet, understanding that some of the screen will be off screen when on a 16:9 phone.  How do you accomplish this? If you’re using a recommended 1.5x to 1 (3:2 aspect ratio) content area, i.e. 320 x 480, 800x1200, etc. then you want to use a background such as 570x360 (landscape or 360x570 portrait).  On a 16:9 your screen will be 320x568 to 570 depending on rounding. So by having the long side 570 on a 480 content area, your background should not black-bar in that direction. If you jump on an iPad then the virtual screen size will be 360x480. So those extra pixels on the short side will fill the iPad, preventing black bars, but 90 pixels (45 on each side, 44 with an iPhone 5), will be off screen. Simply don’t put anything on the background image in these bleed areas and you will never see black bars regardless of what config.lua you use.  This is all about making your background big enough to fill the black areas.  If you use an 800x1200 content area, the backgrounds should be 900x1425.

So to sum up, there is no perfect config.lua file. You just have to understand the limits of what you choose to do and understand out different aspect ratios fit on a canvas.

So to get to your question, if objects need to be a fixed distance from each other, you can easily use object2.x = object1.x + someDistance.

I like doing:   object2.x = object1.x +  0.5 * object1.width + somePaddingAmount.

Rob

#10

Wow, this summed up everything in a neat little bow. Also, it won’t be a card game, but rather a base defense game. I understand you used the cards as the example. But thank you for the valuable info, especially over background size. Turns out positioning objects in accordance to different objects is working perfectly. I checked in Nokia, iPad, iPhone, Android, Kindle, and HTC, and the text objects are in relatively the same place.

I guess you use this formula to account for the default 0.5 anchor.

#11

Ironically we just had a discussion on this topic.

The thread is here

#12

Hi @sdktester15,

You mean this one? I’ve stated elsewhere that I, personally, heavily discourage this practice. I firmly believe it causes more confusion than clarity… the biggest reason is not so much in the “theory” behind it, but that people use it without any real comprehension of what’s going on and how to use it properly, so it’s like somebody trying to fire a heavy automatic gun without any knowledge of how guns work. However, that’s my opinion and you can continue trying to use it if you’d like.

As for other tutorials now gone, we occasionally take some down when they are definitively outdated, offer bad advice (today versus when they were written years ago), or when they have been replaced by a more modern guide. If you can cite some of the topics which you want to explore, perhaps I can help guide you to more modern resources.

Take care,

Brent

#13

Hmmm… I read the thread @graham07, and I saw the advice that @Brent Sorrentino gave. (Or at least how he codes) 

Its just the problem comes to having these formulas for positioning them correctly on some devices, while positioning them incorrectly on others.

top + fullh / 10 96 + fifth \* j

Should I return to using pixels instead of fractions of screen height and width?

Also, even if I did return to using pixels, it would still be mispositioned because I have content near the corners of the device.

#14

Hi @sdktester15,

Yes, if you take anything like a “full width”, meaning the edge-to-edge pixel distance on all devices, that will vary because some devices are wider than others. So then doing division on that will make your objects position incorrectly. That’s why I choose to work in a predictable “letterbox” content area, and then push things like UI elements toward the edges of the screen (as I outlined in another post).

Another option, which some prefer, is to use “zoomEven” scale mode. Have you used that before and do you understand how it works?

Take care,

Brent

#15

First of all, what do you mean by push things toward the edges of the screen? I assume this is to fill the black bars sometimes left behind by letterBox’s scaling.

Second of all, I have not used zoomEven. But it seems to fill the width, but cause content to bleed off of the top and bottom.  

I can see the advantages of letterBox in some cases. So, I guess I would use pixels to move them. But at the same time I had some problems with pixels.

Uuhhh… this is so frustrating.  <_<

Hmm… I guess a solution could be to position objects based on the position of other objects.

object1.x, object1.y = 100, 150 object2.x, object2.y = object1.x, 250

Do you think this would be a good practice?

#16

I think you may be making it more complicated than it needs to be. :slight_smile:

Generally, if you want to work in a more predictable content area, it’s based on two choices:

  1. Use “letterbox” and then “fill” the letterbox bars (if any) with content, or push objects like UI toward the actual screen edges using the tips I mentioned in the other post.

  2. Use “zoomEven” and know that your screen will be entirely filled BUT you will have some content bleed off the edge when the aspect ratio differs.

Using #1, you can also push game objects (not just UI) toward edges. And yes, you could use a “relational” thing too, positioning objects relative to some parent object so that they all stay aligned.

Brent

#17

I guess I will stick with letterBox, I have never had any problems with it. Also, I think the relational positioning would work since none of the sizes of anything in my game will change depending on the device with the exception of backgrounds.

#18

In most games, there are game objects where the distance between them is important, then there are objects that can move based on the shape of the screen these are typically buttons, joystick controls, scores, life bars, basic UI bits… Then there is the background which needs to be designed to fill the screen regardless of the device.

If your game objects need to be the same distance apart, you cannot use a dynamic config.lua but if you’re building a card game where the various stacks of cards can spread out or move closer together  based on real estate a dynamic config.lua can help you. This needs to be the very first decision you make when deciding what to do. You of course, can make either one work, but you’re likely going to need  to do more work to make a card game where it’s okay to spread the cards out with a fixed config.lua and it’s a pain in the rear to make a angry birds type game function with a dynamic config.lua.

Next, your non-game objects, i.e. your UI bits usually need to be positioned near edges of the screen. The dynamic config.lua guarantees that 0, 0 will be the top, left corner and that display.contentHeight, display.contentWidth is guaranteed to be the bottom, right corner. Lets day you have a fire button you want 50 px away from the bottom, right. You simply position it at:  display.contentWidth - 50, display.contentHeight - 50. Want the life bar 50 px from the top, left, simply set them to 50, 50. Done. With a fixed config.lua, you have to use display.screenOriginX, display.screenOriginY and add those values to any object that needs to be near the edge of a screen and use display.actualContentWidth and display.actualContentHeight to get to the right and bottom of the screen. (you still need to add the screenOrigin* values to your right and bottom positioned items). Normally you want these items to move based on the shape of the screen.

Finally the background should be large enough to cover the full width of a 16:9 device understanding that on a tablet, part of the wide-side will be off screen. We call this “bleed” in developer terms. On the other size, the background has to be large enough to cover the full height of a tablet, understanding that some of the screen will be off screen when on a 16:9 phone.  How do you accomplish this? If you’re using a recommended 1.5x to 1 (3:2 aspect ratio) content area, i.e. 320 x 480, 800x1200, etc. then you want to use a background such as 570x360 (landscape or 360x570 portrait).  On a 16:9 your screen will be 320x568 to 570 depending on rounding. So by having the long side 570 on a 480 content area, your background should not black-bar in that direction. If you jump on an iPad then the virtual screen size will be 360x480. So those extra pixels on the short side will fill the iPad, preventing black bars, but 90 pixels (45 on each side, 44 with an iPhone 5), will be off screen. Simply don’t put anything on the background image in these bleed areas and you will never see black bars regardless of what config.lua you use.  This is all about making your background big enough to fill the black areas.  If you use an 800x1200 content area, the backgrounds should be 900x1425.

So to sum up, there is no perfect config.lua file. You just have to understand the limits of what you choose to do and understand out different aspect ratios fit on a canvas.

So to get to your question, if objects need to be a fixed distance from each other, you can easily use object2.x = object1.x + someDistance.

I like doing:   object2.x = object1.x +  0.5 * object1.width + somePaddingAmount.

Rob

#19

Wow, this summed up everything in a neat little bow. Also, it won’t be a card game, but rather a base defense game. I understand you used the cards as the example. But thank you for the valuable info, especially over background size. Turns out positioning objects in accordance to different objects is working perfectly. I checked in Nokia, iPad, iPhone, Android, Kindle, and HTC, and the text objects are in relatively the same place.

I guess you use this formula to account for the default 0.5 anchor.