@jollzy,
Sorry that file is missing, I cleaned out my dropbox a few months back and can’t seem to find it anymore. Maybe @RSCdev still has a copy of it around? If not I can make another one, it’s not too hard I just don’t have the time at the moment. I will; get to it if he doesn’t have a copy! [import]uid: 19620 topic_id: 23200 reply_id: 142514[/import]
@jollzy @rxmarccall I still have a copy of it. Hopefully this works: https://www.dropbox.com/s/82x2akdf0wixiea/UniversalBuildSkeleton.zip [import]uid: 173326 topic_id: 23200 reply_id: 142517[/import]
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