Is there a way to get the true screen dimensions of the device when you're using content scaling? Like I'm trying to get the unscaled dimensions, not the dimensions I set it to in the config.

Any help is greatly appreciated.

Let me just add one more thing about specifically what I'm trying to accomplish. I'm using zoomStretch as my scaling mode. This looks fine in most cases. But I have one object in my game, which is a round ball, and on devices like the Droid it looks a little out of proportion because of the scaling from the iPhone dimensions. So I wanted to use the true dimensions of the screen to get a ratio of how much to change the xScale of the ball so it is back in proportion. I'm hoping there's a way to get this true screen size measurement so I can do this...

Are you asking about display.stageWidth and display.stageHeight ?

Nope, as far as I know and my tests have shown, those yield the same values as contentWidth or contentHeight and viewableContentWidth/height. All of them are just giving the virtual screen values.

There is no way to get those information as far as I know. I requested this functionality at different places already.

You could use the letterbox scaling for keeping the aspect ratio. That will work fine...

Centering the letterboxed screen was another feature request I posted some time ago. The whole scaling stuff is another "half finished" (cheesy) feature which is practical useless for real applications in its current implementation.

Alright, thanks man. I think what I'm going to do is just use the letterbox like you said and upscale backgrounds to get rid of the black. That way you won't really be able to tell and all the important stuff should still be in proportion!

@DFox, Can you post/send me an example of the problem you are seeing? The goal is you should not have to worry about the actual screen dimensions of the device. This may be a bug that needs to be addressed. You can post the code here or email me a demo project: tom at anscamobile.com

Thanks,
-Tom

Hey Tom,

Thanks for the response, but I don't think this is a bug. It's just that none of the content scaling modes did exactly what I needed. I'll try to explain.

On iPhone/iPad any of the content scaling modes work perfectly because everything is the same ratio. So even if you use zoomStretch, nothing will ever be distorted. But when you use something like zoomStretch for Android, you have devices like the Droid where the resolution is 854×480, so stuff like circles will appear distorted if you use zoomStretch.

So my first idea to combat this was to compensate for this effect by using the actual size of the screen (854x480) to resize stuff like circles to compensate for the zoomStretch. But this can't be done because Corona doesn't allow you to get that 854x480, because you can only get the virtual screen size created by the zoomStretch which is the standard iPhone size, so you never actually know how much to compensate for. You can't even actually tell programmatically that it is being distorted.

So in the end, the only way I was able to solve this was for my Android builds to go with letterbox mode. Then I expand all backgrounds to cover any of the black area created by the letterbox. Since you can't get the actual screen size, I had to upscale the background to fit the Droid since I think that has the tallest screen. This pretty much works fine for my scenario.

But this problem could easily be solved if Corona just allowed you to get the actual screen size in addition to the virtual screen size created by the content scaling.

Please let me know if you have any questions or still think this is a bug, but I think right now this is just a missing feature.

@Tom I second what DFox said!

You may additional read:

http://developer.anscamobile.com/forum/2010/06/19/dynamic-content-scaling-centering

http://developer.anscamobile.com/forum/2010/07/03/letterbox-scaling-allows-content-overflow-screen

Basically: To control the output in a scaled version one needs to know the screen dimensions in all but the very simples cases.

Agreed that we need a feature to look up the actual screen dimensions (but for this to be useful, it should return the values IN the base coordinate system). We are currently working on the APIs in this area.

I personally don't use "zoomStretch" much, since even the iPhone and iPad have two different aspect ratios. (The iPhone is nearly 14:9, the iPad is 4:3). I'd generally recommend "letterbox" scaling and then adding extra non-essential graphics in the "bleed" area, which is how we used to handle Flash Lite development for multiple phones.

Thanks for the info, that's awesome, those APIs will be extremely useful.

I actually wasn't aware that the iPad had a different ratio, but even when using zoomStretch, everything I've seen so far has looked really good on the iPad too since it's pretty close, even circles. But I'll keep that in mind about using the letterbox for iPhone too, like I did for Android.

I've been struggling with a related issue. It's a little depressing that this has been going on for well over a year and there still isn't really enough screen metrics to actually manage the screen when using a content scaling approach.

In my case, I have a 320x480 virtual screen, and all of the action takes place there. But I have some "extra" screen on the left and right in most Android platforms, as they have "wider than iPhone" aspect ratios. My problem is that I really need to know how much extra screen I have (in each dimension) in order to make sure I'm properly filling the background. You would think you might be able to use the viewable content metrics, but those don't work in letterbox (the only useful scaling mode as far as I can tell). You could try to use the screen origin metrics, which work *IF* the scaled screen is centered (which it might or might not be).

I guess if the viewable content metrics just worked properly, that would do it (those would then describe the area that you needed to manage, which I gather was the whole idea of those properties).

There is reference in the docs to a known bug with viewable content metrics when using letterbox scaling. I looked through the bug database (man, that search function was horrible), but I didn't actually see any such bug.

As far as I can tell, if you actually want to even *know* the true aspect ratio, or event the visible screen area, the only way to do it is to not use content scaling. This really seems like an easy problem to fix, and I'm surprised more people haven't complained. I guess people just pick some amount of fudge factor and live with it.