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

Solar2D Android
#21

(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.

#22

(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?)

#23

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!

#24

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.

#25

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…

#26

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]

#27

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();&nbsp;

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.