This isn't an existing bug, but it would be a massive quality of life improvement to toggle the prominent screen at will in-game when using the Citra core.
To be able to go into Quick Menu >> Controls and map any given key to the swap screen function.
This isn't actually a RetroArch request, but rather a Citra-libretro request. As such, it's more likely to get some traction if you open the issue at the core's repository:
https://github.com/libretro/citra/issues
Lol, selby closed it because he thought it should be handled at the
frontend :P
On Tue, Jun 26, 2018 at 12:34 PM hizzlekizzle notifications@github.com
wrote:
Closed #6924 https://github.com/libretro/RetroArch/issues/6924.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/libretro/RetroArch/issues/6924#event-1702059279, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABpC0G9KX5Ay-qRQxerUYxqMJ8KHRd4_ks5uAnCxgaJpZM4U356p
.
So you fellas see this as a backend and they see it as a frontend issue. Who should I talk to, then?
oh lol ok...
Well, I see it as a core issue because A) you can assign the core functionality to a retropad button (I assume this has not been done yet and needs to happen in the core) and then B) that button can be mapped in the frontend (already done).
Am I missing something? I'll reopen the issue either way :)
Core options can't be mapped to hotkeys so it can't be a core option, it could be added in the core as a retropad button then it would "just work"
Looking at the core options, it seems there's already a layout option and then another option to swap the screen locations. I think the screen location swap should just move to a hotkey.
That might be within my abilities...
Hey, thanks, hizzlekizzle! I appreciate it.
@fr500 We are out of RetroPad buttons. L3 is used for touchscreen click, and R3 is reserved for multiplayer menus/etc. This should be a frontend issue, as it shouldn't be the cores responsibility to update variables which are provided by the frontend.
ah, yeah, I just noticed the lack of available buttons, as well. :( I often wish the retropad had phantom buttons (or additional face buttons or however you want to think of it) that we could assign things to and then remap at runtime...
As for the core/frontend jurisdiction, I don't guess I follow your reasoning. What variables are being provided by the frontend in this case? As I see it, the arrangement is happening prior to handing off the image to the frontend, so it's all settled by the time the frontend gets ahold of it. It would be the frontend's responsibility if the core handed two separate images and the frontend arranged them.
The frontend provides the values, that's what he meant.
Ah, gotcha.
Yeah, it would be nice if core options could have a button assigned to cycle through their values. Core options are clunky in a lot of ways, both in the API and in how RetroArch interacts with them...
So, just to clarify, this can't really be done until the people over in controls bumps up the limit on available buttons, at which point this could be mapped, but ultimately this is requires another feature to implement, is that right?
Well, not necessarily. It could be mapped to an analog stick direction or something else awkward like that (maybe a hardcoded button combo [blegh]), but yeah, having more virtual buttons could do it. However, that would require a modification to the libretro API, and that hasn't happened yet even for more important stuff, so I wouldn't hold your breath on that specific possibility.
I guess my next question is, does this mean I should open this up with libretro instead?
Has anyone come up with a solution to this? For a workaround, is there a config file I can adjust to assign [citra_swap_screen] to a key? At least that way a third party program could be used to map a controller combo. This is the only issue keeping me from completely switching from the standalone application.