we should probably remind readers that the " actual…" values describe values that are proportionate with the content scaling implied by config.lua (ie resulting contentScaleX & Y), where the pixel -values use physical hardware and ignore any effect of the scaling model…in other words, “actual” can be used with the same percent/ratio calcs as contentWidth but are more descriptive of the full (100%) screen in the 0,0 model described above. I’m quite sleepy so I hope this makes sense…someone else may want to reword this and also explain the difference from: viewableContentHeight
display.pixelWidth, display.pixelHeight gets the actual device resolution in pixels.
display.actualContentWidth, display.actualContentHeight gets the device’s actual screen size in “content area points” based on the defined width and height in config.lua.
Lets say you have a content area defined as 320 x 480 (and held in portrait mode).
Device .contentWidth .contentHeight .actualContentWidth .actualContentHeight .pixelWidth .pixelHeight
iPhone3gs 320 480 320 480 320 480
iPhone4/4s 320 480 320 480 640 960
iPhone5/5s 320 480 320 568 640 1136
iPad 2 320 480 360 480 768 1024
iPad 3/4/Air 320 480 360 480 1536 2048
Kindle Fire HD 320 480 320 512 1600 2560
Hopefully those examples will help you understand what values are returned and when.
Hi guys, I am starting to get ready to implement all my graphics and I was wondering whether its still really necessary for 360x570 graphics? Seems to be required less and less, is it still worth it?
Also I assume you need to create higher resolutions for all your graphics (such as items, characters etc)? For example if I have graphics that are around 32x32 that work well at 360/50 resolution should I just double it (and again) when scaling up the resolutions?
Thanks,
Mark
Brent and I think it’s probably time that many people can skip the 300px class of image sizes. We started recommending a content are of 800x1200 as it’s device agnostic (i.e. it’s not an actual screen size) to get you out of thinking in terms of pixels. But there is a problem with our widgets where some things like the widget.newPickerWheel isn’t scalable and is designed for a 320x class content area. If you plan to make use of widgets, you need to stay with the 320x480 sized content area. There may be other reasons too.
But to us the benefits are: 1. There just are not that many small screen sizes still out there. Yes, we want to support every possible device, but at some point, you have to not support the tiny screens any more. 2. It cuts down on the number of files in the app bundle and while it doesn’t save that much on space, it helps with your sanity.
Only you can decide how many of these older screens you want to support. If that’s important, I would stay with the smaller content area because those devices have less memory and CPU to handle resizing the graphics down.
Does CL have no plans to make the widgets scale?? I’m too far into my app (at 640 x 960) to revert back to 320x480 now.
So if CL is not going to make that improvement, then I’ll need to do it or hire someone to do it while I’m working on other things.
The only one I really need is PickerWheel (as a date-picker). Does anyone have any guestimates on how much work that would be?? Alex??
Thanks
Dewey
Hi Dewey I would say its not something we are going to tackle any time soon. I don’t know if there is an entry for it on the Feedback site or not or if it is how many votes it has. But given our priorities and what engineering is working on it, adapting pickerWheel to be resizable isn’t very high on the priority list. I took a quick glance through the open source code and it seems to me the limits are based on the graphics used to draw the various chrome parts for the pickerView.
You might be able to decode what’s going on there, provide your own graphic frames at whatever size you want them and make it work. However that’s not a widget I’ve attempted that with.
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
we should probably remind readers that the " actual…" values describe values that are proportionate with the content scaling implied by config.lua (ie resulting contentScaleX & Y), where the pixel -values use physical hardware and ignore any effect of the scaling model…in other words, “actual” can be used with the same percent/ratio calcs as contentWidth but are more descriptive of the full (100%) screen in the 0,0 model described above. I’m quite sleepy so I hope this makes sense…someone else may want to reword this and also explain the difference from: viewableContentHeight
display.pixelWidth, display.pixelHeight gets the actual device resolution in pixels.
display.actualContentWidth, display.actualContentHeight gets the device’s actual screen size in “content area points” based on the defined width and height in config.lua.
Lets say you have a content area defined as 320 x 480 (and held in portrait mode).
Device .contentWidth .contentHeight .actualContentWidth .actualContentHeight .pixelWidth .pixelHeight
iPhone3gs 320 480 320 480 320 480
iPhone4/4s 320 480 320 480 640 960
iPhone5/5s 320 480 320 568 640 1136
iPad 2 320 480 360 480 768 1024
iPad 3/4/Air 320 480 360 480 1536 2048
Kindle Fire HD 320 480 320 512 1600 2560
Hopefully those examples will help you understand what values are returned and when.
Hi guys, I am starting to get ready to implement all my graphics and I was wondering whether its still really necessary for 360x570 graphics? Seems to be required less and less, is it still worth it?
Also I assume you need to create higher resolutions for all your graphics (such as items, characters etc)? For example if I have graphics that are around 32x32 that work well at 360/50 resolution should I just double it (and again) when scaling up the resolutions?
Thanks,
Mark
Brent and I think it’s probably time that many people can skip the 300px class of image sizes. We started recommending a content are of 800x1200 as it’s device agnostic (i.e. it’s not an actual screen size) to get you out of thinking in terms of pixels. But there is a problem with our widgets where some things like the widget.newPickerWheel isn’t scalable and is designed for a 320x class content area. If you plan to make use of widgets, you need to stay with the 320x480 sized content area. There may be other reasons too.
But to us the benefits are: 1. There just are not that many small screen sizes still out there. Yes, we want to support every possible device, but at some point, you have to not support the tiny screens any more. 2. It cuts down on the number of files in the app bundle and while it doesn’t save that much on space, it helps with your sanity.
Only you can decide how many of these older screens you want to support. If that’s important, I would stay with the smaller content area because those devices have less memory and CPU to handle resizing the graphics down.
Does CL have no plans to make the widgets scale?? I’m too far into my app (at 640 x 960) to revert back to 320x480 now.
So if CL is not going to make that improvement, then I’ll need to do it or hire someone to do it while I’m working on other things.
The only one I really need is PickerWheel (as a date-picker). Does anyone have any guestimates on how much work that would be?? Alex??
Thanks
Dewey