Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Understanding Letterbox Scalling
Started by RicardoGraca Mar 12 2012 03:03 AM

- - - - -
91 replies to this topic
[TOPIC CONTROLS]
« Page 4 of 4 2 3 4
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#76

Tim @ Playful Media

[GLOBAL: userInfoPane.html]
Tim @ Playful Media
  • Observer

  • 21 posts
  • Corona SDK

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.



[TOPIC: post.html]
#77

nicholasclayg

[GLOBAL: userInfoPane.html]
nicholasclayg
  • Contributor

  • 452 posts
  • Corona SDK

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.



[TOPIC: post.html]
#78

walkerjohn723

[GLOBAL: userInfoPane.html]
walkerjohn723
  • Enthusiast

  • 33 posts
  • Corona SDK

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.



[TOPIC: post.html]
#79

walkerjohn723

[GLOBAL: userInfoPane.html]
walkerjohn723
  • Enthusiast

  • 33 posts
  • Corona SDK

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.



[TOPIC: post.html]
#80

davebollinger

[GLOBAL: userInfoPane.html]
davebollinger
  • Corona Geek

  • 1,276 posts
  • Enterprise

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

 



[TOPIC: post.html]
#81

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,126 posts
  • Corona SDK

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.



[TOPIC: post.html]
#82

davebollinger

[GLOBAL: userInfoPane.html]
davebollinger
  • Corona Geek

  • 1,276 posts
  • Enterprise

 

Actually we recommend using a 360 x 570 base image ... It's simply what that math works out to.

 

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.



[TOPIC: post.html]
#83

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,126 posts
  • Corona SDK

That's one of the reasons we did an update to the Ultimate config.lua post where we actually calculate the content area to be perfect for the device, but for creating backgrounds you still have to figure out what those numbers work out too.  And you're right, in some cases (I think it was a Samsung S2) the device might have a soft button bar that comes out of the specified screen ratio.  The device was a 16:9, but the firm ware reported something like 1.8666:1 because they took the softbar out of their screen area and I had to redo some of the app's backgrounds to cover that oddness.

 

Rob



[TOPIC: post.html]
#84

gritob

[GLOBAL: userInfoPane.html]
gritob
  • Observer

  • 7 posts
  • Corona SDK

so you are talking about the 320x480 (2:3) sized virtual screen inside a much bigger real display (lets take a 16:9 for example). with this technique i will be able to "fill" the black borders with a big proper background image. if i want to put an image in the top left corner of the display (16:9) and another one in the bottom right corner. is there a possibility to add touchlisteners to these images or is this not possible because the images are outside the virtual screen?



[TOPIC: post.html]
#85

davebollinger

[GLOBAL: userInfoPane.html]
davebollinger
  • Corona Geek

  • 1,276 posts
  • Enterprise

you have access to the entire screen no matter how you do it -- for positioning display objects, creating touch listeners, whatever.  the only thing that changes is the total *range* of your content coordinates (that is, you can still "think" in terms of 320x480, ignoring actual device pixel resolution, though it may actually be something like 320x568 once extended to letterbox aspect in your 16:9 example, and your y values might range from -74..394 if center-aligned as opposed to top-aligned - your "zero/origin" still occurs at the top-left of your 320x480 content box, wherever you have that aligned)

 

whether you use 320x480 or some other size for your "native" content doesn't really matter, the rest of the aspect math works out similarly.   those are just the coordinates you've chosen to prefer as your "@1x" resolution.  (sure, there are *other* considerations like image file sizes and texture size limits that you might want to think about when choosing a content size, but they don't affect the aspect math itself) 



[TOPIC: post.html]
#86

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,126 posts
  • Corona SDK

Think of it this way... You can define a 1.5:1 area that's centered in the screen (i.e. 320x480) and understand that you may have some items positioned at negative values (since 0,0 isn't at guaranteed to be at the top left and something will be positioned greater than 320 and 480.  Or the Ultimate config.lua makes sure 0,0 is the top left and display.contentWidth, display.contentHeight is the bottom right.

 

Rob



[TOPIC: post.html]
#87

jesseikaur

[GLOBAL: userInfoPane.html]
jesseikaur
  • Observer

  • 3 posts
  • Corona SDK

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.
 

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:

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:

application = {
    content = {
        width = 320,
        height = 480,
        scale = "letterbox",
        xAlign = "center",
        yAlign = "center",
    }
}
Instantiation of images for backgrounds:
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
uid: 61899 topic_id: 23200 reply_id: 323200

 

 Thank you for sharing how to scale apps by device and operating system. 



[TOPIC: post.html]
#88

anaqim

[GLOBAL: userInfoPane.html]
anaqim
  • Contributor

  • 666 posts
  • Corona SDK

The post is too long for me to read through so please excuse if this has been said already, but my approach (in 2016-2017) where devices are more and more powerful, is to define a single resolution, work with that and let devices scale it.

 

To fit practically all iOS and Android devices, the app has to support aspect ratios from 1,777777 to 1,333333 (16:9 and 4:3).

 

So if I want to make a HD app it goes like this (but it translates to all resolutions):

 

Full app resolution (typically a background image) = 1280x810 pixels

Design the game around the centered 1080x720 pixels area

 

So the game area 1080x720 has an aspect of 1,5

If a device has a wider aspect, it will expand the width up to 1280 giving the maximum aspect of 1,77777

If a device (mostly ipads) has a more narrow aspect, it will expand the hegith up to 810 giving the mimum aspect of 1,33333

 

Draw these numbers in a drawing program and it will all make sense.

 

I also love not having to deal with different graphic element version (@2 etc).

 

I test all on what I consider be a lower end device and thats it.

If customers have lesser devices than that, please upgrade, we cant progam legacy compatibility forever.

 

Cheers!

Anaqim

 

 

Edit! How to calculate this.

 

Decide the width you want to support, usually for a 16:9 device. Lets use 1920 for this example.

1920/1.777777 = 1080 sets the (16:9) resolution at 1920x1080

1080*1.5 = 1620 which set the safe area (game area, always visible area) to 1620x1080

1620/1.333333 = 1215 which sets the (4:3) resolution at 1620x1215

 

There you have it :)



[TOPIC: post.html]
#89

elifares

[GLOBAL: userInfoPane.html]
elifares
  • Enthusiast

  • 80 posts
  • Corona SDK

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.

 

 

I thought zoomEven is the scale setting that would make sure the entire device screen is covered and have some bleeding. Doesn't letterBox make the entire content area reside on the screen and result in "black bars" on devices?



[TOPIC: post.html]
#90

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,126 posts
  • Corona SDK

Remember when you set the width and height in config.lua, you're defining your own region on a virtual screen.  It can be 10 points wide by 100000 points high if that works for you.  Most people maintain a 1.5:1 aspect ratio, and for reasons that Apple and Google still perpetuate, we still recommend a width of 320 x 480.

 

Obviously this "fits" almost no screen today.  The Samsung S8 decided that 16:9 wasn't a good size and went to 2:1 and Apple one-upped them with the iPhone X's insanely tall 2.185:1.  Tablets still tend to remain more square shape, with the iPads at the most extreme 4:3.

 

Keep in mind, display.contentWidth is the value "You" put in config.lua. The same with display.contentHeight.

 

With a 320x480 content, Corona will map your content area when using "letterbox" so that the 320 width fits the device's actual width. (since config.lua is always discussed in portrait mode, I will too).  Therefore if you decided that your width is 320, then display.actualContentWidth will be 320  ** unless the aspect ratio is more square **.  In the case of the iPad, the height is the value that will be used to scale the screen.  The result is on phones, you have "extra space" above and below the content area (assuming you centered it).  On tablets you have extra space on the sides.

 

From API call terms, display.actualContentWidth and display.actualContentHeight will give you your number of points that your scaled screen represents.  It's your responsibility to fill in this extra space and we've more than once published suggestions on how to do this.

 

In the case of zoomEven, the content area is stretched even more to make sure the side that the full screen is filled while cutting off more of the background.  Still if you make your background big enough and use letterbox, then you won't have "bars".

 

Rob


  • elifares likes this

[TOPIC: post.html]
#91

wpaul645

[GLOBAL: userInfoPane.html]
wpaul645
  • Observer

  • 1 posts
  • Corona SDK

Best forum discussion for gaining knowledge.



[TOPIC: post.html]
#92

hammadazam008

[GLOBAL: userInfoPane.html]
hammadazam008
  • Observer

  • 1 posts
  • Corona SDK

On the off chance that you don't anticipate supporting 16:9 or 16:10 goals you can make your pictures 360x480 or products of that. That is everything that is required for all the present gamesmodapk.info and  iOS gadgets accessible. Note that the bits of gossip says the following iPhone will have a 16:9 perspective proportion so in the event that you plan on supporting it you should utilize the suggested picture sizes. The advantage of that will be that you will pick up relatively programmed Android bolster. In the event that you just an arrangement to help high goals gadgets, you can do as you say and make the base goals 720x1140.




[topic_controls]
« Page 4 of 4 2 3 4
 
[/topic_controls]