Modernizing the config.lua - Rob Miracle article

Solar2D General Questions/Discussion
#21

Hi @piotrz55,

I see your point, and I think it may be an inherent issue with laying out a grid, even if you use the low-to-high method. For example, if you start with 320x480 (the old suggested size) and do 1 pixel lines, the grid will probably look odd on some devices that don’t scale up at an even 2x or 4x factor (and that would happen frequently, since there are so many devices of so many sizes). The thin lines may become “2.5” pixels, or “4.5” or whatever.

I suppose you could gather the actual screen size of the device and show different size lines on each, but that may still not work as expected.

Brent

#22

I suppose you could gather the actual screen size of the device and show different size lines on each, but that may still not work as expected.

But there is difference for vertical and horizontal ones. Let’s say both are 3px. Then fvertiacal appears as 2px and horizontal as 1px wide.

For example, if you start with 320x480 (the old suggested size) and do 1 pixel lines, the grid will probably look odd on some devices

I was using such config before and all lines were the same width, but now vertical and horizontal ones differ

#23

Hmmm, that’s odd. And you’re not using “zoomStretch” scale mode or something? What is your content width and height, and what device is this occurring on?

#24

If you still need to support a lower resolution screen, it may be best to keep your core content area close the base size you intend to support.

#25

Haven’t checked for lower resolution - found this issue today. I use Galaxy S3 and have problem with thin lines. My config file is as in article, 800x1200 option

#26

Hi @piotrz55,

Just to bump my previous question, are you by chance using “zoomStretch” for the scale mode?

#27

Nope, just copy paste from Rob’s tutorial

#28

Any suggestions?

#29

Hi @piotrz55,

How are you printing “application.content.height”? This does not appear to be a valid API call. Also, did you change the scale setting to something other than “letterbox” as shown in the tutorial? Can you please show some code, esp. your config.lua file?

Thanks,

Brent

#30

Keep in mind, the config.lua is presented in “Portrait” mode.  The SIII is a 720x1280 screen so 1280/720 = 1.7777778 * 800pt wide content area = 1422 display.contentHeight (guess it could round up to 1423)  So the numbers are right.

Remember the content area does not have to map 1 to 1 with the screen.  That’s why we are suggesting 800x1200 so that people stop thinking in screen pixels.  Think of your app in screen space and let Corona figure it out.  Since the SIII is a “tall” device (greater than the 1:1.5 ratio that we use for the content area) the config.lua will calculate the height based on the width of 800.  For your device that becomes 1423.  If you try to run the same app on an iPad it would give you a 1067*1200 content area to work with.  That way all your graphics basically are scaled the same, but you just have different real-estate depending on the screen you have.

#31

Mu config.lua

[lua]

– config.lua

–calculate the aspect ratio of the device

local aspectRatio = display.pixelHeight / display.pixelWidth

application = {

   content = {

      width = aspectRatio > 1.5 and 800 or math.ceil( 1200 / aspectRatio ),

      height = aspectRatio < 1.5 and 1200 or math.ceil( 800 * aspectRatio ),

      scale = “letterBox”,

      fps = 30,

      imageSuffix = {

         ["@2x"] = 1.3,

      },

   },

}

print(aspectRatio, application.content.width, application.content.height )

[/lua]

#32

@Rob

I get the point you are talking about, but if I have background image which has 800x1280 then I have black bars at top and bottom with display.newImageRect(“background.png”, 800, 1280)

#33

If you are not planning on supporting the iPad, your background should be 800x1423 and that’s the values you shoul dbe passing to display.newImageRect().   If you plan on supporting the iPad, the background should be 1067x1423 and loaded in with those values.  The extra area is going to bleed off the screen, so you shouldn’t put critical features in there.  If you need backgrounds to fit more precisely because of critical background elements, then you could put logic in your code that determines if you need an iPad 1.25:1 friendly background, or a HD 16:9 friendly background or whatever device you want and then load in the precise file.

#34

Ok, I think I get it. However, is there possibility you could elaborate shortly why doesn’t content map 1:1 with screen (physical pixels)? Is this ‘excess’ area hidden under display.screenOriginY (1280 + 2×origin)?

#35

Why not map the content area 1:1 with a screen’s physical pixels?   Well the question is “What screen do I use?”   Do I use a 640x960 iPhone 4/4s?  Do I use a 600x1024 Kindle Fire/Nook?  Or a Nexus 7’s 800x1280? A Ouya’s 720x1280? 

No matter which screen you pick there’s going to be more screens that are not that size.  You have to think in screen dimensions.  While you might be comfortable with the screen size of your device, your potential customers screens are going to be all over the place.  Let’s base our numbers on something easy to work with.   Perhaps 1000 x 1500 may have been a better choice (and you are free to use that if you want) or 600 x 900 or whatever values.  Even the 1.5:1 ratio is at this point arbitrary since it’s really based on the 320x480 shape screens which only a few devices have.  But it’s between wider devices like the iPads and the HDTV shaped 16:9 screens and keeps the math easy.

#36

So image(s) of what size should I use to fill whole screen on ‘all’ devices? 800x1280 gave me black bars at the top and at the bottom (like letterbox in portrait mode)

#37

Hi @piotrz55,

900x1425 would be a good bet (and double that for the @2x version).

#38

I understand that Corona will handle smaller resolutions and scale it accordingly, am I right? :smiley:

#39

Yes… meaning, do you want to target something like the iPhone3GS, or an older/smaller Android device around that size? If so, you can build in an additional suffix for lower resolutions, and specify the suffix name how you wish.

#40

I would say that my target is to support as many devices as possible. You know, there are always some “no-name” products with lower resolutions on which apps, for example ‘bussiness’ apps, should look ‘quite’ good. I know there is no ultimate one solution but covering as wide range as possible is really helpful.