Project

General

Profile

Actions

Emulator Issues #13908

open

Android - Portrait Mode - Assumes user is using onscreen input method

Emulator Issues #13908: Android - Portrait Mode - Assumes user is using onscreen input method

Added by JackWitherell 8 months ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
Android
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Not an issue with the emulator, but with the android app specifically.

What's the problem? Describe what went wrong.

I have a device with a square screen (1:1 aspect ratio. I'm already sorry.) with controls intended to be used while the screen is in portrait mode. When setting the app to use portrait/auto orientation, the app assumes that half of the screen should be dedicated to controls, even when the sidebar controller setting is set to None or all controls are toggled off.

Ideally, there should be an option/setting to force portrait and landscape to follow the same behavior at all times.
Using the device with dolphin's setting set to Landscape/auto orientation (and holding the phone sideways) allows me to use widescreen hacks with 1:1 aspect ratio while stretching is enabled. This is ideal and perfect, however when the phone is in portrait mode, only the top half of the screen is used, presumably to allow space for onscreen controls.

This behavior is not device/screen size specific! It's simply hard coded behavior for expected usability. When in portrait mode, the screen is pinned to the top of the display in portrait mode. I'd like to disable this and have the emulator act more like when the device is in landscape mode, where the screen is center justified and fills the vertical space until horizontal space is consumed.

I've omitted Replication Steps since this is inherent behavior. I'm requesting the ability to override it. 1:1 and tall aspect ratio devices are becoming more common now that devices like the RG CubeXX and Unihertz Titan 2 are available.

Is the issue present in the latest release? For future reference, please also write down the version number of the latest release.

Yes / 2509

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

I've attached four screenshots, the only differences between them are whether the device is in landscape/portrait and whether or not stretch+widescreen hack are enabled.

Both landscape screenshots demonstrate ideal behavior, both portrait screenshots demonstrate the bad case.
In all four screenshots, Overlay controls are turned off entirely as external controls are used.
Identical behavior is present in both respective orientations when "auto" orientation is used as opposed to forcing an orientation.


Files

portrait-widescreenhack.png (581 KB) portrait-widescreenhack.png JackWitherell, 10/24/2025 03:35 AM
portrait-4b3.png (473 KB) portrait-4b3.png JackWitherell, 10/24/2025 03:35 AM
landscape-widescreenhack.png (1010 KB) landscape-widescreenhack.png JackWitherell, 10/24/2025 03:35 AM
landscape-4b3.png (648 KB) landscape-4b3.png JackWitherell, 10/24/2025 03:35 AM
Screenshot_20251027-120610_1.png (107 KB) Screenshot_20251027-120610_1.png JackWitherell, 10/27/2025 07:07 PM
aspect-ratio suggestion.png (194 KB) aspect-ratio suggestion.png JackWitherell, 10/29/2025 01:07 AM

Updated by JosJuice 8 months ago Actions #1

  • Operating system Android added
  • Operating system deleted (N/A)

I'd like to avoid adding extra settings unless it's necessary. What do you think about enabling the "half screen" mode only if the orientation is portrait and the on-screen controls are enabled, as opposed to just when the orientation is portrait? Though, hmm... Some users do things like setting the opacity of the on-screen controls to 0 instead of actually disabling them, since how to disable them isn't obvious. So those users could end up confused about this behavior.

I guess another alternative would be to always use the whole screen if the aspect ratio is set to stretch, because I don't see why someone would want to stretch to exactly half of the screen. But that wouldn't solve things for people who have 1:1 displays but don't want to stretch.

Updated by JackWitherell 8 months ago Actions #2

I see now that I'm advocating for a new option to be added, but I'd suggest that the option is necessary in the long term, that the default behavior can be maintained and that there's a good place to put the option since it would be platform specific.

I'd like to avoid adding extra settings unless it's necessary. What do you think about enabling the "half screen" mode only if the orientation is portrait and the on-screen controls are enabled, as opposed to just when the orientation is portrait? Though, hmm... Some users do things like setting the opacity of the on-screen controls to 0 instead of actually disabling them, since how to disable them isn't obvious. So those users could end up confused about this behavior.

My first thought on this could be controversial, but I'd argue that "magic" behavior caused this problem behavior, and by not adding an option, we're asserting that the magic behavior is better than having the option. I agree that adding settings should be avoided, but I'd rather see sensible or overlook-able options over magic. I have significantly less stake in the trajectory of android dolphin development than most other users who prefer android as their dolphin platform, but magic behavior that was originally implemented will bend and shift with it's need over time.

I'd personally be less worried about users setting the opacity to 0 instead of disabling the controls, since they would have practically no stake in achieving the behavior of eliminating the controller region in the first place if they didn't know otherwise and would be satisfied with their approach. They'd need to disable the controls if they wanted the screen region reclaimed and can easily do both. Personally, I was shocked that disabling the controller didn't reclaim the viewport space, so while your concern is valid, I'd be less concerned as user interpretation of quality can still go either direction.

I guess another alternative would be to always use the whole screen if the aspect ratio is set to stretch, because I don't see why someone would want to stretch to exactly half of the screen. But that wouldn't solve things for people who have 1:1 displays but don't want to stretch.

My main concern regarding this:
When I'm picking aspect ratio options in most apps/software I typically see the word "Force" used next to a listing. The word does nothing for the imagination and more often than not, choosing the option doesn't do anything useful/what is expected from the user's perspective. Trying to fudge or change the behavior the aspect ratio options is probably not for the best, and wrapping these magic behaviors into them will infuriate people. I'd be satisfied on this particular device if selecting stretch did stretch to full screen, and I'm sure many users would be as well on other devices. But in portrait mode?? when all of my onscreen controls are set up? on my 21:9 phone??? idk.

I see three different ways that this could be handled

Path 0: Tweak Aspect Ratio behavior

This is what you suggested, and is an attempt to not add any settings.
I'd suggest that keeping the default behavior is more important to most users of Dolphin, but it's clear to me that what you suggested would solve the problem for me.
I believe, however, that we shouldn't have this magic behavior alongside with changing existing behaviors. It's gonna piss someone off.
I try to address this in the next path:

Path 1: Pragmatic approach for the long term, which keeps current behavior for all portrait mode users and doesn't add any new settings.

  • Make the Graphics Settings>Aspect ratio setting fully customizable and have the magic half-screen controller region in portrait mode be removed entirely.

and

  • Have the Default behavior to vertically justify content to the top of the screen while in portrait mode.

That way, I'd be able to specify 4:3, auto, or dial in a device specific aspect ratio or even something crazy (such as 21:9, vertical aspect ratio with widescreen hack is still a great novelty!), as well as optionally turn on widescreen hack to prevent stretching and call it a day.
Retroarch (which I'm biased against) actually has an option "Viewport Anchor Bias Y" and another option right next to it with the same name specifically for portrait orientation that controls the vertical centering/justification, so people are already used to or familiar with the concept. I don't think the setting needs to be added immediately, as vertically forcing content to the top of the viewport is already the current behavior "technically"

Path 2: The simple toggle option approach to turn the "magic" option into a real one with the current behavior being the default.

Add a toggle in either...

  • overlay controls (which is an android specific menu) or
  • Config > Interface (android specific, and a perfect place to put it since it's next to orientation forcing options!) or
  • god forbid, the emulator's precious graphics settings>advanced panel (do NOT put it here. It'd pollute emulator settings where people are used to seeing them on other platforms)

to disable the dedicated controller region called "Portrait Mode Controller Region" toggle, then a user would only find it when they need it and the experience would be otherwise not impacted.
a note: The full featured approach would be to add a "Landscape Mode Controller Region" toggle defaulted to off as an option as well, but I don't think anyone's asked for that.

Thanks for your time.

Updated by JosJuice 8 months ago Actions #3

I don't fully understand your "path 1". What do you mean by making the aspect ratio "fully customizable"? Would this include customizing where on the screen the image should be centered?

Updated by JackWitherell 8 months ago Actions #4

JosJuice wrote in #note-3:

I don't fully understand your "path 1". What do you mean by making the aspect ratio "fully customizable"? Would this include customizing where on the screen the image should be centered?

Updated by JackWitherell 8 months ago Actions #5

last message posted by accident.

JosJuice wrote in #note-3:

I don't fully understand your "path 1". What do you mean by making the aspect ratio "fully customizable"? Would this include customizing where on the screen the image should be centered?

Currently there are only four options for aspect ratios. Auto for game reported aspect ratio, 4:3 and 16:9 for forcing modes and stretch for full viewport. If we could specify a custom aspect ratio, then the screen size behavior could simply fill a region horizontally and content could be vertically justified to the top of the screen in portrait mode.
Why not allow custom aspect ratios? some games use uneven aspect ratios when displayed on a crt such as 1.263:1 (animal crossing) and 1.183:1 (smash melee)

Updated by JackWitherell 8 months ago Actions #6

Dolphin for other platforms already allows for custom aspect ratios in settings and also in Game.INIs

Updated by JosJuice 8 months ago Actions #7

Right, there are "custom" options that exist in Dolphin but haven't been implemented in the Android UI (simply due to a lack of time/developers). But this doesn't in itself change the fact that portrait mode only uses the top half of the screen. So I assume then you're suggesting that an additional change is done in addition to adding the custom aspect ratio option? Could you please describe that change more clearly? I saw that you wrote "If we could specify a custom aspect ratio, then the screen size behavior could simply fill a region horizontally and content could be vertically justified to the top of the screen in portrait mode", but should this affect all aspect ratios, or only the custom ones?

Updated by JackWitherell 8 months ago Actions #8

JosJuice wrote in #note-7:

an additional change is done in addition to adding the custom aspect ratio option? Could you please describe that change more clearly?

I specified the additional change that would be required here:

Have the Default behavior be to vertically justify content to the top of the screen while in portrait mode.

What I'm suggesting is that content be vertically justified to the top of the screen instead of designating a viewport consisting of half of the screen.

See attached

Updated by JosJuice 8 months ago Actions #9

Right, but what do you mean by it being the default behavior? Would there be a way to make it not be vertically justified to the top of the screen?

Updated by JackWitherell 8 months ago Actions #10

JosJuice wrote in #note-9:

Right, but what do you mean by it being the default behavior? Would there be a way to make it not be vertically justified to the top of the screen?

What I mean by making horizontal fit and upwards vertical justification the default behavior is by making it the way that the app behaves by default. I really don't know how to elaborate further. Default behavior doesn't imply the presence of additional settings or a way to make the screen not vertically justified to the top of the screen.

I see no reason to create an option to control vertical justification while in portrait mode if your priority is to eliminate the need to add additional settings to the app. I see path 1 as a suggestion and not the best possible option for improving the app. It prioritizes keeping behavior similar to what currently exists while generally improving it. I see the worst case scenario in implementing path 2 being a user with a device aspect ratio close to 4:3 who feels like there's not enough space underneath the viewport to organize their controller overlay, and I see this as not much of an issue because control overlay opacity, size and location are already fully customizable.

Path 2 is the ideal path. Currently, users have No control over the placement, scale and position of the emulator while in either landscape or portrait mode. There are easily two equally appealing locations where a setting could be added to control whether or not an onscreen controller region is allocated, and I believe that this would be the ideal option long term. Path 2 prioritizes app functionality and user experience. Path 1 simply prioritizes not adding settings that don't already exist in dolphin main and improving utilization and simplifying behavior of the app. Path 0 prioritizes not adding any new settings whatsoever by simply modifying existing app-specific behavior.

Honestly I'm going to have to defer as to which one would be feasible to implement.

Updated by JackWitherell 8 months ago Actions #11

I think it's safe to say that the app's current design already has a very hard and strong assertion that if a user is playing in portrait mode, then a region below the gameplay view should be designated for onscreen controls. What I'm suggesting is that if you're insisting that new settings being added should be kept to a minimum, then at the very least there should be a way to allow a user to decide whether or not that space should be able to be reclaimed.

If it were up to me, there'd be a button to disable the onscreen controller region right next to the opacity slider. That's all the value I've got left to suggest.

Updated by JosJuice 8 months ago ยท Edited Actions #12

What I mean by making horizontal fit and upwards vertical justification the default behavior is by making it the way that the app behaves by default. I really don't know how to elaborate further. Default behavior doesn't imply the presence of additional settings or a way to make the screen not vertically justified to the top of the screen.

I think we interpret the word default slightly differently then. Either way, with that clarification, your suggested path 1 is something I would be happy to go with. Even if at some later point we would want to add a setting just for this, I think having a setting that toggles between path 1 and always centering makes more sense than a setting that toggles between what Dolphin currently has and always centering.

Actions

Also available in: PDF Atom