One Size Fits All? (Stage size for best display on iOS and Android)

[mrwizzer2]

I'm beating my head against the wall trying to find the one proper stage size that will accommodate all iOS devices and all Android devices adequately.

I've been following Colin Holgate's informative posts and am using the   stage.scaleMode = StageScaleMode.NO_BORDER;  approach.

However, I'm not sure what I should be setting the dimensions of my stage to, as the suggestions I found of Colin's seem to be prior to the release of iPhone 5 and the iPad retina display.

Can anyone recommend a stage size that would work best in trying to accommodate the wide variety of devices out there?

Many thanks in advance!

Mike

[Colin Holgate]

When using no_border I set the stage to a ratio of 14:9, so for example 1680x1080. Your entire content fills that stage, and iPhone 5 users see the middle 16:9 part, and iPad users see the middle 4:3 part. So, iPhone 5 users miss a bit of the top and bottom, and iPad users miss the left and right. You would just make sure that the import stuff was not too close to the edges.

If you try this app I made:

https://itunes.apple.com/us/app/milkshake-mayhem/id556962979?mt=8

on iPhone 5 and iPad, you’ll see how extra parts of the scene become visible.

The other way to work is show_all. For that I use a 16:9 stage and have extra content off the top and bottom of the stage, or I use 4:3 stage, and have extra content off the left and right. That extra content then gets revealed on wider or taller devices.

Here’s an example of a 4:3 app that has extra stuff to the left and right of the stage:

https://itunes.apple.com/us/app/meet-heckerty-funny-interactive/id514220257?mt=8

and here’s a 16:9 app that has extra content above and below the stage:

https://itunes.apple.com/us/app/thomas-friends-lift-haul-collection/id641291615?mt=8

The first two apps are free, that last one is $1.99.

[12345abcdefghi]

Try

stage.scaleMode = StageScaleMode.EXACT_FIT

If your stage size is 480x320 and it is being displayed on an ipad 1 res it will appear slightly taller than it is wide. There are other more elegant ways to do this but nothing simpler.

[Colin Holgate]

That approach will end up distorting all of the content, and changing from a 16:9 to a 4:3 will be very noticeable. Even changing from 14:9 to 4:3 isn’t ideal.

But, it still would be interesting to test.

[Mark.fromOP]

I use Colin's approach and set my stage to 1024 x 600, so far this has worked wonderfully even on HD displays like iPad 4th gen.

[xTLS]

I take it you have considered programming a dynamic interface and decided against it? I've worked on a few cross-platform apps and used the resize and orientation events to arrange the contents to fit the current screen dimensions. I've found it is a lot of fun to make a fluid layout and not overly difficult if you start the project with that in mind, but of course the feasability depends on the app

[Colin Holgate]

A lot of what we do involves graphical scenes, and character animations. In some cases I do move elements around with code, to make them hug the edge of the screen the app is running on. But I can still use the advantages of show_all for all other aspects in the app.

Here’s one recent app, which has an update waiting for review at the moment:

https://itunes.apple.com/us/app/thomas-friends-lift-haul-collection/id641291615?ls=1&mt=8

Here’s a new app, waiting for review, which hopefully will be live in a few days:

https://itunes.apple.com/us/app/thomas-friends-lift-haul-collection/id 666984904?ls=1&mt=8

Both of those use show_all. This one uses no_border:

https://itunes.apple.com/us/app/milkshake-mayhem/id556962979?mt=8

You don’t need to buy the apps to see the difference, just look at the sample screenshots, and compare the iPad and iPhone 5 ones.

[mrwizzer2]

Thanks Colin, and everyone, for your suggestions.

The problem I'm running into when exploring your advice is that our layout is a more standard type of layout with a defined top and bottom, (namely, a banner with navigation buttons at the top and another banner at the bottom).

Colin, your samples don't seem to involve these kind of "picture frame" type of layout restrictions, they appear to be more free form on the stage.

I've experimented with setting the placement of the top and bottom elements dynamically, but everything I've tried seems to provide it's own problems, elements being cut off in one direction or the other, for example.

My best results so far seem to derive from having a stage size of 640x960 and NOT setting any kind of stage.scaleMode.  This way, on both the iPhone 5 and the iPad, the layout seems to work nicely, with the one caveat that there's some letterboxing going on on the iPhone 5, (black bars at top and bottom). 

Also, I didn't notice anyone mentioning the need for a "Default Image" named "Default-568h@2x.png".   I've found that's the only way to get the iPhone 5 to display full screen without the letterbox at top and bottom.  Is there a different method to achieve this, or is it just taken for granted that that's a requirement?

[Colin Holgate]

The letter boxing on iPhone is only cured by including the Default-568h@2x.png splash screen, and since May 1st you are required to support the full height or width of the iPhone 5.

If you look at the Thomas app you’ll see that there is a + button in the upper right of the screen. It’s in the upper right for all screen sizes, and I use some simple arithmetic to move it into the right place. Here’s how those lines look:

import flash.system.Capabilities;

private var screenwidth:int = Math.max(Capabilities.screenResolutionX,Capabilities.screenResolutionY);

private var screenheight:int = Math.min(Capabilities.screenResolutionX,Capabilities.screenResolutionY);

var btny:Number = stage.stageWidth * screenheight / screenwidth

menubtn.y = (stage.stageHeight/2-btny/2);

In my case I have landscape apps, if you’re doing portrait then you would reverse the min and max lines above.

By the way, this is for use with show_all, which is also the default behavior. So, your app where you don’t set the scale mode is already using show_all, and some math like I use would let you place a set of buttons along the top of all screen sizes.

[xTLS]

Maybe I'm missing something here, but isn't this an easier way to place a button in the top right (assuming center point is in top left of button)?

button.x = stage.stageWidth - button.width;

button.y = 0;

edit: I suppose that doesn't apply to show_all. I'm used to using

stage.scaleMode = StageScaleMode.NO_SCALE;

stage.align = StageAlign.TOP_LEFT;

We've done this with banners at the top and bottom. If you design a banner for a specific aspect ratio, you can do something like

banner.width = stage.stageWidth;

banner.scaleY = banner.scaleX;

This causes the banner to fill the width of the screen and change height proportionately. If you want to have more control over the elements in the banner, something like

banner.background.width = stage.stageWidth;

var newHeight:int = stage.stageHeight / 8;

banner.background.height = stage.stageHeight / 8;

banner.buttonBack.height = newHeight;

banner.buttonBack.scaleX = banner.buttonBack.scaleY;

banner.buttonBack.x = banner.buttonBack.y = 0;

banner.title.height = newHeight / 2;

banner.title.scaleX = banner.title.scaleY;

banner.title.x = banner.buttonBack.x + banner.buttonBack.width * 1.2;

banner.title.y = newHeight / 2;

etc

This might not be what you're looking for at all, but I find it works well for resizing.

When asked to convert a fixed-size iPad app to one that dynamically resized for Android devices, we found it infeasible to completely recode the app in the time required, so we mixed dynamic resizing like above with throwing lots of objects into an empty MovieClip and scaling the MovieClip to fit the current stage size. This didn't hurt performance much, even when running graphics designed for the iPad's 2048*1536 retina display on much smaller screens.

[Colin Holgate]

I don’t need to set the x position because that remains the same for all screens. For a show_all landscape app the number of pixels across the screen for a 1024x576 stage (the right ratio for iPhone 5) is 1024, no matter how many pixels are in the video memory. But, the number of pixels of height will vary. For iPhone 5 it stays as 576 tall, but for iPad it’s 768 tall. That means that the button is anchored at a y of -96 on iPad screens.

You can find the halfway point of the visible area by taking the width of the stage and multiplying that by the device’s screen ratio, giving the effective number of pixels tall that device screen is, then divide that number by 2. To find the y value of the top of the stage you would then subtract half the height of the device from half of the original stage height.

Sound complicated, but as you saw it’s only two easy lines of math, and it does work.

Now, if you want to make like a bit easier you can work with a stage size of 1024x768, and have your buttons stuck to the top and bottom of the stage, without needing code to relocate them. Then when the app is run on wider devices you see the content that was off the left and right of the stage. The Heckerty app works that way. It has advantages for some kinds of apps, like a storybook for example, but isn’t right for game scenes like there are in the Thomas app.

[xTLS]

I feel like once you're adjusting the layout that much anyway you might as well use NO_SCALE, but it all comes down to preference and the project.

[Colin Holgate]

I’m only setting the location of one button. All of the rest of the scaling is handled by Flash, and although I could use no scale and movieclips, that I then size based on the device it’s running on, in the very best case I would end up exactly where I am by letting Flash do all of that for me.

[Mark.fromOP]

Colin your bit of code really helped me out on a project I am working on. Genius. Thank you for sharing your knowledge.

private var screenwidth:int = Math.max(Capabilities.screenResolutionX,Capabilities.screenResolutionY);

private var screenheight:int = Math.min(Capabilities.screenResolutionX,Capabilities.screenResolutionY);

[Colin Holgate]

Yes, the interesting part is that the capabilities width value is based on Portrait, even if your app is Landscape. But I wouldn’t bet that it’s based on Portrait for all Android devices. So, using min and max to figure out what the real width is comes in handy.

[Colin Holgate]

BTW, I see that in the forum the screenResoultionY has a space before the Y. That shouldn't be there, it's just a forum formatting glitch.