Re-add and improve methods to get the name of gamepad inputs

[YeldhamDev]

• Readd get_joy_axis_string(), now with the extra parameter value.
• Readd get_joy_button_string(), now with the extra parameter scheme.
• Add the new get_joy_scheme(), to detect what button layout the gamepad has. Can be used with get_joy_button_string().

Closes godotengine/godot-proposals#6930.

[YeldhamDev]

Changes made.

[Mickeon]

I don't know how to feel about this. On one hand it is great to have these names and "schemes" natively. But on the other, it's a bit... prone to be superfluous? I hope I do not sound mean in any way.

After this is merged we are going to get more requests.
Users know there's many controllers out there, and that supporting them all natively is just not possible. But, what about the GameCube controller (which is still loved by many), other pseudo-retro controllers, or even the Steam Controller?

Plus, what about localization? The PR as is cannot localize these, which kind of defeats the purpose. If the need is for controller icons, only get_joy_scheme is necessary here.

All in all, to try and make it brief, I feel like this can be done with custom code or specialized addons much better for the following reasons:

• Users that do not need it simply ignore them;
• They would not bloat the core engine;
• They can be designed for more specific controllers;
• They can easily be expanded upon in the future (even for older versions of the engine).
• The provided strings can be localized as the developer wishes to.

[YeldhamDev]

I don't know how to feel about this. On one hand it is great to have these names and "schemes" natively. But on the other, it's a bit... prone to be superfluous? I hope I do not sound mean in any way.

I disagree. On my own game, the name of inputs is used on its keybinding settings, I rely a lot on get_keycode_string(), and used to rely on get_joy_button/axis_string() methods too before they were abruptly removed.

After this is merged we are going to get more requests.
Users know there's many controllers out there, and that supporting them all natively is just not possible. But, what about the GameCube controller (which is still loved by many), other pseudo-retro controllers, or even the Steam Controller?

You talk like new controller schemes are made all the time, they just sticky to preexisting ones.

The GameCube controller also uses the same names for it's buttons as the other Nintendo controllers (but thanks for reminding me, I should add it to criteria in the Nintendo scheme), and the Steam controller uses the same as the Xbox ones.

Plus, what about localization? The PR as is cannot localize these, which kind of defeats the purpose. If the need is for controller icons, only get_joy_scheme is necessary here.

With the exception of the generic names, the others mainly uses letters for them (LT, ZL, etc), there's barely anything to localize. And for the few that could need, nothing stops users from localizing them. I do localization for some key names returned by get_keycode_string(), for example.

• They would not bloat the core engine;

This is hardly bloat...

• They can be designed for more specific controllers;

The generic names can suffice for the niche controllers for most people.

• They can easily be expanded upon in the future (even for older versions of the engine).

I'm not sure what point you're trying to make here.

[akien-mga]

CC @Riteo who seemed interested in this kind of feature (in Wayland context, but well, it's adjacent :)).

[Riteo]

Ooooh yeah this is some interesting stuff, thanks @akien-mga for the ping :D

As akien pointed out, I was personally interested in adding a proper controller support on Wayland (like, way upstream) and discussing about the hypotethical Godot APIs for that.

I have not researched much on the subject yet so TIWAGOS in regards to what I am about to say.

Joystick parsing is a very big mess and the only reliable way I've seen to detect the right controller is to use the actual native driver when possible (I think it's called HIDAPI on windows), which is the approach used by SDL. In a pinch, name parsing should work good enough as we already depend on a special joystick DB after all.

What I don't completely agree on is the fact that the controllers' schemes are bound to some very generic enums: I'd much prefer, personally, to have lots of entries explaining different controllers than a few minimalistic ones, like JOY_SCHEME_SONY_PS3, JOY_SCHEME_NINTENDO_GAMECUBE and so on.

Yes, controllers are all very similar, but if they have clearly distinct feature-sets or shapes (considering compatible designs as simple reimplementations of said "standards"), then we should enumerate those, even just for visualization purposes (think about of the old-school picture-of-a-controller rebinding screen).

IMO bloat is a minimal concern, as we're adding just a bunch of string checks and a few enums. Plus, being the keycodes the same by definition (they have some loose semantic association IIRC), we could just keep the three string maps and call it a day, simply associating all the JOY_SCHEME_NINTENDO_* enums to the same map and so on.

Edit: In short, I really like this feature, although I'd make the joystick enum way more descriptive, like SDL does: https://github.com/libsdl-org/SDL/blob/fb87f8f15c11477f294b6486f967ea167dcc20d6/src/joystick/controller_type.h#L43-L60

[YeldhamDev]

@Riteo I like the idea, but nothing stops us from expanding the JoyScheme enum when the need arrives, with the current ones serving as a fallback of sorts.

[Riteo]

@YeldhamDev I'm not exactly sure on how we'd use the generic fallbacks. Could you please elaborate a little bit more?

[YeldhamDev]

I mean like if we could identify that the gamepad uses a Xbox scheme, but not pinpoint what controller it exactly is.

[Riteo]

@YeldhamDev if we have an heuristic for that, I suppose we could have some enums akin to JOY_SCHEME_NINTENDO_GENERIC (and so on).

Not exactly sure how we'd figure that out though 🤷

[YeldhamDev]

Not exactly sure how we'd figure that out though 🤷

When we can't check the driver in the platform for whatever reason, but we can still use our list for the name, which it's how the PR works.

I suppose we could have some enums akin to JOY_SCHEME_NINTENDO_GENERIC (and so on).

I don't think the suffix _GENERIC is really necessary, since they are the only ones currently available it would look awkward, even if it would be a form of future proofing.

[Riteo]

@YeldhamDev

I don't think the suffix _GENERIC is really necessary, since they are the only ones currently available it would look awkward, even if it would be a form of future proofing.

Well, I think that we should definitely add more precise enums, so if we don't do that now I think that we should keep the generic suffix.

[YeldhamDev]

@Riteo Alright, what do you think of the new names?

[Riteo]

@YeldhamDev yeah, that's what I was thinking of :D

Sorry if I came as too aggressive.

[Rubonnek]

This PR also partially implements godotengine/godot-proposals#8519, Input.get_joy_type() in that proposal is equivalent to Input.get_joy_scheme() in this PR.

The difference is an implementation detail -- proposal #8519 suggests the use of the vendor and product IDs provided by the joypad in order to identify its button layout. I agree with that implementation since it seems more correct and precise at the same time. Currently Godot is able to extract the vendor_id and product_id but only on Linux through Input.get_joy_info() merged back in #78539. I've opened a PR to include the Windows implementation to extract and expose those IDs on #91539 and if merged, only Mac will be missing, but seems plausible to do the same on Mac.

That said, if we were to implement Input.get_joy_scheme() that way, we'd need a vendor_id and product_id database that maps each joypad to its button layout type, and here are two I've found so far by going over the proposals:

• https://github.com/libsdl-org/SDL/blob/main/src/joystick/controller_list.h
• https://github.com/JujuAdams/Input/blob/community-data/community_gamepad_type.txt

We could massage the data to create an ID for each controller the same way SDL does it, and have that ID map to a specific scheme.

I don't think we should compile those databases into the engine because users needs may differ vastly and for some devices there seems to be no way to tell the button layout and overall it seems best served as an addon, but at the same time it also seems trivial to include an scons option to avoid compiling in the joypad scheme database for those who don't want it included.

That said, including the joypad scheme database within the engine by default could also be beneficial for everyone in the gamedev community -- it gets more eyes on this functionality and as a community we could slowly build a better joypad scheme database. It would also be nice to have a centralized FOSS joypad scheme database every other engine could use. I don't know if there's any specific database used by many engines currently, but regardless in mdqinc/SDL_GameControllerDB#692 (comment) offalynne, the maintainer of community_gamepad_type.txt linked above, also expressed interest in breaking out that database into its own project which would be a nice to have.

[Riteo]

@Rubonnek

it gets more eyes on this functionality and as a community we could slowly build a better joypad scheme database. It would also be nice to have a centralized FOSS joypad scheme database every other engine could use.

IMO it gets even better in the long term. In *nix land, there is work for a Wayland protocol allowing the window manager itself to translate, tunnel and report the type of controller data being sent directly into a window (i.e. no manual device reading): https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244

In other words, in the long term, for certain platforms, game engines won't even have to worry about this whole mess in the first place, as controllers will become a regular input device.