New Input Remapping Menu


#1

So, a big change just happened on the input remapping menu:

There are still a few bugs I hope can be fixed:

  • if the device in settings is RETRO_DEVICE_KEYBOARD and now you load a core that doesn’t support keyboard you get the keymapper (this needs to be sorted as a whole in RetroArch, it has been an issue forever)
  • Mapping several inputs to the same action with analogs involved cause unexpected results
  • Mapping the enter key on the keymapper causes it to get stuck in a loop until you press another button. Doesn’t seem to to happen with other keys
  • Mapping some keys on the keymapper prevents those keys from working on the keyboard

What currently works:

  • [x] Mapping keyboard keys from more than one gamepad (works with dosbox)
  • [x] Mapping more than one button to the same action
  • [x] Unmapping buttons
  • [x] Unmapping analogs
  • [x] Mapping a button to trigger an analog response (tested with mupen, can run on SM64 with the d-pad now, triggers a full analog tilt)
  • [x] Mapping an analog to another analog (having more than one analog mapped to the same output causes issues)
  • [x] Mapping an analog to produce a button response

The most important functional change is that it swaps over the columns so the keymapper and the gamepad mapper follow the same layout:

Gamepad Mapper

Keyboard Mapper

It was not done for pure aesthetical reasons or consitency, but because the GUI itself allows more flexibility. Anyway, I’ll be paying close attention to the post and to this PR for any other issues that may creep up


What's up with the new quick menu controls remapping?
Re-configuring all the remap files is a pain
#2

#3

awesome! this sounds like it would fix the various n64 binding issues some have.

does this change hotkey functionality at all? eg https://forums.libretro.com/t/using-hotkey-combos-and-dedicated-buttons


#4

Nope, actually I’ve been thinking about combos and turbo. They way I would do it is add extra buttons to the right column for extra inputs say combo1…combo16 (16 should be enough give me a break) and another one that is a turbo level toggle.

Combo buttons would trigger pre-made combos, it would be pretty trivial to implement a function that rewrites input to trigger the combo. Creating the gui for that… not so much.

As for turbo, my idea for turbo is 3 turbo levels, and a “hotkey” that you press with any other button to increase that level.

So hotkey + a = turbo a lvl1, turbo + a again, turbo a lvl2, etc.

Still all of those ideas are still in the thinking phase, nothing to show as of now.


#5

‘hotkey + button = turbo button toggle’ is the current behavior isn’t it? I think most people who aren’t happy with that behavior want something like:

  • core button - retropad button
  • core button turbo - retropad button
    • core button turbo cycle rate - 1/2/3

#6

AFAIK the current toggle is fixed and also it “forgets” turbo once the button is released We could have extra buttons like what I suggested for combo, the way it could work is there would be turbo a b x y, etc with configurable levels, and then you’d have to use the remapping menu to configure what physical button triggers each.

That may not scale for anything with more buttons that a NES though :stuck_out_tongue: you need a pad with a fuckton of buttons in that case


#7

@radius there is a bug that when you modify your inputs when a core is loaded and then you use the option “save core overrides” your inputs reset to the ones set when there was no core loaded.


#8

Overrides don’t save bindings. I couldn’t figure it out and probably never will. There is a dedicated menu for remapping which is what was being discussed here. Use that instead.


#9

It seems with the new input mapping the controls quick menu remapping is limited to how many buttons the emulated console has, for instance using gambatte core you can’t remap the B button to any other button on your gamepad like X or L and R only to A:

Is this the intended behavior or am I missing something? It seems like a big oversight not to have the ability to remap buttons per core or per game to any button you want on your gamepad regardless of the emulated system number of buttons.


#10

I have no idea if what you mean. Left column has all the physical buttons of your pad.

Right column all the buttons the core has.

You can remap all physical buttons to core buttons just fine.

They are just unmapped by default as they should


#11

…Nevermind guys, nothing to see here just me being an idiot and not understanding the new menu.


#12

Just recently updated to the latest Android version and I’m having a problem with input remapping. I have an 8bitdo SN30 Pro, and previously have remapped buttons in Nestopia as follows:

gamepad B -> console A

gamepad Y -> console B

gamepad A -> console Turbo A

gamepad X -> console Turbo B

In the new version of Retroarch on Android (1.7.2), not only does my remapping appear to be reverted to defaults in the new core input remapping menu, but it won’t respect my remapping even after changing it back to the way I had it originally.

To be specific, upon starting up the new version of Retroarch , my Nestopia remaps were changed back to the defaults:

gamepad B -> console B

gamepad Y -> console Turbo B

gamepad A -> console A

gamepad X -> console Turbo A

After changing these settings BACK to my original settings prior to the new Retroarch version, Nestopia appears to be totally ignoring my remaps.

FYI, I’m testing this all out using the the “virtual” retropad on-screen overlay because I don’t have my 8bitdo handy at the moment. I don’t think it should matter…


#13

Overlays aren’t affected by remaps, AFAIK.


#14

The overlay used to be affected by remap.

i.e. Each button on the virtual retropad overlay used to correspond to same named physical button on my 8bitdo, NOT to the core console buttons. That is WHY its a virtual retropad.

It is for this reason that, in the absence of my 8bitdo pad, I use the default retropad overlay rather than a NES specific overlay that only has the A and B buttons. If I used the latter, this would correspond to the retropad A and B which I had remapped to Turbo A and A respectively (i.e. no effective B button).

My understanding has always been:

Global input binds map physical buttons/keys to retropad.

On-screen overlay buttons are effectively virtual retropad buttons.

Per-core remppaing maps retropad buttons (either physical or on-screen virtual) to console-specific inputs.


#15

Can confirm that the touch overlays are not affected by the controls input remapping and they used to, made it easier to play on touchscreen, any way to bring that back?


#16

I’ll have to take a look I didn’t even consider that. No ETA though


#17

LOL yeah it happens, but the new interface should be easier to understand too. The issue is that you were probably used to it so you didn’t really consider the change :stuck_out_tongue:

Glad that it works


#18

So, is this is a problem that is going to be corrected or not? The previous behavior made a lot of sense (.i.e. on-screen buttons are virtual retropad buttons, not direct console buttons).


#19

Relax, I am sure they’ll fix it, the RetroArch team always delivers also I saw an issue already on github about that:


#20

Yup, I saw that too.