iOS no longer accepting games in letterbox format. Which resolution?

I've recently had my game rejected because it was in letterbox format.

Apple told me that using letterbox on games makes them look unfinished. So, I have to go full screen.

If I go full screen now. It will stretch the background image. So, I'm going to have to resize it and crop a bit out.

What would be the best resolution to choose for the game, for Apple devices?

Thanks

Seb

I never bump my topics. But, I'm stressing out about this and I want to sort it out before tomorrow.

Any help would be greatly appreciated.

480x320 is Stencyl's recommended resolution, but it really depends how you want your game to look on different devices.  That's what makes these scaling questions so hard to answer.  There is no one solution and what one developer likes, another one hates.

Well, that neither answers the question nor says anything other than "you're on your own."

See this topic for my solution, and a bug report about how Stencyl silently switches the game's choice of scaling algorithm based on seemingly arbitrary criteria:

http://community.stencyl.com/index.php/topic,42976.msg241112.html#msg241112

Some clarity from the developers on this topic is in order, I think. Setting the game's resolution to 480x320 hasn't worked right for anything other than the Flash target in a long time. Stencyl doesn't expose enough of its internals in a usable fashion to get around the limitations it imposes on games, forcing developers to directly access undocumented variables like engine.root.x/engine.root.y, and it seems like developers are struggling with this, when they really shouldn't be - there should be a supported way to determine the safe area games can draw to when a game is using a scaling mode that results in clipping, and the engine should not override the user's choice of scaling algorithm.

The only way I could get my solution to work at all was to patch the engine. I think this is silly for a tool that's supposed to be "the easiest way to make a game."

At the very least, change your documentation to reflect what the engine is ACTUALLY doing.

Here's some more information on the solution I used. My game is in landscape mode, and can't display in letterbox format. It also has onscreen controls which must always show up in the same position relative to the screen edges, regardless on the physical dimensions of the device's screen.

If your game is in portrait mode, you'll have to make some adjustments to make this work for you. Specifically, you'll probably need to calculate the vertical offset of the displayed area, rather than the horizontal offset.

I made my game's resolution 600x320. This should be a wider aspect ratio than any screen that's currently available. The game is designed so that it can be played even if you can't see the edges of the screen. I set the game's scale mode to "Scale to Fit (Letterbox)". You'll note that this is the exact opposite of what the game REALLY needs, which is "Scale to Fit (Fill)". As it turns out, in landscape mode, in some situations, Stencyl arbitrarily switches the two scale modes. More on that later. What you need to know right now is that the actual scale mode we want is "Scale to Fit (Fill)".

What happens in this scale mode is that the engine scales the game so that its smaller dimension fills the device's screen, edge to edge. We're in landscape mode, so the smaller dimension is the height. Some part of the view to the right and left is clipped, but I designed my game so that nothing too important happens there. (My game happens to be a scroller - if the player needs to see that part of the level, he can always go there. It works for me.)

If your game doesn't have any on-screen controls or HUD that needs to be positioned precisely, you can skip ahead to the caveats.

To position on-screen controls, you need to know the offset in game pixels (not device pixels) from the edge of the game's screen to the beginning of the window that's actually displayed. Stencyl's engine keeps that information in the engine.root variable, but that's expressed in device pixels, so to get something we can use in the game we need to divide that by the scale constants that Stencyl uses. We can calculate the offset in game pixels using the expression:

Code: [Select]

-engine.root.x/(engine.root.scaleX*Engine.SCALE)
See the attached image for an example of a Stencyl code block that calculates this and stores it in an attribute.

Once you have the offset available, you can use it to calculate the position of on-screen elements. Position them where they need to be, and anchor them to the screen to show up regardless of the camera position.

For certain types of games, you'll have to use this offset to position game elements (certain types of puzzle games, for example, might need to have game elements positioned very carefully.)

Now for the caveat: When I tested this solution in the iOS simulator, it worked in some configurations, and didn't work in others. Specifically, this worked on the 4", 4.7" and 5.5" simulators, but not in the 3.5" or iPad simulators. In configurations where this didn't work, I was still getting letterbox mode. What's going on?

It turns out that for this to work, the engine must use Scale to Fit (Fill) mode. But it arbitrarily switches to use Letterbox mode when the aspect ratio of the device's screen is 1.5 or less, which includes the 3.5" screens on iPhone 4 or older devices, and all iPad screens.

I can't stress enough how stupid this is.

The only solution I found was to patch the Stencyl engine to at least be consistent about how it applies this switch. To do this, edit line 217 of plaf/haxe/lib/stencyl/1,00/Universal.hx (or around that line) so that instead of:

Code: [Select]

widescreen = aspectRatio > 1.5
it says:

Code: [Select]

widescreen = aspectRatio > 1
This makes my solution work consistently across all iPads and all iPhone configurations, with no letterbox.

This works by pretending that all devices are widescreen devices (why is Stencyl even making that distinction? Because.) A better solution would be to force all devices to NOT be detected as widescreen devices by removing that line, and the if statement that follows it, and selecting the correct Scale Mode, and having Stencyl actually respect it.

I hope this helps, and that you can finally get your game published. I can imagine how stressful it is to have your game rejected and to not get any help from your tool vendor after you paid them good money for a subscription.

Well, that neither answers the question nor says anything other than "you're on your own."

Besides the bug you hijacked this thread to rant about, yeah I'd agree with that.  I can give general explanations for what the scaling modes do but that isn't enough.  I've said before in topics about scaling modes that developers should just try things and see how they look.  For me, I would likely never use the resolution and scaling mode that you used.  What works for you doesn't for others.

Sorry that you feel Stencyl devs are ignoring you, but it's a tiny company with no dedicated forum support, and the devs don't see every thread.  I suggest bumping up your original thread once per day until you get a response.

I did say that this solution worked for me.

Regarding hijacking the thread - I don't feel that's what I was doing. I was trying to present a possible solution to a problem a customer (and a paying customer, I might add) was having, and getting into the details of that bug was necessary for the discussion.

Bumping a bug report doesn't seem to help. Posting it elsewhere doesn't seem to do anything, either.

As for Stencyl being a small company... I'm aware of that, and I'm worried about it. They'll never get any bigger without paying some real attention to paying customers. I was a Studio subscriber for a year, and one of the reasons I didn't renew this year was that I didn't feel like the company was taking customers' issues seriously. I felt like I could never get anyone's attention when I had serious issues with the product, and I saw other people reporting showstopping bugs and getting no response. This kind of attitude will hurt any business's bottom line, and it's a shame to see Stencyl taking this kind of approach. I do like their product, and I think it has potential, but I'm at the point where I'd be worried to rely on it for anything important due to the complete lack of support.

Software developers shouldn't worry when their customers complain. They should worry when the complaints stop.

I've said before in topics about scaling modes that developers should just try things and see how they look.

This can't work as long as the scaling mode changes arbitrarily.

For me, I would likely never use the resolution and scaling mode that you used.  What works for you doesn't for others.

So, what have you used successfully?

I used to use stretch to fit, but my current preference is scale to fit (full screen) with a 310x480 resolution.  The 10 smaller width makes sure that the iPhone 6+ uses 4x graphics rather than 2x (or 3x if enabled).  Actors are adjusted based on camera position and screen size.

Interesting. I remember that when I tried it, Full Screen wasn't working for me at all, but I don't remember the symptoms. I'll have to look at it again.

Thanks, oripessach!

Massively appreciated.

I'll look into your method and rob1221's method, too! (Cheers, Rob)