Also, don’t forget, that template works nicely for iPhone 5 res, however, you’ll need to add a “Default-568h.png” 640x1136 to your root directory otherwise you’ll get a letterbox effect. I’d also recommend using this for your config file: http://www.coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/ [import]uid: 173326 topic_id: 23200 reply_id: 142518[/import]
I’m highly impressed to see the comprehensive resources being offered by you.
so glad I found this post. +1
thanx for a real deep expl. of letterbox Ricardo
For iPhone 5, I had to change -
bottomY = display.contentHeight - display.screenOriginY
To -
bottomY = 568
Basically if it’s a iPhone 5 I use the number 568 instead, this seems to work fine so far for me.
Dave
Here is a handy screen size and resolution reference for most of the devices out there.
Your provided best information for my work it is cool thanks
Thanks and Kind Regards,
Jainteq
Hi,
Just out of curiosity, doesn’t a resolution of 360 by 570 go against the texture optimization suggestions located here. Would 360 by 512 not be a better idea, and just suffer the black lines at the top/bottom of the screen on high devices?
Going from 1MB to 2MB in texture memory for 58 pixels; is it a good trade?
evidence - The black bars (letterbox) is frowned upon now and in some cases will not be approved. Aside from that, why wouldn’t you want to give the user the best experience possible. The devices that have larger screens have them for a reason so why not use them? Imagine if every app had black bars because of texture space, what would be the point of having a larger screen?
If texture space / size is very crucial then my suggestion is that you create the image at 360 x 570 as a master file but save it out as 360 x 512. This will squish the image in one direction and look odd when you view the image directly but when the app scales it back out to 360 x 570 it will look normal. Scaling in one direction often produces results far better than scaling in both directions and if you run a test, I bet 9/10 times you will not really see a difference on the device. Try it 
You could make your backround 323x512 and load it as 360x570. It will scale up some and not be quite as sharp, but it would keep your texture on a 512 boundary.
But given most of the times you need this, it’s a background image. Most scenes only have one full screen image loaded at once, it’s not going to kill your memory usage. Now if you have a photo slide show and you’re loading a couple of dozen full screen photos at once, then you might have some memory problems.
Tim, providing the best user experience is what I am aiming for i.e. preventing low memory warnings. I will try this scaling and see how it looks.
Just for consideration I made this graphic to illustrate the amount of texture memory used for each resolution. http://img46.imageshack.us/img46/3064/n8tc.png
Blue is for iphone, phone 4 and iphone 5. Green is for Samsung Galaxy S2, S3 and S4. Black is the amount of texture memory required after an image is scaled up.
As you can see, to support the S4 you need 2048 x 2048 x 4(rgb+a) = 16MB of texture memory for one background image.
@evidence, “best user experience” is an open ended desire. Lower quality images to save some texture memory may not be the best user experience if your app doesn’t look good. There are probably other ways to optimize image than worry about a few background images.
On the flip side your app can be the most beautiful work of art on the planet, but it wont matter much if it crashes with low memory warnings every 5mins. As you said perhaps only an issue in certain situations e.g. a photo flip book, but I thought it was worth pointing out that staying within the texture boundary was not my idea; It is part of the Corona documentation. That said the scaling up method is also mentioned as a work around in the same document.
I would look at all of your image assets and see where you can scale down. If you are close to the texture memory limits like you have a 570px vs 512px, or even a 600px image, you might try going down to 512px just to see if you notice any difference in quality. Especially if you are squishing the image in one direction like I explained previously.
Back in the day when I was working on consoles like Dreamcast, Nintendo 64, Playstation 1, etc. we had to resort to all type of tricks to manage our texture memory and keep performance up. Often times we had crazy texture packing going on and scaling in 1 direction to fit memory sizes and scaling back up in the engine was used all the time.
Let us know how it goes.
HELL YES.
I’ve been dealing with this CRAP for a couple weeks now.
you’ll need to add a “Default-568h.png” 640x1136 to your root directory otherwise you’ll get a letterbox effect.
I never knew about that. I had the config lua right, build settings, and my images are exactly the size they needed to be but they ALWAYS letterboxed and it was pissing me off to the extreme.
However, once you drop that Default-568h.png into your root directory, things are awesome on the iphone 5, which is what I was targeting.
Yay.
So far, this seems to be a brilliant solution. Is there a way to make this more prominent in the documentation? It seems to me that it would be an ideal framework for people to work with.
So far, this seems to be a brilliant solution. Is there a way to make this more prominent in the documentation? It seems to me that it would be an ideal framework for people to work with.
FWIW, I think the math of the “magic” dimensions could be simplified, and clarified so that other content dimensions are easier to implement and calculate their full-bleed sizes.
It’s simply a matter of the relative fit of the content aspect ratio versus the device aspect ratio. If the content is “wider” than device, then letterboxing will fit width and letterbox top/bottom. If the device is “wider” than the content, then letterboxing will fit height and pillarbox left/right. (if the aspect ratios are an exact match, then you get a “perfect” fit, no bars, equivalent to zoomEven with no cropping occuring)
By convention, aspect ratio is calculated with an assumed landscape orientation, that is: longer-edge / shorter-edge. Aspect ratio is typically expressed as a ratio (fe 4:3, 3:2, 16:9) but may also be represented in equivalent decimal form (~1.333, 1.5, ~1.778). Current devices in production have aspect ratios that roughly range from 4:3 (iPad) to 16:9 (iPhone 5, many Android).
To calculate the dimensions of a “full-bleed” image:
full_bleed_width = content_height * max_device_aspect (which is 16:9, ~1.778)
full_bleed_height = content_width / min_device_aspect (which is 4:3, ~1.333)
I mention this only because it seems targeting the original iPhone’s 320x480 resolution _today_ seems a bit limiting, so you might want to calculate full bleed on a more modern (higher resolution) base content size. For instance, you might be better off defining content size as 640x480 (i happen to like 720x480, using a compromise 3:2 aspect ratio), and adding a lower resolution “@.5x” image set if you must support “320p” -type resolutions.
hth
Actually we recommend using a 360 x 570 base image as this bleeds on most all devices from the 4:3 iPads to the 16:9 devices based on the 320x480 content area. It’s simply what that math works out to.
Unless you are using a hand full of widgets (like widget.newPickerWheel), the content area is really arbitrary. It’s 320x480 because of some iPhone 3 legacy. Since Corona’s content area is a virtual view and we handle scaling to the actual device, you can make it whatever. In fact, with a few edge cases like the newPickerWheel, Brent and I are suggesting that people consider an 800 x 1200 content area. This is still a 1.5:1 aspect ratio from the iPhone 3/4, but it serves a purpose of being in between wide tablets and tall phones, kind of the happy medium. Moving to this side lets you pretty much eliminate a one of the 3 images (image.png, image@2x.png, image@4x.png) moving the former image@2x.png to image.png and image@4x.png to image@2x.png. But doing so means hurting the lower resolution devices (as they have less memory and CPU to process the larger files), but if your okay not supporting the hand full of these old devices, then moving to a larger content area makes sense.
Agree completely, (perhaps because we’re saying the same thing? :D) I was just attempting to “demystify” that math:
320 * 1.778 = 570
480 / 1.333 = 360
(rounding to even numbers)
I think it’s more “powerful” if you think in terms of aspect ratios instead of actual resolutions when talking about full-bleed dimensions. For example, with the underlying math exposed in simple terms, it lets you easily ponder questions like:
Q: what would happen if your content aspect ratio were LESS than the present device minimum (say 6:5, aka 1.2, ex: 900x750)? A: your content will pillarbox on ALL present devices. Your full bleed image size works out to 1334x750. (note substitution of 1.2 as min_device_aspect in calculation of height – no extra height required EVER, only need bleed to pillarbox width)
and conversely:
Q: what would happen if your content aspect ratio were MORE than the present device maximum (say 19:10, aka 1.9, ex: 950x500)? A: your content will letterbox on ALL present devices. Your full bleed image size works out to 950x712 (note substitution of 1.9 as max_device_aspect in calculation of width – no extra width required EVER, only need bleed to letterbox height)
Just food for thought, in support of entirely arbitrary content sizes of the developer’s chosing.