Understanding letterbox scalling

62 replies [Last post]
RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

Hi all,

I've replied to a post recently about how letterbox scalling works and since then I've bumped into a lot of people having trouble with the subject to whom I've been linking that old post.
As I came to the realization that it is quite an important subject and one that people don't understand too well, I'm creating a thread of its own, so here it goes:

<< Start of repost >>

Let's assume you're coding on portrait orientation.

You set your config.lua for a screen of 320x480 pixels, letterbox scalling, and position centered both vertical and horizontal.

1
2
3
4
5
6
7
8
9
application = {
    content = {
        width = 320,
        height = 480,
        scale = "letterbox",
        xAlign = "center",
        yAlign = "center",
    }
}

Now, when you create a background for the game, and you want to target iOS devices, so resolutions 320x480, 640x960 and 768x1024, you should do it like:

1
2
3
local bg = display.newImageRect("bg.png",360,480)
bg.x = display.contentWidth/2
bg.y = display.contentHeight/2

The resolution of the image files should be:

bg.png - 360x480
bg@2.png - 720x960, or even 768x1024 if you want it to look really good on iPad.

Why this 360 pixel width?

Well, the thing is that with letter box, the images on higher resolutions than defined on config.lua will be scaled to fit the screen, but they won't lose their aspect ratio, and that 320x480 rectangle you define on config.lua never goes out off screen.

Let's see some examples. Start by assuming we did things the "normal" way. You call background images as 320x480, what would happen is:

iPhone - No scalling, config.lua already defines a rectangle of the size of the screen, so it would look fine.

iPhone4 - Scaling by a factor of 2, so the ratio is the same. Would look fine too, it would use double resolution image (640x960)

iPad - the 320x480 rect would grow by a factor of 2.1333.., ending up at a size of 682x1024. Since the iPad has a 768x1024 screen, you would notice some black bars on the sides.

Now lets assume you did as I said and called background images as 360x480.

iPhone - No scalling since config.lua defines a rectangle of screen size. The background though is a bit bigger for the screen and has some extra width compared to screen size. Since the background is centered, you would actualy not see some pixels to the sides. More exactly, 360-320 = 40, so 20 pixels to each side.

iPhone4 - Exactly the same case but on higher resolution, scalling by a factor of 2, usage of high res images.

iPad - Once again it will grow by a factor of 2.133, so a 360x480 images would grow to 768x1024, completely filling the iPad screen. No black bars. Usage of high resolution images.

Basically, using this you create the backgrounds with some extra areas that will only be shown when the screen has a different ratio. The screen will always be filled. You have to keep in mind though that anything out of the 320x480 center rectangle of an image (considering low res images), will not show on some devices, so don't base you game in that areas, use it just for filling.

On Android the case is a bit different since the screen is actually taller (on portrait). So instead of having to increase width of background images from 320 to 360, you have to increase their height, from 480 to...
Well, considering all available android devices that number is 570.

In the case you want to completely support all resolutions of all phones/tablets available today, you should:

config.lua:

1
2
3
4
5
6
7
8
9
application = {
    content = {
        width = 320,
        height = 480,
        scale = "letterbox",
        xAlign = "center",
        yAlign = "center",
    }
}

Instantiation of images for backgrounds:

1
2
3
local bg = display.newImageRect("bg.png",360,570)
bg.x = display.contentWidth/2
bg.y = display.contentHeight/2

Low res images: 360x570 pixels
High res images: 720x1120 pixels

Remember that when you're coding though, you're coding for the rect defined on config.lua, so you're coding for a screen of 320x480. If for example on iPad you want to refer to the left of the screen it will not be 0, as 0 is a bit distant from the border, as iPad is wider and this 320x480 rect preserves aspect ratio. So you should actualy rely on some corona defined values to help you. For any device you can define the top, left, right and bottom points as:

Top:
local topY = display.screenOriginY

Right:
local rightX = display.contentWidth - display.screenOriginX

Bottom:
local bottomY = display.contentHeight - display.screenOriginY

Left:
local rightX = display.screenOriginX

Hope this helps everyone to understand letterbox a bit better!

<< End of repost >>

--
Manuel

Replies

@RSCdev
User offline. Last seen 1 year 32 weeks ago. Offline
Joined: 6 Sep 2011

Clap, clap, clap...

I thank you for such explanation @CluelessIdeas.

Cheers,
Rodrigo.

peach pellen
User offline. Last seen 1 year 35 weeks ago. Offline
Alumni
Joined: 12 Apr 2011

Fantastic share! I imagine this will help a lot of developers :)

topthat
User offline. Last seen 4 weeks 4 days ago. Offline
Joined: 1 Sep 2011

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

topthat
User offline. Last seen 4 weeks 4 days ago. Offline
Joined: 1 Sep 2011

I've been playing with this code a bit, and wondered if there was any fault in the following globals (useful for positioning)

1
2
3
4
5
6
7
8
screenWidth = display.contentWidth - (display.screenOriginX*2)
screenHeight = display.contentHeight - (display.screenOriginY*2)
screenTop = display.screenOriginY + display.screenOriginY
screenRight = display.contentWidth - display.screenOriginX
screenBottom = display.contentHeight - display.screenOriginY
screenLeft = display.screenOriginX
screenCentreX = display.contentWidth/2
screenCentreY = display.contentHeight/2

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

There just one wrong:

1
screenTop = display.screenOriginY

Everything else seems fine.

By the way, if for any reason you want to have screenWidth and screenHeight in real pixels, instead of the abstraction created by what you define in config.lua, you can do it like:

1
2
3
4
5
screenWidth = display.contentWidth - (display.screenOriginX*2)
screenRealWidth = screenWidth / display.contentScaleX
 
screenHeight = display.contentHeight - (display.screenOriginY*2)
screenRealHeight = screenHeight / display.contentScaleY

topthat
User offline. Last seen 4 weeks 4 days ago. Offline
Joined: 1 Sep 2011

AH well spotted. I think I copy-pasted a bit too much.

Is there a reason why xAlign & yAlign are better set to "center" rather than "left" / "top"? Is this just to keep as much content on screen as possible?

Likewise, is letterbox used over zoomEven because of problems with physics (I read that zoomEven can mess up the physics object positions - perhaps not in the more recent builds of the SDK)

I'm trying to build up a basic project skeleton and want to ensure that it's likely to work on as many devices as possible.

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

That x and y alignment is for the box you define on config.lua, namely the 320x480 I defined in my examples. If you set them to left and top, for example on an iPad, instead of having an extra 20 (virtual) pixels on each side, you'll have 40 extra pixels on the right.

If you do this, when creating a background you can't set it's position for center (or else you'll have some bleeding areas going off screen to the left), you would have to set topleft reference and 0,0 position. This means that the bleeding area you create on your images for background would all have to be on the right (and bottom for androids). This would be extremely assymetrical. You would be positioning the focus of your game to the right, and to the top, instead of making people focus on the center of the device which I suppose makes more sense.

And imagine that you would want to set an element to the center of the screen. I don't even know if that would be possible. You would have to set the X of the element to be in the middle of the 320x480 rect, and then sum some ammount to actualy center it. How much would you have to sum? In this scenario screenOriginX would be 0, so you don't even know dynamicaly how large is the bleeding area to the right.

The problem with zoomEven is that on different ratios, some of the content from the 320x480 rect can go offscreen. What if some important content goes offscreen? The game becomes unplayable! With letterbox you guarantee that nothing inside that rect goes offscreen, so you have a region in which you can base your game, and you're sure that no matter how strange the ratio may be, it can even be 1000:1, nothing important will ever be offscreen.

Sassa
User offline. Last seen 1 year 18 weeks ago. Offline
Joined: 17 Jul 2011

Thanks! That post really helped me!
Can i use the same configuration for "landscape" scale?

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

@danillo.vellozo Yes of course. You just have to swap the dimensions of the images when creating them on your game logic. E.g.: display.newImageRect("bg.png", 570, 360) instead of what you see in the examples above.

robmiracle
User offline. Last seen 26 weeks 11 hours ago. Offline
Joined: 18 Jan 2011

This is a most brilliant and well explained post!!!

davemikesell
User offline. Last seen 10 hours 40 min ago. Offline
Joined: 9 May 2011

First, thanks for taking the time to write this. Math makes my head hurt, so I like "magic recipes". I'm doing almost what you recommend for my landscape app, except I'm using the 570x380 formula recommended here, since the actual size of my normal image is 570x380 pixels.

http://blog.anscamobile.com/2010/11/content-scaling-made-easy/

However, when I call

1
2
3
background = newImageRect("bg.png", 570, 380)
background.x = display.contentWidth/2
background.y = display.contentHeight/2

The image is blown up all the way and bleeds off the edges of the screen, like I called display.newImage("bg.png", true). Is this a bug in build 773? I have to scale it manually:

1
2
background.xScale = display.contentWidth / background.contentWidth
background.yScale = display.contentHeight / background.contentHeight

Another question to anyone and everyone. My client is providing me with the graphics, and most screens have the buttons burned into the background image. I'm creating invisible rectangles with touch listeners to get those areas to respond to button clicks, but I'm hardcoding the top, left, width, and height. Is that bad practice and should I be using the predefined Corona constants * a certain factor? If I ever changed my 320x480 in the config.lua, I suppose I would get badly burned by these hardcoded numbers.

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

@davemikesell It should be bleeding by exactly 570 - 480 = 90px or 45px on each side, and 380 - 320 = 60px or 30px on the top and bottom, if you done everything correctly. You seem to be making the same mistake most people do when dealing with image scaling. You're expecting to see the whole image all the time on all devices. That's not what you want. It's supposed to have bleed areas that aren't visible on all devices (e.g. iPhone). The background image is supposed to be bigger than the display.contentWidth and Height. If you scale it down like you do then you're loosing all the benefits of this approach and might as well just use newImageRect("img.png", 480, 320) because that's what you end up with by doing it like you do.

Also, if you followed the guides correctly and have everything working as expected then there's no need to use 380px tall images because the extra 20px will never be seen on any device.

davemikesell
User offline. Last seen 10 hours 40 min ago. Offline
Joined: 9 May 2011

Actually, it is what I want in this case, as my client is providing me background images with buttons baked into them. I think I either need to get them to stop doing that and send a larger plain background and separate button images, or I'm stuck with this approach, or even using zoomStretch to make sure everything is visible.

Thanks again for this thread, though - I'm learning a lot. I do understand your explanation, I just have a special case with this client.

davemikesell
User offline. Last seen 10 hours 40 min ago. Offline
Joined: 9 May 2011

One more thing I don't quite understand. Are you saying that if you use newImageRect with an image larger than the resolution set up in config.lua, it won't be scaled at all? That's what you appear to be saying when describing the bleed areas above on the 570x360 image.

Other images on the screen - text, logos, buttons - are scaled depending on which device I render to in the simulator. You can see this for yourself in the DynamicImageResolution sample by getting rid of the suffixes. The 200x200 image is displayed on iPad Retina and other large devices scaled up.

Why would backgrounds be different?

FortyFourDigital
User offline. Last seen 3 weeks 3 days ago. Offline
Joined: 7 Apr 2012

@davemikesell I managed to get these settings working. I found it easiest to draw out an image with pixel markers on it to see how they are displayed on different devices.

As @CluelessIdeas explained, the images are designed to display on iOS with some bleed (the edges of the background image are off the screen) and then on Android, you would see more of this background. The area defined in the settings is more of a "safe zone" that scales inside the device (keeping the aspect ratio). Rather than have black rectangles for any area outside of the safe zone, the bleed area on the background image will be visible instead. If you used a 320x480 background image, you would see the black rectangles.

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

Sorry for the confusion. It will always be scaled if you use a scaling mode on your config.lua. I forgot to mention that the bleed areas I mentioned are in "Corona" units, i.e. in relation to your stage width and height as defined in config.lua.

BTW, you can use buttons baked in using the method mentioned here (instead of the zoom method you seem to be using) as long as the buttons are inside the "safe area". What's the safe area you ask? Take your 570x360 image, put a 480x320 rectangle centered in the middle of it and there you have your safe area. Using the method outlined in this post everything inside this area will always be visible at all times in all devices no matter what the resolution or aspect ratio are.

FortyFourDigital
User offline. Last seen 3 weeks 3 days ago. Offline
Joined: 7 Apr 2012

@CluelessIdeas - that also helped me to see this safe area - made 2 red background images (360x570 and @2x 720x1120) and put a green"safe zone" rectangle right in the middle (320x480 and 640x960 respectively)

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

Just a little bonus for people using this method:

Instead of using 360x570 (and 720x1140) images you can scale those assets to 360x512 (720x1024) after creating them in the proper resolution (360x570) and you won't loose much detail. Remember that you only change the image assets, not the newImageRect values, because you want the Rect to be constant. This will save you a considerable amount of texture memory.

davemikesell
User offline. Last seen 10 hours 40 min ago. Offline
Joined: 9 May 2011

Thanks for the clarification. If I had my client "bake in" the images in the background in the "safe area", won't the size of the borders look larger/smaller relative to the various device sizes?

Another reason I want to get away from this approach is because I don't want director disposing/creating a full size background image on every screen change.

rakoonic
User offline. Last seen 11 hours 39 min ago. Offline
Joined: 20 Mar 2011

Regarding letterbox scaling - if you move stuff in and out of the area you define and there are borders, you may not want them to be visible. A quick hack I did to hide this is a function located here:

You call it (passing a { r=, g=, b= } table should you wish to set hte colour) and it will return either false (which means no borders were needed) or a display group containing bars that block the area you wouldn't normally see.

http://pastebin.com/w2x90vUT

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

So for a all around iOS and Android build, the aspect ratio of 360 x 570 is correct? I read on the old "Content Scaling Made Easy" post to do 380 x 570. Which do you guys suggest?

http://www.coronalabs.com/blog/2010/11/20/content-scaling-made-easy/

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

If you follow the instructions on this post 360x570 is all that is needed. If you make your images 380x570 you will never see those extra pixels in any device available today. There's no harm in using it, it's just wasted work.

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

Ok thank you for the reply, just trying to wrap my head around this for my new app i'm working on. So if I am only wanting to really do image resolutions for iphone 4 and above.. would you think that doing a set of 720x1140(for iphone 4 and ipad) and 1440x2280 (for ipad 3) would be good?

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

If you don't plan on supporting 16:9 or 16:10 resolutions you can make your images 360x480 or multiples of that. That's all that's needed for all the current iOS devices available. Note that the rumors say the next iPhone will have a 16:9 aspect ratio so if you plan on supporting it you should use the recommended image sizes. The benefit of that is that you will gain almost automatic Android support. If you only plan to support high resolution devices you can do as you say and make the base resolution 720x1140.

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

Ok, so I DO want to support 16:9 resolutions. My app is landscape so lets say I do 1140x720, what I don't understand is that according to an aspect ratio calculator, that is a 19:12 aspect ratio. Is that the same ultimately as 16:9?

http://andrew.hedges.name/experiments/aspect_ratio/

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

Don't worry about calculating exact aspect ratios. There is no need, but if you do it's best to use the division result to visualize the aspect ratio e.g. 16:9 = 1.77777, 4:3 = 1.3333. The great thing about this technique is that you will never see black bars no matter what the actual aspect ratio of the device is. One very important part of this is that you MUST use 480x320 (or multiples of it) as the display with and height in your config.lua. When I have time I'll make a detailed blog post explaining exactly what's going on.

PS: There are actually some limitations on what aspect ratios are supported with the recommended 1140x720 resolution, but anything whose aspect ratio is between 1.333 and 1.78 will work perfectly.

PS2: You never see the whole (fullscreen background) image on any device available today so calculating the image's aspect ratio won't do anything for you. On devices with wider screens you won't see the bottom and top parts of the images, and on devices with shorter screens (3:2, 4:3) you won't see the sides of the image.

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

Ok I think I understand, I am just having hard time deciding the resolutions of my images that I should do. I am creating a storybook app, so the majority of the images are images that will cover the entire screen all the time. Isn't there a way to do this so that only the sides of the image gets cut off depending on the device? (Rather than what you said in PS2 about how sometimes the top and bottom might get cut off, other times the sides might)

So according to what you are saying, if I want to support all devices, then I will need some "bleed out" areas both on the sides of my image and on the top and bottom as well?

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

You understood correctly. There is no way around the fact that you need to fill all the bleed out areas with non-important parts of the image. Don't worry that you won't lose all that much although it may seem like it judging by the numbers. Just setup a basic work image with some guides so you can visualize your safe area. If you're using 720x1140 that means 40 pixels both on top and on the bottom and 90 pixels on the sides.
Your other option to make sure that there is no bleed area is making sets of images for different screen aspect ratios and all the associated code, but that would mean a lot of work, not to mention the maintenance work would also increase exponentially. If you find a better solution let me know because I would really like to see it :)

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

I see, I think it finally clicked in my head. Just curious, does corona even support the older iphones now? Just wondering if I really should consider creating images for a really low resolution such as 480x320? Seems like hardly anyone has the older iphones now... Would 1140x720 run well on the iphone 4? or should i try to get a resolution that is more exact to what it displays?

EDIT: haha sorry I just realized.... its exactly what you said. 90 from each side and 40 from top and bottom would put 1140x720 at 960x640... BING!

PS: Although I want the app to ultimately be for iOS and Android. For the iOS build only, couldn't I then export all my images from illustrator at 960x640? (leaving behind the bleed area) and for the Android build I would use the full 1140x720?

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

;) Great! It's much easier to visualize once you set it up!

I think you may have a point with the older iPhones. Right now the only one supported is the 3GS (and iPod touch 3G maybe?), but it won't be upgraded to iOS 6, so the last supported version will be 5.1.1, although Corona itself supports down to 4.3. The low resolution images don't add all that much to the final package size, but it all depends on how much potential customers you are willing to lose. If you find that the number of active 3GS devices is low enough to not worry you then go for it.

Answer to PS: No because you would lose iPad and (possibly) next iPhone support.

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

Ah thats right... Sorry to take so much of your time, you have been of great help! Now to get to work, I for sure have a 'better' understanding of this now. Might be worth while for someone to create a sample project that has the correct config as well as correct example code with correctly sized image files. Maybe I will do that if I can get this figured out tonight...

@RSCdev
User offline. Last seen 1 year 32 weeks ago. Offline
Joined: 6 Sep 2011

@rxmarccall - If you do the "sample" you said above, I will say WOW for you! :)

PS: Sincerely that would be of so much help (for me and others here in the community for sure).

Thanks anyway!

Cheers,
Rodrigo.

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

Alright so I finally started to get his figured out, I made a quick demo app for anyone that is interested, it is extremely simple but it at least shows how it should be setup and includes some demo images to help you understand what corona is doing. Here is a download link:

https://www.dropbox.com/s/mmlfxont1uo5oqj/UniversalBuildSkeleton.zip

I was going to add it to GitHub, but I couldn't figure out how to set it up... I'm a noob with it.
Let me know if thats helpful at all.

@RSCdev
User offline. Last seen 1 year 32 weeks ago. Offline
Joined: 6 Sep 2011

@rxmarccall,

Hey mate, a word for you: WOW!

I highly appreciate your effort and sure your time on making this sample code real! ;)

PS: What a nice community we have here isn`t it? Look the team: @CluelessIdeas first wrote an amazing Forum Post about the "Letterbox Scalling" and @rxmarccall after brainstorming at it, just built an great sample code for all of us - The CoronaSDK Community - understand it even better e use it widely!

+1 for you guys!

Cheers,
Rodrigo.

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

No problem, it took me just a few minutes to put together. Yea the Corona community is a good one, there has always been helpful people around since day one for me.

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

Perfect. That's exactly it.

As a small optimization you might try to squash or resize your images to the nearest power of two dimensions after exporting them to png or jpg. Usually doesn't impact image quality all that much and could save a lot of ram. Since you're using newImageRect they will be expanded to fill the rect dimensions. This is most effective on images that are less important like a background that is covered in some areas by other images.

Example:
resize 570x360 to 512x360 - will save 256KB of texture memory (1MB on @2 images, 4MB on @4)

saravanan.vbe
User offline. Last seen 16 weeks 2 days ago. Offline
Joined: 16 Sep 2011

hi
 i creaded app in corona for iphone in that app i worte  some like that

1
2
3
4
5
imageSuffix =
                                {
                                        ["-x2"] = 2,
                                        ["-x4"] = 4,--ipad3
                                }

 for dynamic image Resulation and like that i want to know what procedure for android build the same project and i want know one more thing that is we mention any premission in build.settings file any thing for android did u explain to me

saravanan.vbe
User offline. Last seen 16 weeks 2 days ago. Offline
Joined: 16 Sep 2011

hi peach pellen
 i creaded app in corona for iphone in that app i worte  some like that

1
2
3
4
5
imageSuffix =
                                {
                                        ["-x2"] = 2,
                                        ["-x4"] = 4,--ipad3
                                }

 for dynamic image Resulation and like that i want to know what procedure for android build the same project and i want know one more thing that is we mention any premission in build.settings file any thing for android did u explain to me

peach pellen
User offline. Last seen 1 year 35 weeks ago. Offline
Alumni
Joined: 12 Apr 2011

You should post about this in the Android sub forum, this thread is about understanding letterbox scaling.

There is a blog post about suffixes and sizes too.

You shouldn't need to add any permissions to build.settings for Android.

dkmac79
User offline. Last seen 1 year 47 weeks ago. Offline
Joined: 10 Dec 2010

this is interesting but a bit outdated?

has anyone an update for this including the new high res devices like galaxy s3, galaxy nexus, ipad(3) etc.

chris.l.frederick
User offline. Last seen 44 weeks 3 days ago. Offline
Joined: 14 May 2011

I am using this setup see a strange bug(?) in the simulator on landscape oriented projects; pick a device like the droid or kindle, then attempt to "tap" on an object to trigger an event. When the object is located in the "non-safe" zone on the right hand side the event won't fire. Seems to work on the left non-safe side...

config.lua

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
application =
        {
                content =
                {
                        --zoom
                        width =  320,
                        height = 480,
                        scale = "letterbox",
                        xAlign = "center",
                        yAlign = "center",
                        fps = 60,
                        imageSuffix = {
                                ["@2x"] = 1.5, 
                        }
                },
        }       

build.settings

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
settings = {
        orientation = {
                default = "landscapeRight", 
                supported = { "landscapeRight","landscapeLeft", "landscape"},
        },
 
        iphone =
        {
                plist =
                {
                CFBundleIconFile = "Icon.png",
                CFBundleIconFiles = {
                   "Icon.png", 
                   "Icon@2x.png", 
                   "Icon-72.png", 
                },
                },
        }
}

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

@dkmac79 It isn't outdated. The fundamental principle of this approach will never be outdated unless something changes in Corona in regards to content scaling. If you aren't going to develop for lower resolution devices you can change the base resolution specified in config.lua if you want, as long as you understand how and why change it.

@chris.l.frederick You are correct and it appears to be a bug. AFAIK this has been present for a very long time. I still haven't investigated fully if it's possible to develop a workaround because I usually don't need to catch touch events in the affected area.

dkmac79
User offline. Last seen 1 year 47 weeks ago. Offline
Joined: 10 Dec 2010

of course the principle is not "wrong" just wanted to know if someone has an update that includes newly introduced devices.

for example i have difficulty to get 1280res devices into the equation because the base size of the would then be 640*380 which is a lot bigger than 480*320 and there fore worries me a bit that the sd devices have to load a lot bigger textures than their screen size and the correlated memory usage.. especially since those SD devices usually come with lower ram amounts than newer devices

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

If you want to target mainly 16:9 devices with a display width of 1280 then you have to change the base resolution to an appropriate value, but I'm assuming by your questions that you still don't fully understand what's going on here. You don't need to change anything to support newer higher resolution devices unless these devices are your main target for development in detriment of other devices. You always have to make a choice of what will be your central device resolution and aspect ratio, and that's why the standard 3:2 aspect ratio of the iPhone was chosen. First it sits right in the middle of the other more common aspect ratios (4:3 and 16:9 or 10, or whereabouts) and second it is a very popular aspect ratio. You really have to forget about resolutions and start thinking in terms of aspect ratios. It appears that you are mixing content scaling and dynamic image resolution which is achieved by having different assets for different content scales (the @2 suffix stuff).
rxmarccall did a great job deconstructing all of this and creating a working example to start developing from. See his comments above.

dkmac79
User offline. Last seen 1 year 47 weeks ago. Offline
Joined: 10 Dec 2010

i fully understand the principle.. and of course i am mixing scaling and dynamic image resolution because you surely won't want to have an sd bg full blown (put perfectly scaled) onto the ipad3.. because that would look horrible..

so its a mix between the principle of letterbox scaling in sync with offering the best texture sets for each "resolution" range

since you want to reach optimal image quality for as much devices as possible.. from sd iphone, to retina iphone over to similar resoluted android devices over to high-res retina like 1280 devices over to the ipad3 with its extremely high resolution..

and its not as trivial as it sounds to get the optimal solution here, because scaling an item only based on resolution ignores the size of the screen and therefore the actual dpi used.. which can easily lead to micro "button" or huge "buttons" or game elements or whatever you use..

especially considering all the rumors that the iphone 5 might be a 16:9 device (which would very well in most uikit based app) its not that easy..

of course this is also heavily dependent of the game.. knifflig :)

since you don't want to scale your sd assets up to the full hd and beyond.. you would want to have texture sets who take over at certain resolutions/ content scales to offer the best image quality

rxmarccall
User offline. Last seen 6 weeks 1 day ago. Offline
Joined: 18 Jan 2011

@dkmac79
You will not see "micro" or "huge" buttons when trying to support device resolutions across the board. When you create an image with "display.newImageRect", you set the width and height of the image to be displayed. No matter what size the true resolution is of the image file in your project directory, it will be forced to display at the width and height you specify with "display.newImageRect". Have you read this blog post really well? http://www.coronalabs.com/blog/2010/11/20/content-scaling-made-easy/

dkmac79
User offline. Last seen 1 year 47 weeks ago. Offline
Joined: 10 Dec 2010

of course the dpi of the screen plays a vital role how "big" an actual pixel is and therefore how big an image is shown.. for example a button..

an tablet with a resolution of 1280*800 and a phone with the same resolution would load the same assets and use the same scaling factor which therefore would end up with either small or huge buttons , elements etc.

not?

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

Correct. This has been asked before and I think it's a known feature request. So far the only way of knowing the actual screen size of a device is with a table of devices with the required information. I have a table with some of the more important ones, but of course it isn't as accurate as having that information being read from the actual device. I have a lot more devices to add to that list but I haven't had the time to do it.

Here are some resources related to the issue you mention:
http://developer.coronalabs.com/code/device-metrics-scaling-based-screen-size
http://developer.coronalabs.com/code/android-screen-sizes-and-names-list
https://github.com/cluelessideas/Android-devices-list

chris.l.frederick
User offline. Last seen 44 weeks 3 days ago. Offline
Joined: 14 May 2011

@CluelessIdeas
Thanks for confirming I'm not crazy. It is a pretty frustrating bug. I'm hoping it does not occur on the actual device, but I'm not optimistic. I do use all the touch surface I can get in several of my apps...

@Ansca / Peach is there anything we can do to help get this issue fixed? Maybe some sample code that reproduces the issue?

RicardoGraca
User offline. Last seen 3 weeks 2 days ago. Offline
Joined: 17 May 2011

It happens on the actual device. Funny thing is that all other directions work fine.

Viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.