Change default mappings between retropad and mgba core

[fekir]

As far as I've understood, the core itself is responsible for the default mappings between retropad ad the core, if not, sorry

Currently the mapping between retropad and a game boy advance looks like

|===
|Retropad (input) |Game Boy Advance (game)
|A                |A
|B                |B
|X                |A
|Y                |B
|L                |L
|R                |R
|Start            |Start
|Select           |Select
|D-Pad            |D-Pad
|Retroarch Menu   |
|===

I would like to propose to map the button X,Y to L,R as there are remotes that do not have buttons mapped to the L,R button of retropad, but have the same amount of buttons as a game boy advance: the wiimote.

With the proposed change, the table (with additional column for the wiimote) looks like

|===
|Wiimote (input) |Retropad (input) |Game Boy Advance (game)
|2               |A                |A
|1               |B                |B
|A               |X                |R (instead of A)
|B               |Y                |L (instead of B)
|                |L                |L
|                |R                |R
|+               |Start            |Start
|-               |Select           |Select
|D-Pad           |D-Pad            |D-Pad
|HOME            |Retroarch Menu   |
|===

and all GBA games can be played with a remote

As far as I could observe, all controllers that have buttons mapped to retropad L,R (dualshock, snes, ...) also always have the equivalents of the buttons mapped to A,B,X,Y, and all controller that have X,Y seem to have L,R; the wiimote is the only exception I could find.

This is to say I could not find any controller that has the retropad buttons X,Y,L,R but not A,B, and thus where the proposed mapping would not make it possible to play game boy advanced games that use the A,B buttons.

On the other hand, changing the current mapping between wiimote and retropad would break some scenarios; for example snes games that do not use L,R but use X,Y.

[hizzlekizzle]

As mentioned here: libretro/Genesis-Plus-GX#369 (comment), this sort of thing is typically handled by remapping in the frontend.

[fekir]

After the discussion in libretro/Genesis-Plus-GX#369, I gave a look at the code.

I believe it should be sufficient to change in src/platform/libretro/libretro.c in the function retro_init, following lines

		{ 0, RETRO_DEVICE_JOYPAD, 0, RETRO_DEVICE_ID_JOYPAD_X, "Turbo A" },
		{ 0, RETRO_DEVICE_JOYPAD, 0, RETRO_DEVICE_ID_JOYPAD_Y, "Turbo B" },

to

		{ 0, RETRO_DEVICE_JOYPAD, 0, RETRO_DEVICE_ID_JOYPAD_X, "R" },
		{ 0, RETRO_DEVICE_JOYPAD, 0, RETRO_DEVICE_ID_JOYPAD_Y, "L" },

although I have to ask; what are the turbo buttons, and is it problematic not having them mapped by default?

[hizzlekizzle]

They're buttons that automatically fire rapidly when held. There is a frontend-based turbo function in RetroArch, but having these permanent buttons that are remap-able was a common request prior to implementation.

The only real issue I can think of with putting gba-L and gba-R on retropad-X and retropad-Y is that we typically map buttons based on physical similarity to the original input device, with L and R on the shoulders of a GBA console. By this logic, those buttons would also live on the shoulders of a typical gamepad.

Of course, anyone who wants those functions moved elsewhere can do so through input remapping (in RetroArch, at least).

[endrift]

The turbo buttons should be removed from the core; they didn't really belong there in the first place, and since the frontend has the feature now there's no reason it should stay in the core. It adds confusingly misnamed buttons to interfaces generated on the list of buttons.

[fekir]

The only real issue I can think of with putting gba-L and gba-R on retropad-X and retropad-Y is that we typically map buttons based on physical similarity to the original input device, with L and R on the shoulders of a GBA console. By this logic, those buttons would also live on the shoulders of a typical gamepad.

I understand this concern.
Unfortunately it is not possible to do controller/retropad/core specific bindings (with that I mean specific bindings between the controller and retropad depending on the core).

(Plus it seems that there are already exceptions to this guideline, for example the sega genesis 6 button controller)

As far as I know there is no controller that has the retropad buttons L,R but not X,Y, and at least one that has X,Y but not L,R...

Of course, anyone who wants those functions moved elsewhere can do so through input remapping (in RetroArch, at least).

Yes, this is what I am doing right now, nevertheless I'm still convinced that having it by default would be better, as it provides a better experience out of the box, which is the main point of the automapping functionality.

[RenanSD007]

The turbo buttons should be removed from the core; they didn't really belong there in the first place, and since the frontend has the feature now there's no reason it should stay in the core. It adds confusingly misnamed buttons to interfaces generated on the list of buttons.

Turbo on Core is better, you can put the Turbo A and B buttons on different buttons on the controller/overlay for example and also RetroArch Turbo Mode doesn't seem to work with Overlay buttons (and even if it worked, it would still be terrible to use, having to switch/hold to use a button is very annoying)

[endrift]

What you have described is frontend issues that are just frontend issues that should be worked out in the frontend. Layering violations like turbo in the core are just technical debt. It does not belong in the core from an architectural perspective and it's only there as a hack. It does not belong in the core.

[RenanSD007]

If the Frontend has options to do the same (like mapping separate buttons to Turbo) and supports Touch (Overlay) buttons instead of just Controller, For me, there would be no problem in removing the Turbo buttons from the Cores, but until this is resolved it would be good to keep the Core option (which also is available in NES cores)