[Feature request] libretro api : possibility to assign more retropad buttons

[barbudreadmon]

This is kind of a duplicate of a request i did last year (#8209) because the goal is basically the same.

It is also kind of a duplicate of #6718, with a somewhat different goal in mind since that old issue was more about hiding buttons to not have them sitting randomly all around the place.

Currently, when creating input descriptors before sending them to retroarch, we are limited to assigning to those buttons/axis :

#define RETRO_DEVICE_ID_JOYPAD_B        0
#define RETRO_DEVICE_ID_JOYPAD_Y        1
#define RETRO_DEVICE_ID_JOYPAD_SELECT   2
#define RETRO_DEVICE_ID_JOYPAD_START    3
#define RETRO_DEVICE_ID_JOYPAD_UP       4
#define RETRO_DEVICE_ID_JOYPAD_DOWN     5
#define RETRO_DEVICE_ID_JOYPAD_LEFT     6
#define RETRO_DEVICE_ID_JOYPAD_RIGHT    7
#define RETRO_DEVICE_ID_JOYPAD_A        8
#define RETRO_DEVICE_ID_JOYPAD_X        9
#define RETRO_DEVICE_ID_JOYPAD_L       10
#define RETRO_DEVICE_ID_JOYPAD_R       11
#define RETRO_DEVICE_ID_JOYPAD_L2      12
#define RETRO_DEVICE_ID_JOYPAD_R2      13
#define RETRO_DEVICE_ID_JOYPAD_L3      14
#define RETRO_DEVICE_ID_JOYPAD_R3      15

...

#define RETRO_DEVICE_INDEX_ANALOG_LEFT       0
#define RETRO_DEVICE_INDEX_ANALOG_RIGHT      1
#define RETRO_DEVICE_INDEX_ANALOG_BUTTON     2
#define RETRO_DEVICE_ID_ANALOG_X             0
#define RETRO_DEVICE_ID_ANALOG_Y             1

Which means we can assign 24 different actions to a retropad controller (including its sticks), in most cases this is plenty, but i've found some cases where being able to map more actions would be awesome, those actions don't need to be mapped to an actual button when starting a game for the first time, they just need to exist as a choice when remapping through "Quick Menu > Controls".

My idea would have been to have those new entries in libretro.h :

...
#define RETRO_DEVICE_ID_JOYPAD_L3      14
#define RETRO_DEVICE_ID_JOYPAD_R3      15
#define RETRO_DEVICE_ID_JOYPAD_FAKE1   16
#define RETRO_DEVICE_ID_JOYPAD_FAKE2   17
...

Then when developping a core, you could assign an action to the RETRO_DEVICE_ID_JOYPAD_FAKE1 id, that action wouldn't be mapped to an actual button by default, but would be available to be mapped wherever the user want when going into "Quick Menu > Controls".

For a core like FBNeo, it would be a huge improvement since i could declare all kinds of macro/autofire actions (which already exist in the codebase), but also weird cabinet inputs that need to be mapped somewhere sometimes, which is why i largely prefer this over the macro mapper.

note: i said 24 actions but tbh it's more like 16 actions, because remapping a non-directional action assigned by default to a stick's direction is extremely clunky. 16 is extremely limited and for the record not sufficient for a machine like the coleco which has 18 keys on its joystick.

note 2: a retired dev made that statement:

I think the only way to add these extra inputs is to define a whole new input device type - something analogous to the current keyboard device, but just a generic 'button bank' with an arbitrary number of indexed buttons (128 or something). These could then be labelled and used however the core wants, and the frontend could map any of them to the existing retropad inputs (like we do currently with 'virtual' keyboard keys).
So someone needs to implement this 'button bank' device type - i.e. copy/paste the current keyboard type, but instead of having pre-defined 'key' inputs, make every input generic and assignable core-side (so then each of these core-assigned inputs can be mapped to retropad inputs in the frontend, like you can currently do with keyboard inputs)

[i30817]

As long as these extra buttons or macro assignments are disabled in netplay/hardcore mode.

[barbudreadmon]

@i30817 why ?

[i30817]

cheating in competitive games for the first, and the second already disables savestates/cheats.

[barbudreadmon]

what do you mean by cheating ? having a button that press 2 different buttons at once is cheating ? you know that you can do that through gaming hardware or third-party application ? the only thing this libretro feature would do is leverage macro support

[i30817]

Configurable macros are cheating. For the most obvious example, imagine someone that makes a macro for supermetroid 'infinite bombjumping' (i did this in zsnes way back then). Then it's just 'Press button to trivialize sequence breaking'.

Adding macros accessible to hardcore mode or netplay is 'cheating people care about': thus, disabled then.

Anyway there is another problem, even if the core upstream supports macros, RA controllers would probably not.

Basically you're asking for something that requires RA/libretro to get back information from a core, ie: 'these are my macro shortcut slots, what macros do you have available' to then present to the user before choosing for the core to go 'ok macro button pressed with macro XYZ i know about, execute macro XYZ'.

The problem here is that the user has no way to make his own without going to the upstream GUI or knowing the fileformat of upstream macros; ie: the big payoff is if the frontend itself has a configurable macro GUI/language (to copy paste), so even cores that don't 'support' macros get them and so that libretro isn't forced to support a api to 'ask about macros available' that doesn't actually help users write macros in the core format so you still need upstream.

[barbudreadmon]

Configurable macros are cheating

This issue isn't about configurable macros, it's about macros pre-defined in the core's source code, i'm only interested in having the macro already defined in fbneo's source code available in the libretro port, none of them is fancy, it's mostly things like having the button to press 3xPunchs or 3xKicks in vs-fighting games. As for other cores, their maintainers will decide what they want to do with this feature.
And anyway, as i said, not having configurable macros in retroarch doesn't prevent the user from creating his own through third-party software/hardware.

[leoxxx]

I don't think it's a cheating. Flycast no macros, Flycast Dojo add macros and give all combinations which you can set. It is convenient for players to play games.

[i30817]

Agree to disagree. The very fact a obscure function gives a undeniable advantage to one of the participants is cheating. The fact that is allowed on 'flycast dojo' (whatever that is) makes newbs likely to be decimated by combos that the opponent is essentially initiating by pressing a button, and leaderboards dominated by those kind of players. Cheating again.

If retroarch is going to advertise online gaming and a 'hardcore mode' they better disable that, maybe with a option for 'both' participants of a match to set to on if they agree to it and a record for the 'hardcore mode' that the person was using combos so it can be disregarded in leaderboard bragging.

[barbudreadmon]

The very fact a obscure function gives a undeniable advantage to one of the participants is cheating.

What are you even talking about ? A button being a shortcut to press a combination of buttons (let's say B+C+D on neogeo) available for all participants is "an undeniable advantage to one of the participants" ? Because, again, this is what this feature request is about. Those shortcut buttons are even available by default in more recent fighting games, and console ports of those games we are talking about (kof, ...).

On the contrary, not having this feature could give an undeniable advantage to the participant who can handle it by other means (3rd party software which might be os-specific, ...).

It's also something that is apparently of practical use for physically disabled people, i remember one such person posting on FB's forum years ago.

[i30817]

If the idea is to share shortcuts obligatorily there would have to have a way to make people agree with the shortcuts, which will not be implemented - especially in 'retroachievements' but certainly in netplay too (it would be hard to make sure/present the information that this guy is using a one button combo and it would segment the possible players too), unless something is implemented in the room joining ui to say 'combs allowed' or 'combos not allowed'.

Instead what 'i'm talking about' is the obvious thing that will result. People that know about the combos and use them will have a advantage and dominate the retroachievements and netplay because 'sharing' shortcuts will be implemented at a individual level and screw the other guy if they happen to not do it. It's 'their own' fault not knowing all the tools/using their advantage right. I don't trust the 'honor' system in competitions.

Your point about external tools is well made. If the situation already exists, might as well formalize it anyway... but people have been asking for combos (for individual non-netplay/leaderboard) games for years, and it hasn't happened.

Anyway, good luck with your RFE.

[barbudreadmon]

I understand your point, however i don't think optimizing your layout is akin to cheating neither that those shortcuts gives an undeniable advantage, and i think it's the user's problem if he doesn't use all features libretro gives at his disposal.

Also i think there are far bigger concerns as far as fairplay is concerned: 3rd party tools as i mentioned, but also programmable devices, and someone knowledgeable could even build his own core while modifying the source code to get advantages.

[odditude42]

anecdote in favor of implementation:
for most fighting games which have standard inputs which require multiple buttons, the console ports explicitly support binding those multi-button inputs to a single button. this is done because while hitting two or three buttons simultaneously on a 6-button arcade controller is fairly trivial, it can be incredibly difficult to do on a gamepad.

official tournament play on modern fighting games (generally designed as console-first or console-only) permits using these multi-button bindings without restriction.

therefore, in can be inferred that many the game developers view this functionality as standard, and it should not be considered cheating.

if the functionality is made separate from more generalized macro support (e.g. only support multiple buttons, not programmatic/serialized input chains), this should fit the request without raising cheating concerns.