win32 alpha fullscreen rotates a portrait game

[miellaby]

The win32 (alpha target) exe does auto-rotate a portrait-oriented game when the window gets bigger in width. Game not playable on desktop because of this bug.

I guess there shouldn't be a autorotate feature at all on a win32 game anyway, should be?

[john-blackburn]

Yes, I think you are right. So if you maximise the portrait oriented game, it should fill the surrounding space with just the background colour? Or perhaps maximise just means fill the screen vertically but not horizontally (ie stretch from top to bottom but not full screen)

[AnthonyBall1966]

Don't forget that some win32 devices are portrait.

[john-blackburn]

I'm trying to think here about what should really happen. Let's say you have a portrait game which launches at 480x800 px. So it starts off in a window 480 px wide and 800 px deep. Then the user clicks the maximise button. Do we want the window to fill the whole screen? If it does, and the game remains portrait within the window, then large areas to the left and right of the game area will be blank, filled with a single colour (presumably the application:getBackgroundColor value). This is actually how the Qt-based Windows Desktop target works.

But the problem with this is large areas of the screen are obscured and the user cannot do anything else with his computer while playing the game. A better solution might be, when the user presses "maximise" it maximised only vertically. So if the users screen is 1920 × 1280, the window would resize to 1280 px high. But probably we don't want it to be 480 x 1280 as it would be too tall and thin. Probably we want to maximise vertically while retaining the same aspect ratio, so it should grow to 768 x 1280 in this example.

[miellaby]

But the problem with this is large areas of the screen are obscured and the user cannot do anything else with his computer while playing the game.

That's the point of fullscreen IMHO. I'm against a simple window resizing.

If it does, and the game remains portrait within the window, then large areas to the left and right of the game area will be blank, filled with a single colour (presumably the application:getBackgroundColor value)

Only if Gideros perform stage clipping. Which should be an option. If clipping is disabled, the developper might prepare a nice background picture at top of the z-stack to both clip stuff and decorate in case of fullscreen.

Well that's what I would do with my game renabomb, which works in portrait mode. I already use a png "frame" so to accomodate the different screen ratios with pixel-perfect scaling on Android.

[john-blackburn]

OK, thanks, I see what you mean! So am I right in saying the Windows Desktop export (with Qt) behaves just as you want? If so I will try to copy this behaviour in Win32 (and also WinRT).

[miellaby]

Yep, the QT based exe behavior is the best default behavior IMHO.

As a matter of fact, it should be the default behavior for Android and other mobile platforms as well, while It's not the case today on Android. Depending on the scaling mode, the user may see leaks out of the stage dimension. That's why I had to develop a stupid masking frame.

Ideally, there should be an option to enable/disable stage clipping for all targets (default to enabled like QT export). it should be a global option beside the project logical dimensions and scaling mode in the project settings and it should be observed whatever the target,