What Skin do you use? (Janky Sim Skin Discussion)

[richard9]

Just dipping my toes into the Android side of the pond through OSX, and I’m really quite…shocked?..at how outdated the simulator skin set is for Android, I mean:

• Motorola Droid : 480x854, 4 years old
• Google NexusOne : 480x800, 4 years old
• HTC Sensation : 540x960, 2+ years old
• Samsung Galaxy Tab : 600x1024, nearly 4 years old
• Samsung Galaxy S3 : 720x1280, almost 2 years old, easily the most relevant here

I can understand supporting old devices, and maybe some/all of them still support Google Play - obviously the S3 is still quite popular - but this isn’t even the same time zone as the current shelf of Android releases (Z1, HTC One, Galaxy S4, Note 3, and so on) or even the wildly lauded Nexus 7 (2013); devices that almost universally are looking at supporting 1080p+.

Do folks here just ignore the Android skins and use the Kindle alternatives? (Or does that just introduce other problems for Google Play developers?)

• Kindle Fire : 600x1024, 2+ years old
• Kindle Fire HD 7 : 800x1280, 1.5 years old
• Kindle Fire HD 9 : 1200x1900, 1.5 years old
• Nook Color: 600x1024, early cretaceous period

Given that the next gen of devices are already talking 2560x1600, and Samsung touting 4K in a few years, this is probably going to continue to spiral out of control. Hopefully users are up voting this feature request to open up the simulator for a more flexible solution that doesn’t require CL to provide new skins and settings every month.

[Alex10]

I’ve got a Nexus 4 daily driver, and a smattering of Acer devices with different resolutions. I also have some committed beta testers with more recent devices. I’d love to get a better look at what things look like on Android from the simulator, so I’m with you there. However, I’ve long stopped putting faith in taking what the simulator shows me as device reality, so after the initial proof of concept, I build straightaway for real-world testing.

Not to sound like a homer, but with the 4000+ Android devices on the road, its tough to cover them all. Also, there are a good amount of things I’d like to get out of CoronaLabs (*cough*Windows Phone*cough*) that forever trump my desire for new skins/resolutions.

[richard9]

I hear you, Panc, but I think in principle it would make more sense (and be far more extendable long-term) to have even a small set of standard resolutions (say, 16x9 and 16x10) with or without skins, that cover a low res to high res gamut:

ie:
480x800
720x1280
1080x1920
2560x1600

That way we could have blanket coverage and some rough testing of how the Android environment would react at the low, mid and high ends of resolution and asset size. As it is, there is seemingly no way to do so unless:

A) test as a Kindle device (possible drawbacks include just being identified wrong in code?)
B) build for device (hardly ideal and generally time consuming)

I agree that it’s impractical to cover all android devices, but the idea should be to at least cover major ones *or* just the major resolutions they might support. For example , I just went overseas, and here’s what commuters used, generally speaking:

50% Note 3 (1920x1080)
20% 5S (1136x640)
20% S4 (1920x1080)
5% Tab 7 (1280x720)

There is some amount of convergence there; supporting even just the major resolutions seems a step up from the current setting.

[ingemar]

For me that lack of resolutions doesn’t bother me too much as I don’t rely on the Corona Simulator for later stage development. That and the fact that I only use letterbox scaling so I know that the stage will always fit on screen.

I only use the Corona Simulator while testing concepts and initial bug fixing. Once I get past that stage I use real devices to confirm layouts and game play.

This goes for both iOS and Android builds.

However, the link above for the Custom Resolution idea is a good one. At least it would make it possible to test any aspect ratio when needed.

[richard9]

Now that I think about it a bit more, I may need to split the vote and ask for something a bit more coherent. To really support Android in the future in a reliable way, we need:

1. Resolution Selection. Skins are flashy but we really just need to be concerned with the fact that any given device going forward is going to be 1280x720, 1920x1080, 1920x1200, or 2560x1600.  iOS is seemingly a more stable platform in this regard, but the Retina iPad screen doesn’t even have a “real” skin per se. 

2. A toggle-able software button array. Android doesn’t generally let you turn this off, so for our purposes its really just a black bar taking up screen real-estate. (I could build some free code to do this, but the downside is everyone would have to branch their code since it wouldn’t update display.actualContentWidth in debug and would have to be turned off on-device.) Sony, Google and LG seem content to use software buttons while Samsung prefers to keep it in hardware, so this is going to be an ongoing struggle. 

I’m actually surprised there isn’t at least one skin with the software array, but I guess given the age of the skins included that’s just how it is.

3. Platform Selection. The as mentioned method to set whether the simulator detects Android, Kindle, etc. Would be a huge step forward given the number of pseudo-android devices and storefronts out there. Tizen, Nokia, Windows, etc…

[Alex10]

I am 100% on-board with #1. Once Windows Phone support rolls out, I think that #3 will be addressed. However, I have a very strong feeling that CL won’t support detection of Tizen, Samsung etc., but that’s just my $0.02. 

As for #2, there are several ROMs/Android OSes that let you go into Immersive mode at your leisure. I’ve seen my screen-size calculations get completely busted with I switch between modes during app use. Not ideal by any stretch, but I think it would be best practice to just code as though it exists. Android is a wild rainforest; you never know when you’re going to step on a brown recluse and buy the farm.

[richard9]

(Platform Selection)

Panc, the argument isn’t so much if Corona Labs will support those other platforms, but just that they already do support quite a bit (iOS, Android, Kindle, Nook, GameStick, Ouya). So that’s a pretty beefy list to start with in terms of devices that are still basically Android cores. And a pulldown is much easier to support for new platforms than baking together a whole new skin-set.

(Immersive Mode)

What devices let you switch? I know about KitKat Immersive Mode but AFAIK you have to implement it per-app, and Corona doesn’t support that yet. I’m not particularly worried about custom ROMs that let you toggle that stuff on the fly; I’m mostly concerned with default phone environments which AFAIK are almost universally “it’s on or it’s off”

Having the button array in the simulator seems crucial to me because:

a) It’s basically a single-sided, forced letterbox, resulting in a lot of new, weird resolutions as you hack pixels off of seemingly standard width/height sets

b ) There is the option (if probably not used much) to use the back button as a feature within an app

c) There seems to be three major implementations, similar to how the iOS status bar works:

1. No software buttons (Galaxy line - easily the most popular Android phone line)

2. Opaque buttons (Nexus line)

3. Translucent buttons (LG G2 and assorted)

[Alex10]

(Platform Selection)

That is a good point about #1. I’m not saying CL won’t support it, I’m just saying my gut says “don’t count on it”. Don’t get me wrong; it’d be sweet if I could get it. 

(Immersive Mode)

Maybe I’m missing something, but I released “Crosstown Smash” after testing on a bunch of different devices, and I didn’t see the navigation bar ever interfere with gameplay. Maybe I didn’t test on enough devices… now I’m scared. I’m going to go back to my beta testers to see if they are seeing anything weird. I haven’t heard anything negative. Do you have any Android devices? Feel free to have a look at the “Free” version and let me know if it looks wonky to you.

[richard9]

(Graphics/Layout)

The problem isn’t so much interfering with gameplay so much as that it requires a more exact style of coding. Since you can’t assume the screen will be 1920x1080 or 1820x1080 or 1890x1080, display.actualContentWidth/height must be used. (game elements aren’t hidden behind the array; the screen resolution itself is adjusted.) And a user-built array isn’t a good idea either for that reason.

You may see different squash/stretching of images than you intended, or even just gaps (especially if you use display.contentHeight) that are not visible using any current simulator skin. I’m currently debugging an issue on the Nexus 7 where a 20px high strip at the top of the screen is not being used, and there’s no simulator skin that can repro it.

(Gameplay)

1. The buttons become a bottom-screen minefield. You don’t want actions too close to the bottom because players may accidentally quit or suspend the app. 

2. Obviously drag-up gestures become much more problematic, if not impossible.

(Devices)

I’m seeing basically the same experience on my Galaxy Note 3 (hardware buttons) and Nexus 7 (software buttons) so you seem good there. But they are both roughly the same resolution (once is 1920x1080, the other is 1920x1080-~60?)

[Alex10]

Just sent you a PM about screenshots, if you can provide them: Awesome! If not: I understand, you didn’t start the thread to be a beta tester

Anyway, yea, those are serious concerns. I do use display.actualContentHeight for button placement, but if you’re saying they are busted, I better figure it out post-haste. I’m waiting to hear back from a Note 3 user, and I might run into Best Buy tonight and check it out there. Cheapest device rental in town.

Now you’ve got me absolutely on board with #2. If I still had hair, it would be turning white at the prospect of a broken interface for players of my game!

[richard9]

Hmm, I guess we are both confused here. display.actualContentHeight works fine, if opposite. But as I just found out this week you *have* to use that; display.contentWidth is useless in this regard because it won’t consider the changed resolution scale. So if you use any other method to get objects on screen, you may have a variety of UI issues that you’ll never see until you put it on the device with software buttons.

I have a Note 3 and things look pretty good. I’ll see if I can send you a couple of grabs from a N7 and Note 3.

[ingemar]

Now I’m a bit confused and also concerned.

I only use letterbox mode in my apps, and I’m using display.contentWidth/contentHeight to position stuff on screen and I haven’t heard about any problems on Android (yet).

I have a Nexus 7, and it uses software to display a black navigation bar at the bottom of the screen and I don’t have any positioning issues on it even though I’m using display.contentWidth and display.contentHeight…

[richard9]

Ingemar, you should be fine AFAIK strictly because you’re using letterbox mode. Letterbox (AFAIK) enforces the original aspect ratio, so that no matter how square the device is, if you have it at 16:9, it will be 16:9 (or whatever your ratio is) display.contentWidth/Height always work because their aspect ratio never changes. 

ie:

– config.lua resolution: 480 x 320 (4:3)

– device resolution: 1280 x 720 (16:9)

– result: Corona SDK calculates the best 4:3 resolution that can fit within 1280x720

– As long as you’re not using display.pixelWidth/Height, your positioning is all fine because the ratios are the same

Using the typical ultimate config.lua method, the aspect ratio can change because the goal is always to use the available screen resolution without warping on-screen elements. 

ie:

– config.lua resolution: 480 x 320 (4:3)

– device resolution: 1280 x 720 (16:9)

– result: vertical/horizontal scaling multipliers are used. So instead of 480 x 320, it might be 512 x 320 or something similar (because 1280x720 would be a @2x situation)

In the second case, display.actualContentWidth/Height will report back 512 x 320, while the original display.contentWidth/Height will still report config.lua’s 480 x 320. So theoretically you are always safer using actualContentWidth/Height.

The trick/annoyance with using ‘actual’ is that it only reports (at least pre G2.0) the width/height of a portrait device, regardless of your orientation settings. So if you’re building a landscape app, you need to use Width in place of Height and vice-versa. This makes your code really difficult to read, and is a strong argument for instead preloading your lua files with more understandable language, i.e.:

[lua]local screenWidth = display.actualContentHeight

local screenHeight = display.actualContentWidth[/lua]

[ingemar]

I use a modified version of the Ultimate Config, and with that I get display.contentWidth/contentHeight to report “actual” width/height, not the letterboxed width/height.

My standard config.lua is like this:

-- config.lua local aspectRatio = display.pixelHeight / display.pixelWidth; SAFE\_WIDTH = 684; SAFE\_HEIGHT = 1026; local maxAspect = SAFE\_HEIGHT / SAFE\_WIDTH; application = { content = { width = aspectRatio \> maxAspect and SAFE\_WIDTH or math.ceil(SAFE\_HEIGHT / aspectRatio), height = aspectRatio \< maxAspect and SAFE\_HEIGHT or math.ceil(SAFE\_WIDTH \* aspectRatio), scale = "letterbox", fps = 60, antialias = false, xAlign = "center", yAlign = "center", imageSuffix = { ["@0.5x"] = 0, [""] = 0.7, ["@2x"] = 1.4 } } }

(Off topic: I know! 684 x 1026 seems weird, but I want the iPad resolution as standard but with the iPhone’s 3:2 aspect ratio, and this is the closest I can get with whole integers)

I also have another module which defines the screen boundaries for me.

(I’ve stripped away a bunch of irrelevant stuff for this topic).

-- appglobals.lua local M = {}; require("config"); -- this reads in config.lua so that the device width/height can be accessed . . . a bunch of other stuff here... . . local deviceScreen = {}; M.configureScreen = function() local dWidth = display.contentWidth \> application.content.width and SAFE\_HEIGHT or SAFE\_WIDTH; local dHeight = display.contentWidth \> application.content.width and SAFE\_WIDTH or SAFE\_HEIGHT; deviceScreen.left = 0; deviceScreen.top = 0; deviceScreen.right = display.contentWidth; deviceScreen.bottom = display.contentHeight; deviceScreen.width = deviceScreen.right - deviceScreen.left; deviceScreen.height = deviceScreen.bottom - deviceScreen.top; deviceScreen.safeLeft = math.ceil((deviceScreen.width - dWidth) / 2); deviceScreen.safeRight = deviceScreen.right - deviceScreen.safeLeft; deviceScreen.safeTop = math.ceil((deviceScreen.height - dHeight) / 2); deviceScreen.safeBottom = deviceScreen.bottom - deviceScreen.safeTop; end M.getScreen = function() return deviceScreen; end -- init module M.configureScreen(); return M;

In my other modules, I then call

local app = require("appglobals"); local screen = app.getScreen(); 

If I need to position stuff within the 3:2 aspect ratio (safe-zone) I use the screen.safe* variants, otherwise I just use left, right etc. to position relative to the device’s actual screen boundaries.

If the app supports both landscape and portrait I call app.configureScreen() on orientation change to calculate the new dimensions.

So far this approach has been successful.

[Alex10]

I’ve got a Nexus 4 daily driver, and a smattering of Acer devices with different resolutions. I also have some committed beta testers with more recent devices. I’d love to get a better look at what things look like on Android from the simulator, so I’m with you there. However, I’ve long stopped putting faith in taking what the simulator shows me as device reality, so after the initial proof of concept, I build straightaway for real-world testing.

Not to sound like a homer, but with the 4000+ Android devices on the road, its tough to cover them all. Also, there are a good amount of things I’d like to get out of CoronaLabs (*cough*Windows Phone*cough*) that forever trump my desire for new skins/resolutions.

[richard9]

I hear you, Panc, but I think in principle it would make more sense (and be far more extendable long-term) to have even a small set of standard resolutions (say, 16x9 and 16x10) with or without skins, that cover a low res to high res gamut:

ie:
480x800
720x1280
1080x1920
2560x1600

That way we could have blanket coverage and some rough testing of how the Android environment would react at the low, mid and high ends of resolution and asset size. As it is, there is seemingly no way to do so unless:

A) test as a Kindle device (possible drawbacks include just being identified wrong in code?)
B) build for device (hardly ideal and generally time consuming)

I agree that it’s impractical to cover all android devices, but the idea should be to at least cover major ones *or* just the major resolutions they might support. For example , I just went overseas, and here’s what commuters used, generally speaking:

50% Note 3 (1920x1080)
20% 5S (1136x640)
20% S4 (1920x1080)
5% Tab 7 (1280x720)

There is some amount of convergence there; supporting even just the major resolutions seems a step up from the current setting.

[ingemar]

For me that lack of resolutions doesn’t bother me too much as I don’t rely on the Corona Simulator for later stage development. That and the fact that I only use letterbox scaling so I know that the stage will always fit on screen.

I only use the Corona Simulator while testing concepts and initial bug fixing. Once I get past that stage I use real devices to confirm layouts and game play.

This goes for both iOS and Android builds.

However, the link above for the Custom Resolution idea is a good one. At least it would make it possible to test any aspect ratio when needed.

[richard9]

Now that I think about it a bit more, I may need to split the vote and ask for something a bit more coherent. To really support Android in the future in a reliable way, we need:

1. Resolution Selection. Skins are flashy but we really just need to be concerned with the fact that any given device going forward is going to be 1280x720, 1920x1080, 1920x1200, or 2560x1600.  iOS is seemingly a more stable platform in this regard, but the Retina iPad screen doesn’t even have a “real” skin per se. 

2. A toggle-able software button array. Android doesn’t generally let you turn this off, so for our purposes its really just a black bar taking up screen real-estate. (I could build some free code to do this, but the downside is everyone would have to branch their code since it wouldn’t update display.actualContentWidth in debug and would have to be turned off on-device.) Sony, Google and LG seem content to use software buttons while Samsung prefers to keep it in hardware, so this is going to be an ongoing struggle. 

I’m actually surprised there isn’t at least one skin with the software array, but I guess given the age of the skins included that’s just how it is.

3. Platform Selection. The as mentioned method to set whether the simulator detects Android, Kindle, etc. Would be a huge step forward given the number of pseudo-android devices and storefronts out there. Tizen, Nokia, Windows, etc…

[Alex10]

I am 100% on-board with #1. Once Windows Phone support rolls out, I think that #3 will be addressed. However, I have a very strong feeling that CL won’t support detection of Tizen, Samsung etc., but that’s just my $0.02. 

As for #2, there are several ROMs/Android OSes that let you go into Immersive mode at your leisure. I’ve seen my screen-size calculations get completely busted with I switch between modes during app use. Not ideal by any stretch, but I think it would be best practice to just code as though it exists. Android is a wild rainforest; you never know when you’re going to step on a brown recluse and buy the farm.

[richard9]

(Platform Selection)

Panc, the argument isn’t so much if Corona Labs will support those other platforms, but just that they already do support quite a bit (iOS, Android, Kindle, Nook, GameStick, Ouya). So that’s a pretty beefy list to start with in terms of devices that are still basically Android cores. And a pulldown is much easier to support for new platforms than baking together a whole new skin-set.

(Immersive Mode)

What devices let you switch? I know about KitKat Immersive Mode but AFAIK you have to implement it per-app, and Corona doesn’t support that yet. I’m not particularly worried about custom ROMs that let you toggle that stuff on the fly; I’m mostly concerned with default phone environments which AFAIK are almost universally “it’s on or it’s off”

Having the button array in the simulator seems crucial to me because:

a) It’s basically a single-sided, forced letterbox, resulting in a lot of new, weird resolutions as you hack pixels off of seemingly standard width/height sets

b ) There is the option (if probably not used much) to use the back button as a feature within an app

c) There seems to be three major implementations, similar to how the iOS status bar works:

1. No software buttons (Galaxy line - easily the most popular Android phone line)

2. Opaque buttons (Nexus line)

3. Translucent buttons (LG G2 and assorted)