Hello guys
ingemar: thanks a lot for your work!
Please tell me, how do you use those on anything other than devices with ratio configured in config.lua?
It’s the second time I’m trying to build an app in corona, which should look close to native, and it’s the second time I’m reinventing the wheel when it comes to composer and running the app on anything different than 320x480 ratio. BTW. Corona folks still didn’t update the widgets library to handle anything else than that screen size… But I understand the focus is somewhere else.
Anyway… how do you handle a scene which appears close to the side of the device and disappears before it slides totally out of the screen?
I have to change all of those animations to match the screen size.
There’s a second drawback however - composer is using transition.* library for the transitions, which has a time based algorithms, which means that if your scene loads for a little longer than few frames, you will end up with your scene showing [again] further away from the side of the screen.
So I always [where always equals 2 ;)] end up giving up on Composer and using something custom, based on the AKTween library [thank you oh great AK :)] to create something nice.
I probably wouldn’t whine about that, but creating new easing effects for AKTween is a little pain in the butt .
Am I the only one with such issues? 
I’m not sure I follow what you mean. display.contentWidth will adapt to whatever the config.lua is set to.
I haven’t used 320x480 for a long time (I use 682x1023) and it works well with that configuration.
This is a stripped down version of a config.lua from one of my recent projects
-- config.lua local aspectRatio = display.pixelHeight / display.pixelWidth SAFE\_HEIGHT = 1023 SAFE\_WIDTH = SAFE\_HEIGHT / 1.5 -- make it 3:2 aspect ratio local maxAspect = SAFE\_HEIGHT / SAFE\_WIDTH application = { content = { width = aspectRatio \> maxAspect and SAFE\_WIDTH or math.ceil(SAFE\_HEIGHT / aspectRatio), height = aspectRatio \< maxAspect and SAFE\_HEIGHT or math.ceil(SAFE\_WIDTH \* aspectRatio), scale = "letterbox", fps = 60, antialias = false, xAlign = "center", yAlign = "center" } }Can I respectfully request that you open a new thread to discuss the content area. This has been a great thread about iOS 7 style transitions and I would hate for it to get hijacked to a new subject.
Thanks
Rob
It also seems possible to do this with Storyboard via a similar (or the same) mechanism. From January 2014:
http://forums.coronalabs.com/topic/42971-storyboard-transition-easing-options/
Rob: I’m very sorry, that was not my intention, back to the topic.
ingemar: you use 0 coordinate a lot in your configuration, that was my main worry, here’s why:
0 is rarely the left edge of the screen, it usually is a value below 0, in order to compensate this, we [and from the look of things it seems to be the general approach (at least that’s something I see most often on the boards)] insert elements into scenes with coordinates below 0.
Here’s a little pic to illustrate what I mean:
So now the scene is located at 0, but the content starts at -20 for example.
So according to your config, if I have a scene created like this and want to slide it into the screen from left, the scene will be loaded at display.contentWidth, so point (0,0) of the scene will be located at (display.contentWidth, 0), so it will look this way:
Isn’t that right?
So in order to handle that, I would expect the start x to be set to (display.contentWidth - display.screenOriginX) instead of display.contentWidth.
Well since no one said anything about this, I’m wondering what did I do wrong?
This effect is not really visible on phones, but on tablets where the difference in screen ratio when compared to phone is big, this effect is clearly visible.
I hope this won’t be considered as hijacking 
- again, my apologies Rob.
Krystian
Now I see what you mean :). It’s about the “old” vs “new” way of handling the screen.
I used to use a fixed width and height in my config.lua, but there were several issues with that approach, among them (as you’ve also detected now) is that 0,0 is not always in the upper left corner which causes unwanted behaviour in many situations (such as composer effects). However if you use my config.lua I posted above, the origin (0,0) of the screen will *always* be in the upper left regardless if it’s run on a tablet or phone. Just replace the SAFE_HEIGHT value with whatever value you want to use.
My config.lua is a modified version of Rob’s “Modernized config.lua” as described here:
http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
I always use letterbox to scale my screen, and there are times where you need to know the “safe area” of the letterboxed content.
I have a module with a few functions that calculates this which I use throughout my app.
Here’s a stripped down version of my appglobals.lua
require("config") local deviceScreen . . . local configureScreen = function() local dWidth = display.contentWidth \> application.content.width and SAFE\_HEIGHT or SAFE\_WIDTH local dHeight = display.contentWidth \> application.content.width and SAFE\_WIDTH or SAFE\_HEIGHT deviceScreen.left = 0 deviceScreen.top = 0 deviceScreen.right = display.contentWidth deviceScreen.bottom = display.contentHeight deviceScreen.width = deviceScreen.right - deviceScreen.left deviceScreen.height = deviceScreen.bottom - deviceScreen.top deviceScreen.safeLeft = math.ceil((deviceScreen.width - dWidth) / 2) deviceScreen.safeRight = deviceScreen.right - deviceScreen.safeLeft deviceScreen.safeTop = math.ceil((deviceScreen.height - dHeight) / 2) deviceScreen.safeBottom = deviceScreen.bottom - deviceScreen.safeTop end local getScreen = function() return deviceScreen end . . . local public = {} public.configureScreen = configureScreen public.getScreen = getScreen return public
I call configureScreen() in my main.lua and I require(“appglobals”) in all my modules. I can then access the safe area coordinates for the particular device I’m running my app on.
After switching to this approach, instead of fixed width/height values in config.lua, all issues have been eliminated, and all the composer screen effects will work as expected. It’s the only way to get slide effects to work properly across devices.
The bad news is that switching to this new style of config.lua will require you to adjust object coordinates in your old apps to accommodate for the shift of origin, but it’s worth it. Like I mentioned above, it’s the only way to get some of the composer effects to work across devices (including the ones I made above).
Here’s a sample project that shows the difference between the “old” vs “new” style of config.
(Just comment / uncomment the relevant lines in config.lua)
With the old style config, the slide transition doesn’t start at the left edge and doesn’t go all the way to the right edge on an iPad. You’ll also see black border issues in the iPad and iPhone 5 simulators.
The new style config eliminates all these issues.
Hello ingemar,
thanks a lot! I use custom properties for handling width, height, and 0,0, but I never thought about changing config.lua to make the 0,0 always in the upper left corner.
Thanks a lot for this! Will think of it when developing next game.
For apps, however, I cannot do it, since I want to use the widgets from widget 2.0 library, and they require the config.lua width and height values to be set to 320x240.
Thanks a lot for this!
There are several ways to approaching managing various screen shapes with config.lua. I’m with Ingemar. I want 0, 0 to be my top left and display.contentWidth, display.contentHeight to be bottom right. But this comes with a price that you can predict center in advance. You have to use math to derive center and place things relative to edges or the center.
As for widgets, you can still use a config.lua that has 0, 0 at the top left. As long as you keep your numbers for the width and height around the 320 pixels as the core width, widgets will work just fine.
If you’re doing non-game apps, I would recommend you consider an “adaptive” config.lua (change “letterbox” or “zoomEven” to “adaptive” and leave out height/width. This will give you different screen sizes based on device, but the relative size of things like tabBars, buttons, switches, etc. stay the same. That is if you sit several devices beside each other and have an on/off switch, it will be the same size on all devices.
Hello guys
ingemar: thanks a lot for your work!
Please tell me, how do you use those on anything other than devices with ratio configured in config.lua?
It’s the second time I’m trying to build an app in corona, which should look close to native, and it’s the second time I’m reinventing the wheel when it comes to composer and running the app on anything different than 320x480 ratio. BTW. Corona folks still didn’t update the widgets library to handle anything else than that screen size… But I understand the focus is somewhere else.
Anyway… how do you handle a scene which appears close to the side of the device and disappears before it slides totally out of the screen?
I have to change all of those animations to match the screen size.
There’s a second drawback however - composer is using transition.* library for the transitions, which has a time based algorithms, which means that if your scene loads for a little longer than few frames, you will end up with your scene showing [again] further away from the side of the screen.
So I always [where always equals 2 ;)] end up giving up on Composer and using something custom, based on the AKTween library [thank you oh great AK :)] to create something nice.
I probably wouldn’t whine about that, but creating new easing effects for AKTween is a little pain in the butt .
Am I the only one with such issues?
I’m not sure I follow what you mean. display.contentWidth will adapt to whatever the config.lua is set to.
I haven’t used 320x480 for a long time (I use 682x1023) and it works well with that configuration.
This is a stripped down version of a config.lua from one of my recent projects
-- config.lua local aspectRatio = display.pixelHeight / display.pixelWidth SAFE\_HEIGHT = 1023 SAFE\_WIDTH = SAFE\_HEIGHT / 1.5 -- make it 3:2 aspect ratio local maxAspect = SAFE\_HEIGHT / SAFE\_WIDTH application = { content = { width = aspectRatio \> maxAspect and SAFE\_WIDTH or math.ceil(SAFE\_HEIGHT / aspectRatio), height = aspectRatio \< maxAspect and SAFE\_HEIGHT or math.ceil(SAFE\_WIDTH \* aspectRatio), scale = "letterbox", fps = 60, antialias = false, xAlign = "center", yAlign = "center" } }Can I respectfully request that you open a new thread to discuss the content area. This has been a great thread about iOS 7 style transitions and I would hate for it to get hijacked to a new subject.
Thanks
Rob
It also seems possible to do this with Storyboard via a similar (or the same) mechanism. From January 2014:
http://forums.coronalabs.com/topic/42971-storyboard-transition-easing-options/
Rob: I’m very sorry, that was not my intention, back to the topic.
ingemar: you use 0 coordinate a lot in your configuration, that was my main worry, here’s why:
0 is rarely the left edge of the screen, it usually is a value below 0, in order to compensate this, we [and from the look of things it seems to be the general approach (at least that’s something I see most often on the boards)] insert elements into scenes with coordinates below 0.
Here’s a little pic to illustrate what I mean:
So now the scene is located at 0, but the content starts at -20 for example.
So according to your config, if I have a scene created like this and want to slide it into the screen from left, the scene will be loaded at display.contentWidth, so point (0,0) of the scene will be located at (display.contentWidth, 0), so it will look this way:
Isn’t that right?
So in order to handle that, I would expect the start x to be set to (display.contentWidth - display.screenOriginX) instead of display.contentWidth.
Well since no one said anything about this, I’m wondering what did I do wrong?
This effect is not really visible on phones, but on tablets where the difference in screen ratio when compared to phone is big, this effect is clearly visible.
I hope this won’t be considered as hijacking - again, my apologies Rob.
Krystian
Now I see what you mean :). It’s about the “old” vs “new” way of handling the screen.
I used to use a fixed width and height in my config.lua, but there were several issues with that approach, among them (as you’ve also detected now) is that 0,0 is not always in the upper left corner which causes unwanted behaviour in many situations (such as composer effects). However if you use my config.lua I posted above, the origin (0,0) of the screen will *always* be in the upper left regardless if it’s run on a tablet or phone. Just replace the SAFE_HEIGHT value with whatever value you want to use.
My config.lua is a modified version of Rob’s “Modernized config.lua” as described here:
http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
I always use letterbox to scale my screen, and there are times where you need to know the “safe area” of the letterboxed content.
I have a module with a few functions that calculates this which I use throughout my app.
Here’s a stripped down version of my appglobals.lua
require("config") local deviceScreen . . . local configureScreen = function() local dWidth = display.contentWidth \> application.content.width and SAFE\_HEIGHT or SAFE\_WIDTH local dHeight = display.contentWidth \> application.content.width and SAFE\_WIDTH or SAFE\_HEIGHT deviceScreen.left = 0 deviceScreen.top = 0 deviceScreen.right = display.contentWidth deviceScreen.bottom = display.contentHeight deviceScreen.width = deviceScreen.right - deviceScreen.left deviceScreen.height = deviceScreen.bottom - deviceScreen.top deviceScreen.safeLeft = math.ceil((deviceScreen.width - dWidth) / 2) deviceScreen.safeRight = deviceScreen.right - deviceScreen.safeLeft deviceScreen.safeTop = math.ceil((deviceScreen.height - dHeight) / 2) deviceScreen.safeBottom = deviceScreen.bottom - deviceScreen.safeTop end local getScreen = function() return deviceScreen end . . . local public = {} public.configureScreen = configureScreen public.getScreen = getScreen return public
I call configureScreen() in my main.lua and I require(“appglobals”) in all my modules. I can then access the safe area coordinates for the particular device I’m running my app on.
After switching to this approach, instead of fixed width/height values in config.lua, all issues have been eliminated, and all the composer screen effects will work as expected. It’s the only way to get slide effects to work properly across devices.
The bad news is that switching to this new style of config.lua will require you to adjust object coordinates in your old apps to accommodate for the shift of origin, but it’s worth it. Like I mentioned above, it’s the only way to get some of the composer effects to work across devices (including the ones I made above).
Here’s a sample project that shows the difference between the “old” vs “new” style of config.
(Just comment / uncomment the relevant lines in config.lua)
With the old style config, the slide transition doesn’t start at the left edge and doesn’t go all the way to the right edge on an iPad. You’ll also see black border issues in the iPad and iPhone 5 simulators.
The new style config eliminates all these issues.
Hello ingemar,
thanks a lot! I use custom properties for handling width, height, and 0,0, but I never thought about changing config.lua to make the 0,0 always in the upper left corner.
Thanks a lot for this! Will think of it when developing next game.
For apps, however, I cannot do it, since I want to use the widgets from widget 2.0 library, and they require the config.lua width and height values to be set to 320x240.
Thanks a lot for this!
There are several ways to approaching managing various screen shapes with config.lua. I’m with Ingemar. I want 0, 0 to be my top left and display.contentWidth, display.contentHeight to be bottom right. But this comes with a price that you can predict center in advance. You have to use math to derive center and place things relative to edges or the center.
As for widgets, you can still use a config.lua that has 0, 0 at the top left. As long as you keep your numbers for the width and height around the 320 pixels as the core width, widgets will work just fine.
If you’re doing non-game apps, I would recommend you consider an “adaptive” config.lua (change “letterbox” or “zoomEven” to “adaptive” and leave out height/width. This will give you different screen sizes based on device, but the relative size of things like tabBars, buttons, switches, etc. stay the same. That is if you sit several devices beside each other and have an on/off switch, it will be the same size on all devices.