Android `setOrientationBis` issues

[AntTheAlchemist]

In the case of SDL_SetHint(SDL_HINT_ORIENTATIONS, "LandscapeLeft LandscapeRight Portrait PortraitUpsideDown"), setOrientationBis will decide depending on w > h. This is a bug. It should be using SCREEN_ORIENTATION_FULL_SENSOR instead, to let the sensor decide.

[slime73]

Looking at the code, it seems like it will do what you want if the window is resizable, right? Here:

SDL/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java

Lines 1142 to 1146 in a880410

	/* At least one orientation is allowed */
	if (resizable) {
	if (is_portrait_allowed && is_landscape_allowed) {
	/* hint allows both landscape and portrait, promote to full user */
	req = ActivityInfo.SCREEN_ORIENTATION_FULL_USER;

[AntTheAlchemist]

Looking at the code, it seems like it will do what you want if the window is resizable, right?

You're right - I didn't notice I was missing that flag in my window creation 🤦🏼‍♂️ Thanks!

[AntTheAlchemist]

I did find another bug though. If choosing between a flipped, or not, version of landscape / portrait, the user setting isn't respected, so it will always use the sensor, regardless of user's auto rotate setting. So, if it's a full 360 rotation, that works fine, and respects the user's auto rotate. But landscapeLeft & landscapeRight will always be sensor, ignoring user's auto rotate. Does that make sense?

[slouken]

Patches welcome!

[AntTheAlchemist]

I'll have a bash at a fix later - it's making me go cross-eyed at the moment.

[AntTheAlchemist]

07636ac fixes the user's auto-rotate issue, but I found yet another problem in the logic:

SDL_SetHint(SDL_HINT_ORIENTATIONS, "LandscapeLeft LandscapeRight Portrait"); will allow PortraitUpsideDown, because there's no distinction between one portrait and both landscape (and visa versa... one landscape and both portraits) when deciding to allow all orientations (hope that makes sense). I don't see a way to actually fix this without looking to see if we're attempting to get landscape or portrait. setOrientationBis() is flawed; a different approach is needed.

[superfury]

I've noticed issues on Android with this as well.
My app basically uses a SDL1/2/3 (using ifdefs) compatible way of creating a SDL surface, and for SDL2/3 the window, texture and attributes. The SDL2 method is based on the 1.2->2.0 migration guide. Then the same is done for the SDL2->SDL3 migration guide. The code (detecting SDL2 and SDL3 defines to differentiate the code) is thus compatible with all 3. There's also a STATICSCREEN setting that changes some specific nonresizing behaviour for unchanging screens (with a fixed horizontal/vertical resolution. Basically all consoles and Android in my app's case). Sony PSP (SDL 1.2) uses a hardcoded resolution, the others are dynamic (Windows/Linux) or static as well as autodetected (SDL2/3, using SDL defaults).
See: https://bitbucket.org/superfury/commonemuframework/src/default/emu/gpu/gpu.c function updateWindow (the updateWindowOrientation is also called when the screen orientation changes (SDL orientation event is pretty much given into it's parameters with update set to 1 instead of updateWindow's 0), causing updateWindow to be called at a later point in time to refresh the window size etc., done through forcing the texure to be reloaded (the variable being set to 1)).

Now, I've looked at the results.
On Windows, somehow horizontal mouse coordinates go wonky on full screen SDL3 (it almost looks like they're too large movements combined with x/y swapped in the default Landscape mode of most monitors?). Maybe also the coordinates are DPI-affected, making them even smaller incorrectly? My app expects a simple linear float from 0.0-1.0 of the window's relative x/y axis (converting it back to pixels or inches/mm for it's purposes) like in windowed mode. But this doesn't seem to work properly? Maybe it's also affected by the fullscreen letterbox handling using the SDL SDL_SetRenderLogicalPresentation SDL_LOGICAL_PRESENTATION_LETTERBOX to keep aspect ratio proper?
Then, on Android, the touch events seem to follow the (hard) configured orientation (top right bottom of current orientation being reported as almost coordinate 1.0,1.0. This works fine on both SDL 3.1.1 and 3.1.3+.
However, the screen window (rendered landscape in my app always) is setup as follows:
(Works fine on SDL 3.1.1 on Android, faults like below on 3.1.3 and 3.1.6)

• Before SDL_Init, set the orientation Hint to "LandscapeLeft LandscapeRight" to only support landscape outputs (my app tries to use the full screen, which is better when using the old sensor landscape mode in SDL2 activity, which is removed for SDL3). Disabling this call makes the screen render stretched to edges of the screen in portrait mode only (landscape has no effect). The top-right bottom of the screen always registers as (1,1) with touch events, so that's correct. But since the screen stays stuck on portrait mode, the touch events rotate to 0,90,180,270 degrees even though the screen pixels only rotate 0,180 degrees?
• I've tried fixing it by making the texture rotate 90 degrees clockwise from within the rendering (https://bitbucket.org/superfury/commonemuframework/src/default/emu/gpu/gpu_sdl.c function safeFlip. It's calling SDL_RenderTextureRotated instead of SDL_RenderTexture in this case (only on Android right now, although commented out using a "#if 0" preprocesor directive). Somehow the screen gets oddly stretched in landscape mode with this?

Edit: Managed to fix the 3.1.3+ (or 3.1.6, don't know when high DPI support was introduced) handling of mouse and touch coordinates. Now, both coordinate x/y locations are first filtered using SDL_ConvertEventToRenderCoordinates. Also when using finger events, it also transforms ms it back to relative coordinates using the know x and y resolution (since the touch subsystem of my app uses that for compatiblity).

Still working on getting the Android version running properly.

[superfury]

I've tried to make it run better this time.

I've changed the window to resizable (to properly obtain the four direction events) and observed the height/width gotten from the SDL_GetDisplayUsableBounds to obtain the coordinates for rendering on the window's automatically located display.
For some reason, Portrait mode reports a portrait size. And Landscape mode reports a Landscape size (portrait, but x/y swapped).
But when rendering the screen, both are rendered in portrait always? And since the window size can't be adjusted using SDL_SetWindowSize (it has no SDL handler when I step into the function (returning SDL_Unmapped()) and doesn't affect the renderer properly). So it's giving a Landscape sized screen which can only be rendered in portrait! Thus messing up all aspect ratios that are used etc.
The coordinate system performs fullscreen always in those cases, so at least that's correct for that case.
non-Fullscreen (using the same method but for filling the desktop area using a window) desktop windows on Windows also messes up the coordinates using SDL_ConvertEventToRenderCoordinates. It works fine in fullscreen (with letterboxing presentation) and normal non-letterbox presentation windowed mode though?

[AntTheAlchemist]

@superfury keep in mind that there are several other bugs at the moment which will confuse things. Vulkan currently renders in portrait only, which might explain what's going on. And changing orientation will leave the rotated renderer in a broken state coordinate-wise until after 1 present. There is no way to reliably determine what's going on until the other bugs are fixed.

[superfury]

OK. I found out one weird thing.
When on Android, somehow in landscape mode, the width is large while the height is small.
So basically, it's providing a viewport of a landscape window, even though the window being rendered is actually portrait (I see it being cut off in this mode, as the horizontal vs vertical sizes are inversed in the window when created without any sizes (for autodetection using the display it's connected to))?