On second look, I had a curly bracket out of place The “updated” config build looks the same as the “normal” build.
I have another project I want to try this on, because if it works, I will have pulled all my hair out for nothing!
On second look, I had a curly bracket out of place The “updated” config build looks the same as the “normal” build.
I have another project I want to try this on, because if it works, I will have pulled all my hair out for nothing!
I agree Rakoonic, and this is exactly how I do things. I would much rather work from the top left like I’m used to. Especially with all the headers and things like that. As long as you know the actual screen dimensions then people should size and place objects according to percentages of the _W & _H. Just makes more sense to me.
The only slight ‘issue’ I have with any scaling at all is that it can make pixel perfect alignment a slight issue. Maybe it’s best not to scale at all and work completely with percentages of the actual resolution?
First of all, display.contentWidth and display.contentHeight are supposed to be read-only varaibles (see: http://docs.coronalabs.com/api/library/display/contentHeight.html). You probably should not be trying to change them. The display.actualContentHeight would seem to handle getting you the height of the content area including the letterBoxed bars and you could use that if needed, but other values like display.contentCenterX and display.contentCenterY are set based on display.contentWidth and display.contentHeight. You in code have to change those values if you want to use them.
While you are an experienced programmer and understand the pitfalls of using globals and know when you can safely use them, that isn’t the case for many of the developers out there. We are trying to discourage usage of global variables and while _W and _H are handy short cuts, it’s a better practice to use the values provided with the display object.
The beauty of Corona SDK is things like are not made of right and wrong ways to do things. You should use what works for you. But with the wide level of skills helping the community solve a problem is an easy manner is a good thing.
Rob - Yeah I would not recommend changing values like that either, and I was also hesitant about using the globals sample, but I’ve seen plenty of people using them.
Regarding the other values not being correct, you are right, but then again I never used them to be honest - I just needed to know the width and height and I do the rest myself. I just felt I was missing something because this config.lua thing is something I’ve seen raised many times in the past.
As for Corona (or rather Lua) having multiple ways of doing things I agree. I consider myself a reasonable programmer, but am new to Lua, and still learn new things all the time that makes me love it more and more
@craig - I have this issue in some games, where I want pixel perfect control. What I do in this case is have no scaling mode, and for front ends and menus etc I wrote my own alternative to content scaling. It works essentially the same, but the difference is you can toggle it on and off, so I get the best of both worlds.
@Rob, I don’t think anyone is changing those read-only variables. Just using them as a reference. Always referring to the _W & _H when sizing and placing elements on the screen (adding differences depending on which device) gives a developer more control imo, rather than sort of ‘hoping for the best’.
But agreed, whatever is easier for each developer.
Also what is wrong with using just a few globals? Surely they don’t take up too much memory, and as long as you don’t keep making them throughout the app would it really matter? I would only create them when the app initializes (main.lua) and never create them on my “objects” (external scripts that a called multiple times) - I can definitely see why that would be an issue
Craig I think the ‘no globals’ is best practice. I guess they try to hammer it home early on so people don’t get accustomed to using them. I must admit I did use a few and then went down to one (I had a global table which is where I stored my ‘globals’), before someone kindly posted code which removed the need for all globals but maintained the same functionality.
Here’s the code - put it into a new lua file, call it globals.lua and you are almost ready.
[lua]local _data = {}
return data[/lua]
To use it in any file you need globals just do something like:
[lua]local _myGlobals = require( “globals.lua” )[/lua]And that is it! You then just create and read globals by putting them into the _myGlobals variable, eg:
[lua]_myGlobals.playerLives = 10
print( _myGlobals.playerLives )[/lua]Simple ‘globals’ without any globals. I’d probably not use _myGlobals as a variable name, I soon tire of anything longer than a few characters!
Right, I get that. but it still makes accessing these same variables between different objects a little difficult. Every time you ‘require’ that table, you are essentially resetting all the variables. I guess you could pass it as an argument into an objects ‘new’ function in order to keep referencing it.
But yeah, that data table would be fine for static variables.
Craig, no, you don’t reset the table.
The first time you require a file, it loads it into memory. However, future requires don’t reload it, they merely pass a reference to the already-loaded module, which is why the values persist.
Ah cool thanks for that. All my external scripts have tables created within function scopes, so I am used to doing things like: local newHeader = require(“Classes.Objects.Header”).new(“titleHere”), and it of course would return a new ‘instance’. I was not sure how the require operation actually operated itself.
Does this technique get better or worse with Corona moving (in Graphics 2.0) to everything being created at center (rather than top/left) coordinates?? What are the pro’s and conn’s of Rob’s ultimate config and this approach in terms of easy/intuitive display-object placement?
Does this technique get better or worse with Corona moving (in Graphics 2.0) to everything being created at center (rather than top/left) coordinates?? What are the pro’s and conn’s of Rob’s ultimate config and this approach in terms of easy/intuitive display-object placement?
I find this to be a good approach. I do a similar thing but I don’t align the content to top left I just setup my own varibales for screenTop, screenBottom, screenWidth, screenHeight, screenCenter (changed by status bar or action bars) and other and then use those for positioning.
I don’t think that G1.0 vs G2.0 has anything to do with The ultimate config.lua, though I guess things could be a bit easier. For me when I started with Corona SDK, I was very confused because different things got positioned differently when you passed in the X, Y, the exact thing that G2.0 addressed so I got in a habit of explicitly setting the .x and .y after creating the object since I knew that was positioning by the center anyway. With G2.0 I can now consistently position things and I’m trying to break the habit of explicitly setting the .x and .y, though I think the code is easier to read when I do.
But regardless of the config.lua, this positioning works. Where you have to think differently with the ultimate config.lua is positioning things in the middle of the screen or along the right and bottom edges. Instead of using fixed numbers like x = 460 you have to use x = display.contentWidth - 20 and you have to be okay with edge positioned things relative distance of a fixed distance. In other words for a landscape app, you might have a score near the right edge and the player’s lives left near the left edge. This lets you keep them a fixed distance form the edge vs. a fixed distance from each other.
Hey,
Rob and/or rakoonic, I could really use your help, guys!
I’m really frustrated due to the fact I haven’t accomplished the “ultimate” config yet. I’m designing a game. I read both the ultimate config and modernizing the config articles created by Rob Miracle, but nothing really works. If I use rakoonic’s method, do I still need image suffix? If so, exactly what types? 1.5 and 3.0? Does this mean I still need three different backgrounds (360x570, 720x1140, 1148x2280)? If so, using rakoonic’s method, are the following lua files correct?
config.lua:
[lua]
application =
{
content =
{
width = 320,
height = 480,
scale = “letterbox”,
xAlign = “left”,
yAlign = “top”,
fps = 30,
imageSuffix = – 360x570
{
["@2x"] = 1.5, – 720x1140
["@4x"] = 3.0, – 1148x2280
},
},
}
[/lua]
main.lua:
[lua]
display.setStatusBar(display.HiddenStatusBar)
_W = math.floor(display.actualContentWidth + 0.5)
_H = math.floor(display.actualContentHeight + 0.5)
local background = display.newImageRect(“textures/background.png”, 360, 570) – Is it correct, or is it 320x480?
background.anchorX = 1 – Is it correct?
background.anchorY = 1 – Is it correct?
background.x = _W – Is it correct?
background.y = _H – Is it correct?
[/lua]
If rakoonic’s method is really working, I’d like to know if this is correct. If not, please tell me how.
Both of our systems work. Your code will draw your background with the bottom right corner of the artwork at the bottom right corner of the device regardless of the shape of the device. Depending on your artwork, this may be the the right thing or not. You can do:
local background = display.newImageRect("textures/background.png", 360, 570) -- Is it correct, or is it 320x480? background.anchorX = 0 -- Is it correct? background.anchorY = 0 -- Is it correct? background.x = 0 -- Is it correct? background.y = 0 -- Is it correct?
And it will draw your artwork with its Top Left corner at the top left of the screen or you can do:
local background = display.newImageRect("textures/background.png", 360, 570) -- Is it correct, or is it 320x480? background.anchorX = 0.5 -- Is it correct? background.anchorY = 0.5 -- Is it correct? background.x = \_W / 2 -- Is it correct? background.y = \_H / 2 -- Is it correct?
And it will draw your background at the center of the screen.
Depending on your background and were important elements are, you may want to use any of the three ways to draw your background. Just keep in mind that on some devices the bottom part of the screen will get cut off, on others the sides are going to get cut off. Using centered, then some might get cut off of both sides.
This graphic can help you understand that’s going on:
Now this assumes a center drawn background. On an iPad you will get the yellow and blue areas on screen and the green and red will get cut off. On an iPhone 5 or many Android phones, you will get the red and blue area visible while the green and yellow will be off screen. If you’re on an iPhone 3 or 4 you will only get the blue area. Most Android tablets will loose some of the red, green and yellow, but keep some of it.
What you put in the red, green and yellow areas will determine the best placement strategy for you. The Ultimate config.lua is based on these area’s being centered on the screen. 0, 0 will be the top left. display.contentWidth, display.contentHeight will be the bottom right corner and display.contentCenterX, display.contentCenterY will be the center.
Rakoonic’s is accomplishing the same thing. It’s difference is that display.contentWidth, display.contentHeight return the defined values of 320 and 480 which may not be the actual content width and height. This is why he uses the values display.actualContentWidth and display.actualContentHeight to create the shortcut’s _W and _H. At this point _W and _H represent the bottom right corner. You have to calculate your own center values by dividing _W and _H by 2 (or multiply by 0.5) to compute your real centerX and centerY values.
As for the @2x and @4x things, you always load in the size of your smallest one. In this case, 360x570 and you use the actual size of the image, not the content area. That way the parts that need to bleed of the screen will and the artwork won’t be distorted by changing it’s aspect ratio.
Rob
Hey Rob,
First of all, thanks for responding and helping me! I really appreciate that, honest. Second, this is how my config.lua and main.lua are, at the moment. And yes, I have managed to center the background (there are no bleed areas). I use three different backgrounds (360x570, 720x1140, 1148x2280), just like you mentioned on your previous article (the ultimate config). These are my settings.
config.lua:
[lua]
application =
{
content =
{
width = 320,
height = 480,
scale = “letterbox”,
xAlign = “left”,
yAlign = “top”,
imageSuffix =
{
["@2x"] = 1.5,
["@4x"] = 3.0,
},
},
}
[/lua]
main.lua:
[lua]
display.setStatusBar(display.HiddenStatusBar)
local storyboard = require(“storyboard”)
storyboard.gotoScene(“scenes.start”)
[/lua]
scenes/start.lua:
[lua]
local storyboard = require(“storyboard”)
local scene = storyboard.newScene()
_W = math.floor(display.actualContentWidth + 0.5)
_H = math.floor(display.actualContentHeight + 0.5)
function scene:createScene(event)
local sceneGroup = self.view
local background = display.newImageRect(“textures/background.png”, 360, 570)
background.x = _W / 2
background.y = _H / 2
sceneGroup:insert(background)
end
scene:addEventListener(“createScene”, scene)
return scene
[/lua]
I’m trying to be as organized as possible, so if you care to share your knowledge, please do. Everything works just fine, but just to be one hundred percent sure, do you find anything wrong? Anything at all?
Thanks once again, Rob. You are one helluva guy!
That seems to be doing what you need it to do. Just keep in mind that display.contentWidth, display.contentHeight, display.contentCenterX, and display.contentCenterY values won’t work for you. You will have to use your calculated _W and _H and compute your own center’s.
One completely off topic thought. If you haven’t downloaded 2189 yet, I would do so, and switch from Storyboard to Composer (It’s storyboard 2.0). http://coronalabs.com/blog/2014/01/21/introducing-the-composer-api-plus-tutorial/
It’s going to be the scene manager that gets features and bug fixes going forward. We are retiring storyboard. If you are not too deep into it, switching now will be easier than later. Same basic principles, just a cleaner API and a better code base for us to support long term.
Rob
Thanks for the heads up. I’ll switch to composer.
By the way, why won’t these displays work? Can you be more specific?
Also, you mentioned that I’ll have to calculate the center point myself, do you mean _W / 2 for x, _H / 2 for y?
EDIT: I downloaded version 2189 and was wondering, when I use composer, it doesn’t change the color to blue, like it’s a function (it works, but the color remains white), is it because my corona editor package is not updated? If so, how do you I update it (i use sublime text)?
display.contentWidth and display.contentHeight return the value from your config.lua. Since you only set 320 and 480, regardless of the device, that’s the values returned. That’s why the method you are using is using display. actual ContentWidth and display. actual ContentHeight. Likewise display.contentCenterX is display.contentWidth / 2, not display. actual ContentWidth / 2.
Corona Editor has not been updated to know about composer yet. This is to be expected.
Rob