And just to be clear: Are you talking about the Corona SDK Simulator or the Xcode iOS Simulator?
Rob
Yes, it is happening on both the simulator and the actual devices with the home button/power button screenshot.
And when I say simulator, I mean the Xcode simulator. If screen shots are possible with the Corona simulator, I didn’t know it …
Hi @cjanis,
Can you post one of the direct “device screenshots” (not Xcode simulator) so I can see the degree of this issue and compare it to what I’ve tested so far? Please use the JungleScene project as a test.
Thanks,
Brent
Hi @cjanis,
Sorry for the delayed response. I did some careful investigation/testing of this and came up with the following:
I verified that there is 1px of black on the sides of the JungleScene sample (landscape mode) on iPhone6. I believe this is caused by the content scaling between the virtual 320x480 screen and that of the iPhone6+ (750x1334) or iPhone6 (640x1136). The iPhone6 pixels content scaling is not an even number and since you can’t position images in fractions of a pixel, you either leave a one pixel empty row/column in one dimension or you fill the screen completely by making one pixel row/column offscreen. Since the mode is “zoomEven”, Corona is preserving the content on the screen, leaving a one pixel gap. The other way to do it would be “letterbox” mode (my personal preference) using a background that extends past the letterbox content area.
To go into further detail, pixels are (obviously) whole numbers. If the ratio between a virtual screen (320x480) and a real one turns out to have a fractional content ratio that results in resizing an image to a fractional size (e.g., 230.3333) or having to position it to a fractional location (e.g., 24.512), how would a developer position it so it’s accurate to an exact pixel boundary? You can only be accurate plus or minus one pixel. In my testing, “zoomEven” will drop the fractional part so that everything fits within the screen boundaries. In contrast, if that mode did the opposite, e.g. “rounded up”, developers would be faced with the issue of losing one pixel of their image offscreen.
Basically, this is an inherent but minor limitation that can’t be overcome “by itself,” but it’s easily solved by positioning objects slightly differently, using “letterbox” mode, using a slightly larger background image, or various other approaches.
Hope this helps,
Brent
Thanks for the explanation. It’s good to know that I can work around it, but my understanding was that zoomEven is supposed to fill the entire screen:
“zoomEven” — scales the content area to fill the screen while preserving the same aspect ratio. Some content may “bleed” off the screen edges on devices with aspect ratios that differ from your content aspect ratio.
It sounds like Corona has a minor bug in zoomEven if it’s rounding down instead of up. That’s what would make the most sense logically and per the definition in the documentation, right? Losing that one pixel is to be expected as part of the content “bleed”. It sounds like that should be a pretty easy correction to make in a forthcoming daily build if all that is required is to change the direction of the rounding. Can you confirm if it will be corrected?
Hi @cjanis,
Just to clarify what the documentation says, the potential “bleed” that is referred to by “zoomEven” is the bleed on the axis that is not adjusted to the screen edges… it’s actually the other axis. So if in a landscape app, the horizontal side would not bleed off the left and right edges, but rather the vertical side (might) bleed off the top and bottom.
Basically, this is a “no win” situation which you just need to account for as I outlined. Corona could “round up” but then people would lose 1 pixel, and that may not be acceptable to some developers (in fact, in that case there would be bleed on both axes). There are many ways to account for this behavior, and personally, I prefer “letterbox” mode to “zoomEven”.
Take care,
Brent
“letterbox” = preserves the aspect ratio and keeps all content visible even if it doesn’t fill the screen
“zoomStretch” = fills the screen by ignoring the aspect ratio, can distort the content
“zoomEven” should = preserves the aspect ratio and fills the screen even if some content overflows on one or both axes
As you described it, zoomEven is basically letterbox but only concerned with preserving content visibility on one axis instead of both.
Maybe what we need is a “zoomExtraEven” mode where bleeding is permissible on either axis. Otherwise, we don’t have the option of any kind of non-distortive dynamic scaling that is guaranteed to fill the all the available screen space. Right?
You can always make your background bigger than your screen. Most people using a 320x480 letterbox screen will use a 360x570 pixel background which covers the bleed areas. You can make it even bigger if you’re finding that your device is having a rounding issue as Brent described above.
Rob