Retroarch: Input remapping limitations [$10]

[fr500]

1. It doesn't allow remapping analogs to digital and viceversa
2. It doesn't allow keyboard to gamepad remapping
3. Some users have mentioned they would like to be able to have remaps "per-controller" in addition to the current "per-core" and "per-game". I'm not really in agreement with this but it may be good to consider.
4. It doesn't allow unbinding buttons

---

There is a $10 open bounty on this issue. Add to the bounty at Bountysource.

[fr500]

For keyboard to gamepad mapping I think the interface should look like this:

Left side would list the RetroPad buttons (with their autoconf descriptors)
Right side would list the descriptors from the core

SImilar to what I implemented on dosbox:

The current implementation remapping implementation for reference:

I think a new env would be needed for this purpose, one that gets all the possible keys with their labels and offers a GUI similar to core options.

https://github.com/libretro/RetroArch/issues/3028

[fr500]

For gamepads an N-to-1 remapping we have to thing about the GUI, it actually "works" now (if you remap two core buttons to one physical button it works but we need a way to add extra buttons, not just override the current ones)

[fr500]

@papermanzero suggested something like this:

Problem is our GUI is not mouse based and we don't have a way to have a multiple entry list like that.

[fr500]

Maybe remapping should present us an empty list instead, and we can then add a "RetroPad button" and then a coresponding "Core Mapping", then we could add said "RetroPad button" more than once with a different "Core Mapping"

[fr500]

As for analog to digital remapping which was mentioned in https://github.com/libretro/RetroArch/issues/3670 the problem is that each axis on the analogs is composed of two variables, analog stick index and the value (left stick, X for instance). I don't know how could we represent the data to make it work.

I think it would be nice to have each of the 4 analog axes represented individually and split into minus and plus ranges but that would be a huge ABI change and certainly won't be done any time soon.

I really dunno how to solve analog to digital mapping.
Maybe a "meanwhile" solution for mupen would be to have a "different controller" that assigns everything to digital inputs.

[jvook]

Nice, this is very comprehensive.

Maybe remapping should present us an empty list instead, and we can then add a "RetroPad button" and then a coresponding "Core Mapping", then we could add said "RetroPad button" more than once with a different "Core Mapping"

This seems like the best option for 2:1 mapping. I think you mean like a toggle here so you have "Add Retropad Remap... : Retropad Y", and pressing A adds a line with Retropad Y, and pressing it again adds a second line with Retropad Y? Then select down to the newly added Retropad Y (on the left side), and toggle between core inputs? LIke "Retropad Y : Button A". It would need a toggle at the end of the core-provided inputs for "Delete this remap button" that removed the "Retropad Y" line.

It doesn't allow keyboard to gamepad remapping

I didn't really follow this, but you mean mapping Retropad to keyboard buttons, for games that use keyboard as input on DosBOX, etc.? If that's right, wouldn't this be gamepad to keyboard remapping? Or am I misunderstanding it? (not being pedantic, it's just unclear to me). Seems like a great addition from the image you showed.

As for analog to digital remapping which was mentioned in #3670 the problem is that each axis on the analogs is composed of two variables, analog stick index and the value (left stick, X for instance). I don't know how could we represent the data to make it work.

Issue #3670 is not really an analog-to-digital mapping issue. The buttons on an n64 controller are not analog buttons. To be clear, what I have gathered on this issue is that n64 input is a compromise: some users would like to execute the c-buttons on, for example, an x-box 360 pad, which only has 4 face buttons. Other users want to use the right analog stick. So retroarch compromises and sets a hotkey to swap the ABXY on the controller face to the c-buttons, as well as offers analog functionality. But let's not lose sight of the fact that n64 c-button is not analog (gamecube is, but that's not the case here.)

One way of approach the issue in #3670 is to "fix" analog to digital mapping and vice-versa, but that's going down a rabbit hole as you mentioned. Really, the c-buttons probably should not be compromised to a hotkey setup as they are now at such a low level. We have a retropad, and it has tons of buttons and certainly enough to handle the c-buttons on an n64 controller. In my opinion, separate buttons for n64 should be the default, whereas any hotkey-swapping sort of things should be optional. That is more of a power-user option anyway. But something like hotkey swapping could be implemented by the new 2:1 mapping feature as discussed above, where certain cores are configured to send a "hotkey swap" button in addition the core inputs, and then the hotkey swap functions ("e.g., A-button (C-button Up)") are presented as additional core inputs for the user to select (on the right side).

In fact, the secondary swap functionality can be included in the primary core input, because they will have no function unless a user sets the swap button anyway.

To be clear, the compromise here (I think), is that the lack of 2:1 mappings do not allow retroarch to offer a separate "c-button up" to the user when the c-button is also attached the hotkey swap functionality "a-button (c-button up)" (please correct me if I'm incorrect on this point). So, if 2:1 mappings were implemented, the issue would be moot, as such hotkey swap functionality could (and should) be implemented as an optional setup, rather than a hard-coded compromise.

ANOTHER way of solving the issue #3670 would be allowing digital to analog mapping, essentially saying "hey, forget all this stuff about hotkey swapping, just remap your face buttons to the (hacky) analog stick->c-button mappings." This could work, but it's applying a pretty big hammer to a tiny problem. It's not really necessary for this particular purpose but if digital to analog remapping would be implemented then the issue would indeed become moot.

[fr500]

I didn't really follow this, but you mean mapping Retropad to keyboard buttons, for games that use keyboard as input on DosBOX, etc.? If that's right, wouldn't this be gamepad to keyboard remapping? Or am I misunderstanding it? (not being pedantic, it's just unclear to me). Seems like a great addition from the image you showed.

I guess it's a matter of POV, but yeah that's what I mean.

[dankcushions]

mapping analog to digital (and vice versa) would be cool. i did a hack in mame2003 to allow this for a specific scenario: https://github.com/libretro/mame2003-libretro/commit/3c2bcc8fc3c53c53a8130e6f7c4ccdba42fb79ec

it would be better to do this in RA as it adds flexibility and also would allow the analog threshold to be tied in with the input_axis_threshold rather than hard-coded to 0.5 like i have here.

[Tatsuya79]

The easiest way to configure those mappings from a user perspective would be like the input binding menu:
"press the key(s) to map to Retropad A"
3, 2, 1s...

Something like that.
Those really long lists in a single item box are a pain, like with playlists core assignments but that's something else...

[Papermanzero]

Any update on this one. I guess the problematic issue is the layer approach.
Core input -> retro controller input -> real input
Mednafen uses the approach to ask the user: press button for a, press button for b etc.
But you would still have the limitations of multiple key bindings, which would be helpful.

Another possibility would be to map several retropad key to the core input.
The benefit would be to save the keybindings in order to provide for each game specific bindings.
Like loading a shader preset for a game, the user loads a binding preset.

[gingerbeardman]

Adding my voice to this one. It's been an interesting read.

Suggestion by @Tatsuya79 is OK for PC but not OK for consoles where you need to map virtual keys onto the controller buttons, so the mapping would have to be selected from a list rather than being physically pressed.

I've just added to the bounty on this.
edit: bounty removed due to bountysource issues

[Papermanzero]

I would also go for the ppsspp implementation. The mednafen approach is nice, but meanwhile the mednafen guis provide an input mapping ui like evry other emulator.

[fr500]

Shitty bounty pot considering this is one of the most important issues :p
LOL at least I may get my $10 back

I'm about to solve this partially, I am adding a generic keymapper:
https://github.com/libretro/RetroArch/pull/5420

Basically all that this needs is a "controller device" in the core set to RETRO_DEVICE_KEYBOARD. It should not respond to gamepad when set to this device and it should all just work then.

It also allows more than one button to act as a key so... n:1 mapping for keys

[gingerbeardman]

Very cool, nice work. Exciting stuff!

[fr500]

It seems the N:1 thing only works with the polling method not the callback method.