Reported pixel resolution for iPhone6 in standard and zoom display views

[DougAEdwards]

Apologies if this post is more appropriate in another forum, but I am a newbie to Corona. I have been experimenting with config.lua content settings - especially that provided by Sergey Lalov (corona SDK Pro Tip #36: SmartPixel config.lua). I don’t understand the reported pixel resolutions.

I modified the test program provided by Sergey to add on-screen printing of display.pixel* and display.Content* as well as the display.actualContent* The program displays 70 point white squares at the top left and bottom right of a frame whose size is defined by display.content*

Here are a summary of my results: (I am comparing the results of the Corona Simulator - version 2016.2830 with the program run on an iPhone 6s running IOS 9.3.1). Note everything seems consistent for iPhone 4 and 5 simulations.

1. using the “standard” config.lua settings (content width/height = 320/480), the program gives the expected appearance with letterboxing. The Corona simulator reports display.content* = 320 x 480, display.actualContent 320 x 569 (rounding error??), and display.pixel* = 750 x 1334. All (almost) as expected.

2. Running on my iPhone 6s in standard display mode (and in the Xcode simulator), display.content* = 320x480, display.actualContent = 320 x 568, BUT display.pixel* = 640 x 1136. Note the discrepancy with the Corona simulator. The white squares appear to be the correct physical size as far as I could measure them on the phone screen.

3. Running on my iPhone 6s in zoomed display mode, display.content* = 320x480, display.actualContent = 320 x 568, BUT display.pixel* = 750 x 1331. The white squares are the same size as in the previous use (as expected).

What is going on with the values of display.pixel* ? The rendered pixel density of a 6s phone in standard view was, I thought, 750 x 1334, but that is what is reported in zoomed display mode. Similarly, the rendered pixel density in zoomed display mode is 640 x 1136, but that is what is reported in standard display mode.

Does the fact that what is reported is the “inverse” of what is expected account for the (correct) result that both images in both standard and zoomed modes are the same size? Of course, as far as I can make out, the pixel density shouldn’t be required by any designer, so perhaps it doesn’t matter.

Now the experiment is repeated using Sergey’s config.lua. This determines an optimum content space - I have no idea how IOS determines this at runtime.

4. Using Sergey’s “SmartPixel” config.lua, In the Corona simulator, there is no letterboxing, the layout fills the screen. The Corona simulator reports display.content* = 375 x 667, display.actualContent 375 x 667 , and display.pixel* = 750 x 1334. All as expected.

5. Running on my iPhone 6s in standard display mode (and in the Xcode simulator), display.content* = 320x568, display.actualContent = 320 x 568, BUT display.pixel* = 640 x 1136. Note the discrepancy with the Corona simulator. The white squares appear to be the correct physical size as far as I could measure them on the phone screen.

6. Running on my iPhone 6s in zoomed display mode, display.content* = 375 x 665, display.actualContent = 375 x 665.5, BUT display.pixel* = 750 x 133 1. The white squares are smaller than in this zoomed mode than in standard display mode, but this is consistent with the reported content size being larger than in the standard display mode. Users however, may be puzzled by features being smaller in zoomed mode than in standard mode.

Questions: 

a) Why is the reported pixel resolution for standard display mode more appropriate for zoomed display mode and vice versa?

B) Why does the content area differ using Sergey’s SmartPixel config.lua between standard display mode and zoomed display mode?

[bjsorrentino]

Hi @DougAEdwards,

Welcome to Corona! This topic can be a little confusing at first, but we’ll try to straighten it out.

To start, can you post the actual “config.lua” code that is yielding different results? Please surround the code with “lua” tags as well, for clarity in the forums:

[lua] -- code [/lua]

Thanks,

Brent

[DougAEdwards]

Brent. Here is the codes requested- taken (with minor additions) from Sergey’s postingTip #36 SmartPixel config.lua 18 Nov 2014.

[lua]

– config.lua

– Author: Lerg - spiralcodestudio.com

– GitHub: https://github.com/Lerg/smartpixel-config-lua

– SmartPixel config.lua

– Uses pixel perfect content scaling when possible

local w, h = display.pixelWidth, display.pixelHeight

local modes = {1, 1.5, 2, 3, 4, 6, 8} – Scaling factors to try

local contentW, contentH = 320, 480   – Minimal size your content can fit in

– Try each mode and find the best one

local _w, _h, _m = w, h, 1

for i = 1, #modes do

    local m = modes[i]

    local lw, lh = w / m, h / m

    if lw < contentW or lh < contentH then

        break

    else

        _w, _h, _m = lw, lh, m

    end

end

– If scaling is not pixel perfect (between 1 and 2) - use letterbox

if _m < 2 then

    local scale = math.max(contentW / w, contentH / h)

    _w, _h = w * scale, h * scale

end

application = {

    content = {

        width = _w,

        height = _h,

        scale = ‘letterbox’,

        fps = 60,

        imageSuffix = {

            [’@2x’] = 1.1,

            [’@4x’] = 2.1,

        }

    }

}

– Uncomment to use the common content scaling

–[[

application = {

    content = {

        width = 320,

        height = 480,

        scale = ‘letterbox’,

        fps = 60,

        imageSuffix = {

            [’@2x’] = 1.1,

            [’@4x’] = 2.1,

        }

    }

}

–]]

[/lua]

main.lua belwo

[lua]

local _W, _H = display.contentWidth, display.contentHeight

local _CX, _CY = _W * 0.5, _H * 0.5

– x = 0, y = 0 - top left corner

– x = _W, y = _H - bottom right corner

display.setStatusBar(display.HiddenStatusBar)

display.setDefault(‘background’, 0.5, 0, 0)

local s = 70 

local frame = display.newRect(_CX, _CY, _W - 2, _H - 2)

frame:setFillColor(0, 1, 1, 0.5)

frame.strokeWidth = 1

local topLeftRect = display.newRect(0, 0, s, s)

topLeftRect.anchorX, topLeftRect.anchorY = 0, 0

local bottomRightRect = display.newRect(_W, _H, s, s)

bottomRightRect.anchorX, bottomRightRect.anchorY = 1, 1

– added by DAE

local ViewableContentSize = display.newText {

    x = _CX, y = _CY -150, fontSize = 14,

    text = 'Viewable Content: ’ … display.viewableContentWidth … ’ x ’

    … display.viewableContentHeight

}

local ConfigContentSize = display.newText {

    x = _CX, y = _CY -125, fontSize = 14,

    text = 'Config Content: ’ … tostring(_W) … ’ x ’ … tostring(_H)

}

– end of DAE edit 

local contentSizeText = display.newText{

    x = _CX, y = _CY - 100,

    fontSize = 14,

    text = 'Content (Actual): ’ … display.actualContentWidth … ’ x ’ … display.actualContentHeight

}

local suffix = display.imageSuffix or ‘none’

local suffixText = display.newText{

    x = _CX, y = _CY - 50,

    fontSize = 14,

    text = 'Suffix: ’ … suffix

}

local scale = display.pixelHeight / display.actualContentHeight

local scaleText = display.newText{

    x = _CX, y = _CY,

    fontSize = 14,

    text = 'Scale: ’ … scale

}

local pixelPerfect = ‘no’

if scale == 3 then

    pixelPerfect = ‘kinda’

elseif scale == 1 or scale % 2 == 0 then

    pixelPerfect = ‘yes’

end

local pixelText = display.newText{

    x = _CX, y = _CY + 50,

    fontSize = 14,

    text = 'Pixel perfect: ’ … pixelPerfect

}

– added by DAE

local screenPixels = display.newText {

    x = _CX , y =_CY + 80, fontSize = 14 ,

    text = ‘ScreenPixels: ’ … display.pixelWidth … ’ x’ … display.pixelHeight

}

print(‘Content’, display.actualContentWidth … ’ x ’ … display.actualContentHeight)

print(‘Suffix’, suffix)

print(‘Scale’, scale)

print(‘Pixel perfect’, pixelPerfect)

[/lua]

[bjsorrentino]

Hi @DougAEdwards,

I must admit, while there are many ways to “tinker” with the config.lua setup, I’m not a supporter of over-complicating this. Some users will set up variable scales, widths, heights, etc. (as it appears this code is doing), but I find it vastly easier to just set up a basic content area width/height like 320x480, using “letterbox” scale (or “zoomEven” if you prefer), then using Corona APIs to work within that content area on every screen aspect ratio.

Basically, when it comes to handling mobile device screen sizes/aspects, it’s already a little challenging by the sheer fact of the hundreds of different devices in the market. Why make your life as a developer more complicated than it needs to be?

Brent

[JonPM]

@bjsorrentino

Basically, when it comes to handling mobile device screen sizes/aspects, it’s already a little challenging by the sheer fact of the hundreds of different devices in the market. Why make your life as a developer more complicated than it needs to be?

Brent

Correction:  *thousands

[DougAEdwards]

Sorry if I didn’t make myself clear.

My query was about the apparent anomalous results returned by display.pixel* for an iPhone 6[s] in standard view and zoomed view modes. The Corona simulator returns what I might have expected, the Xcode simulator and the real device returns what are to me  counter-intuitive results (I haven’t found a way for getting Xcode to simulate a device in zoomed view mode though).

The query was not about Sergey’s SmartPixel config lua - it was just that I was running his code to understand how it works when I came across this anomaly. The major part of my query (contained in points 1 to 3 in my original posting) used a more or less standard configuration file (obtained by uncommenting the last code block in the config.lua file I posted above).

Should I have posed this query in another part of the forum?

[rob]

If you only include a Default-568h@2x.png launcher image, iOS assume your phone is running in iPhone 5 compatibility mode and it returns you values relative to stretching the iPhone 5 screen to fit the iPhone 6’s physical size. The 6’s screen is 117% bigger.  This works out to a 750 x 1331 pixel screen. The actual iPhone 6 screen is just a little bit taller, 750x1334 in size. When that’s scaled down to the 320x content area, (320 / 750 * 1336) you get 569. So the numbers are right and you’re seeing iPhone 5 compatibility mode.

See the guide on build.settings (https://docs.coronalabs.com/guide/distribution/buildSettings/index.html#ios-1) for Launcher image setup for the new phones.

Rob

[DougAEdwards]

Thanks Rob.

I didn’t realise the implications of not specifying a launch image for the different devices - especially as it seemed to work without one.

Any reason why Corona does not generate a table for UILaunchImages in the plist table of the build.settings file?

[rob]

Two reasons.  First, not everyone wants it. We have many Android only developers or people building OS X and Windows desktop apps or even tvOS. We are not going to randomly drop a massive table in build settings until people need it. Secondly, there is an alternate way of using Xcode and it’s Storyboard to generate a file that does launch images instead of using that huge table which some people prefer. See:

https://coronalabs.com/blog/2014/10/21/tutorial-building-multi-screen-launch-images-using-xcode-6/

It’s a bit dated since Xcode 7 came out, but the technique will still work.

Rob

[bjsorrentino]

Hi @DougAEdwards,

Welcome to Corona! This topic can be a little confusing at first, but we’ll try to straighten it out.

To start, can you post the actual “config.lua” code that is yielding different results? Please surround the code with “lua” tags as well, for clarity in the forums:

[lua] -- code [/lua]

Thanks,

Brent

[DougAEdwards]

Brent. Here is the codes requested- taken (with minor additions) from Sergey’s postingTip #36 SmartPixel config.lua 18 Nov 2014.

[lua]

– config.lua

– Author: Lerg - spiralcodestudio.com

– GitHub: https://github.com/Lerg/smartpixel-config-lua

– SmartPixel config.lua

– Uses pixel perfect content scaling when possible

local w, h = display.pixelWidth, display.pixelHeight

local modes = {1, 1.5, 2, 3, 4, 6, 8} – Scaling factors to try

local contentW, contentH = 320, 480   – Minimal size your content can fit in

– Try each mode and find the best one

local _w, _h, _m = w, h, 1

for i = 1, #modes do

    local m = modes[i]

    local lw, lh = w / m, h / m

    if lw < contentW or lh < contentH then

        break

    else

        _w, _h, _m = lw, lh, m

    end

end

– If scaling is not pixel perfect (between 1 and 2) - use letterbox

if _m < 2 then

    local scale = math.max(contentW / w, contentH / h)

    _w, _h = w * scale, h * scale

end

application = {

    content = {

        width = _w,

        height = _h,

        scale = ‘letterbox’,

        fps = 60,

        imageSuffix = {

            [’@2x’] = 1.1,

            [’@4x’] = 2.1,

        }

    }

}

– Uncomment to use the common content scaling

–[[

application = {

    content = {

        width = 320,

        height = 480,

        scale = ‘letterbox’,

        fps = 60,

        imageSuffix = {

            [’@2x’] = 1.1,

            [’@4x’] = 2.1,

        }

    }

}

–]]

[/lua]

main.lua belwo

[lua]

local _W, _H = display.contentWidth, display.contentHeight

local _CX, _CY = _W * 0.5, _H * 0.5

– x = 0, y = 0 - top left corner

– x = _W, y = _H - bottom right corner

display.setStatusBar(display.HiddenStatusBar)

display.setDefault(‘background’, 0.5, 0, 0)

local s = 70 

local frame = display.newRect(_CX, _CY, _W - 2, _H - 2)

frame:setFillColor(0, 1, 1, 0.5)

frame.strokeWidth = 1

local topLeftRect = display.newRect(0, 0, s, s)

topLeftRect.anchorX, topLeftRect.anchorY = 0, 0

local bottomRightRect = display.newRect(_W, _H, s, s)

bottomRightRect.anchorX, bottomRightRect.anchorY = 1, 1

– added by DAE

local ViewableContentSize = display.newText {

    x = _CX, y = _CY -150, fontSize = 14,

    text = 'Viewable Content: ’ … display.viewableContentWidth … ’ x ’

    … display.viewableContentHeight

}

local ConfigContentSize = display.newText {

    x = _CX, y = _CY -125, fontSize = 14,

    text = 'Config Content: ’ … tostring(_W) … ’ x ’ … tostring(_H)

}

– end of DAE edit 

local contentSizeText = display.newText{

    x = _CX, y = _CY - 100,

    fontSize = 14,

    text = 'Content (Actual): ’ … display.actualContentWidth … ’ x ’ … display.actualContentHeight

}

local suffix = display.imageSuffix or ‘none’

local suffixText = display.newText{

    x = _CX, y = _CY - 50,

    fontSize = 14,

    text = 'Suffix: ’ … suffix

}

local scale = display.pixelHeight / display.actualContentHeight

local scaleText = display.newText{

    x = _CX, y = _CY,

    fontSize = 14,

    text = 'Scale: ’ … scale

}

local pixelPerfect = ‘no’

if scale == 3 then

    pixelPerfect = ‘kinda’

elseif scale == 1 or scale % 2 == 0 then

    pixelPerfect = ‘yes’

end

local pixelText = display.newText{

    x = _CX, y = _CY + 50,

    fontSize = 14,

    text = 'Pixel perfect: ’ … pixelPerfect

}

– added by DAE

local screenPixels = display.newText {

    x = _CX , y =_CY + 80, fontSize = 14 ,

    text = ‘ScreenPixels: ’ … display.pixelWidth … ’ x’ … display.pixelHeight

}

print(‘Content’, display.actualContentWidth … ’ x ’ … display.actualContentHeight)

print(‘Suffix’, suffix)

print(‘Scale’, scale)

print(‘Pixel perfect’, pixelPerfect)

[/lua]

[bjsorrentino]

Hi @DougAEdwards,

I must admit, while there are many ways to “tinker” with the config.lua setup, I’m not a supporter of over-complicating this. Some users will set up variable scales, widths, heights, etc. (as it appears this code is doing), but I find it vastly easier to just set up a basic content area width/height like 320x480, using “letterbox” scale (or “zoomEven” if you prefer), then using Corona APIs to work within that content area on every screen aspect ratio.

Basically, when it comes to handling mobile device screen sizes/aspects, it’s already a little challenging by the sheer fact of the hundreds of different devices in the market. Why make your life as a developer more complicated than it needs to be?

Brent

[JonPM]

@bjsorrentino

Basically, when it comes to handling mobile device screen sizes/aspects, it’s already a little challenging by the sheer fact of the hundreds of different devices in the market. Why make your life as a developer more complicated than it needs to be?

Brent

Correction:  *thousands

[DougAEdwards]

Sorry if I didn’t make myself clear.

My query was about the apparent anomalous results returned by display.pixel* for an iPhone 6[s] in standard view and zoomed view modes. The Corona simulator returns what I might have expected, the Xcode simulator and the real device returns what are to me  counter-intuitive results (I haven’t found a way for getting Xcode to simulate a device in zoomed view mode though).

The query was not about Sergey’s SmartPixel config lua - it was just that I was running his code to understand how it works when I came across this anomaly. The major part of my query (contained in points 1 to 3 in my original posting) used a more or less standard configuration file (obtained by uncommenting the last code block in the config.lua file I posted above).

Should I have posed this query in another part of the forum?

[rob]

If you only include a Default-568h@2x.png launcher image, iOS assume your phone is running in iPhone 5 compatibility mode and it returns you values relative to stretching the iPhone 5 screen to fit the iPhone 6’s physical size. The 6’s screen is 117% bigger.  This works out to a 750 x 1331 pixel screen. The actual iPhone 6 screen is just a little bit taller, 750x1334 in size. When that’s scaled down to the 320x content area, (320 / 750 * 1336) you get 569. So the numbers are right and you’re seeing iPhone 5 compatibility mode.

See the guide on build.settings (https://docs.coronalabs.com/guide/distribution/buildSettings/index.html#ios-1) for Launcher image setup for the new phones.

Rob

[DougAEdwards]

Thanks Rob.

I didn’t realise the implications of not specifying a launch image for the different devices - especially as it seemed to work without one.

Any reason why Corona does not generate a table for UILaunchImages in the plist table of the build.settings file?

[rob]

Two reasons.  First, not everyone wants it. We have many Android only developers or people building OS X and Windows desktop apps or even tvOS. We are not going to randomly drop a massive table in build settings until people need it. Secondly, there is an alternate way of using Xcode and it’s Storyboard to generate a file that does launch images instead of using that huge table which some people prefer. See:

https://coronalabs.com/blog/2014/10/21/tutorial-building-multi-screen-launch-images-using-xcode-6/

It’s a bit dated since Xcode 7 came out, but the technique will still work.

Rob