Joypad size and placement

[thomas6]

Hi all,

Over the years I’ve become a very good Lua / Corona coder, and I’ve seen numerous thread sort of sideways-relating to this question, but still I find I’m faced with a conundrum.

How do you guys deal with joypad/joystick button placement on the screen? I know this all boils down to resolution and device detection, as well as guessing physical screen dimensions, but in the end I’m really wondering if anyone has a good solution for this…

For a bit more of an in-depth explanation: I’m wondering how you can detect screen ratios, dimension and physical size so that you can place and size joypad buttons in a practical way. In my personal case, that would be a left and right button in the left bottom corner of the screen, and a jump button in the right bottom corner.

For example, the iPad Pro and iPad Mini share the same resolution. How then do you detect that one device is a lot bigger than the other, so you can scale up the buttons on the smaller screen (or the other way around).

How do you guys and girls deal with this? Smart detection of screen sizes, user settings with a couple of different options, or even complete personal customisation?

Really looking forward to hearing how other deal with this.

Thanks,

Thomas

[anaqim]

Hi, never done it but why couldnt you just anchor them off the edges?

Something like:

local dw=display.actualContentWidth local dh=display.actualContentHeight local leftController=display.newImage(...etc) leftController.anchorX=0 leftController.anchorY=1 leftController:translate(20,dh-20) local rightController=display.newImage(...etc) rightController.anchorX=1 rightController.anchorY=1 rightController(dw-20,dh-20)

[thomas6]

Correct, that’s part of the solution. But that only helps to find the “corners”.

Then you still need to figure out how big you want to make the buttons, and how far from the edge you want to go. If not, your “right-sized” buttons on the iPad mini will become giant blobs that are space out too far to be practical on an iPad Pro 10".

That’s the hard part.

[davebollinger]

on android it’s relatively* easy to get the physical size with system.getInfo, then a bit of math against display.pixelWidth will give you the scaling factor for a reasonable starting point for making a true “one inch button, one-half inch from screen edge” (example measurements).   tho i’d still suggest allowing user to adjust this from a settings screen if you can.

*except that some devices “lie” about their physical size

that type of support was essentially mandatory on android since there’s like 10,000 different makes/models.  on ios it’s harder, BUT you could do it via platform-detection since there’s probably less than a dozen or so models you’d likely need to support.

[anaqim]

those controllers usually have a set size in your design resolution.

its then easy to know that left controller is 10.23% of the width (example only)

thats a percentage you can use to resize the controller for each screen size.

its the same with distance from edges etc, always use percentages instead of hard pixel sizes, and you should be fine.

[davebollinger]

the problem (as per OP) with percentages is that you might end up with a 1" button on a small phone, but a 3" button on a big tablet. (assuming that content dimensions remain constant, except for aspect adjustment, thus content ratio to device pixels remains same too - what’s missing from the calculations is a physical dimension)

consider a 3.5" iphone4 at 640x960 vs a 9" ipad2 at 768x1024.  nearly the same pixel resolution, but tablet’s physical dimensions are much bigger.  so then if your content dimensions remain constant (say 320x480, as aspect-adjusted) then your contentScale remains essentially constant too (minor difference due to aspect-adjustment notwithstanding), so essentially:  10% of 3.5" produces a .35" button, 10% of 9" produces a .9" button = ~3x bigger.

actual issue:  human dimensions (ie: “how big is your fingertip”) don’t change just because you have a larger or smaller device.

you need to know the physical dimensions in order to calculate DPI (dots per inch), else you can’t correct for physical ui size.  native ui development doesn’t have this issue because measurements are abstracted into virtual “points”, but corona does.  (you could try corona’s adaptive scaling, though it potentially has other non-desirable properties for game use)

[thomas6]

Thanks DaveB, you beat me to it and saved me some time.

For Android I can get the physical dimensions of the screen.

For iOS I can make an estimated guess for past models, but unfortunately not for future devices.

I think I’m going to have a “Joypad scale” setting that users can set with a slider. On first startup I will make an educated guess based on the above, and then users can adjust according to their liking with the scale slider.

That seems to be the best way to go, for now, for me!

[anaqim]

If creating a game that uses zoom scaling, which most do, I would presume the developer want controls to scale with the UI, otherwise there will be displacements that needs to be catered for (as dave suggested).

Its true that controls will vary in size according to screen sizes, but so will the game itself so I dont quite see this as anything but expected and okay behaviour. its of course important to use sizes that work decently on all scales otherwise it gets tricky. One could also “aid” the controls by using a transparent area outside the controls to extend the touch area, provided whats behind doesnt require touch events. Its not a perfect solution but it should work fine.

For adaptive scaling things are easier and work pretty much like i described above. I’m using adaptive scaling in my latest app and have tested it on several devices from 4 to 10 inches and with different pixel density, it seems to work fine, although not always 100% identical in size. I need to test on more devices but the corona adaptive scaling should take care of it for all common cases, so i dont worry much about it.

[anaqim]

Hi, never done it but why couldnt you just anchor them off the edges?

Something like:

local dw=display.actualContentWidth local dh=display.actualContentHeight local leftController=display.newImage(...etc) leftController.anchorX=0 leftController.anchorY=1 leftController:translate(20,dh-20) local rightController=display.newImage(...etc) rightController.anchorX=1 rightController.anchorY=1 rightController(dw-20,dh-20)

[thomas6]

Correct, that’s part of the solution. But that only helps to find the “corners”.

Then you still need to figure out how big you want to make the buttons, and how far from the edge you want to go. If not, your “right-sized” buttons on the iPad mini will become giant blobs that are space out too far to be practical on an iPad Pro 10".

That’s the hard part.

[davebollinger]

on android it’s relatively* easy to get the physical size with system.getInfo, then a bit of math against display.pixelWidth will give you the scaling factor for a reasonable starting point for making a true “one inch button, one-half inch from screen edge” (example measurements).   tho i’d still suggest allowing user to adjust this from a settings screen if you can.

*except that some devices “lie” about their physical size

that type of support was essentially mandatory on android since there’s like 10,000 different makes/models.  on ios it’s harder, BUT you could do it via platform-detection since there’s probably less than a dozen or so models you’d likely need to support.

[anaqim]

those controllers usually have a set size in your design resolution.

its then easy to know that left controller is 10.23% of the width (example only)

thats a percentage you can use to resize the controller for each screen size.

its the same with distance from edges etc, always use percentages instead of hard pixel sizes, and you should be fine.

[davebollinger]

the problem (as per OP) with percentages is that you might end up with a 1" button on a small phone, but a 3" button on a big tablet. (assuming that content dimensions remain constant, except for aspect adjustment, thus content ratio to device pixels remains same too - what’s missing from the calculations is a physical dimension)

consider a 3.5" iphone4 at 640x960 vs a 9" ipad2 at 768x1024.  nearly the same pixel resolution, but tablet’s physical dimensions are much bigger.  so then if your content dimensions remain constant (say 320x480, as aspect-adjusted) then your contentScale remains essentially constant too (minor difference due to aspect-adjustment notwithstanding), so essentially:  10% of 3.5" produces a .35" button, 10% of 9" produces a .9" button = ~3x bigger.

actual issue:  human dimensions (ie: “how big is your fingertip”) don’t change just because you have a larger or smaller device.

you need to know the physical dimensions in order to calculate DPI (dots per inch), else you can’t correct for physical ui size.  native ui development doesn’t have this issue because measurements are abstracted into virtual “points”, but corona does.  (you could try corona’s adaptive scaling, though it potentially has other non-desirable properties for game use)

[thomas6]

Thanks DaveB, you beat me to it and saved me some time.

For Android I can get the physical dimensions of the screen.

For iOS I can make an estimated guess for past models, but unfortunately not for future devices.

I think I’m going to have a “Joypad scale” setting that users can set with a slider. On first startup I will make an educated guess based on the above, and then users can adjust according to their liking with the scale slider.

That seems to be the best way to go, for now, for me!

[anaqim]

If creating a game that uses zoom scaling, which most do, I would presume the developer want controls to scale with the UI, otherwise there will be displacements that needs to be catered for (as dave suggested).

Its true that controls will vary in size according to screen sizes, but so will the game itself so I dont quite see this as anything but expected and okay behaviour. its of course important to use sizes that work decently on all scales otherwise it gets tricky. One could also “aid” the controls by using a transparent area outside the controls to extend the touch area, provided whats behind doesnt require touch events. Its not a perfect solution but it should work fine.

For adaptive scaling things are easier and work pretty much like i described above. I’m using adaptive scaling in my latest app and have tested it on several devices from 4 to 10 inches and with different pixel density, it seems to work fine, although not always 100% identical in size. I need to test on more devices but the corona adaptive scaling should take care of it for all common cases, so i dont worry much about it.