Increase JOY_NUM_BUTTONS to 128 and add required localizations

[derrickturk]

I want to put this out as less of a "pull request" and more of a strawman or question from a drive-by contributor - is this worth doing? Are there non-obvious downsides (performance? backward compatibility with old pilot profiles [maybe the movement of the hat switch identifiers has bad implications]? etc.).

Bumping the joystick button limit to match what I understand to be the maximum allowed by DirectInput (plus the now excellent multiple-controller support) would be a big help for those of us with "fancy" HOTAS setups. Many mid- and high-end controllers support acting as multiple "virtual controllers", but for at least some this doesn't work with FS2Open due to each "virtual controller" having the same identifiers.

[Baezon]

Have you tested whether this is sufficient to actually use buttons past 32? I assume you have such a joystick?

[derrickturk]

Yes, it's worked fine with my setup (joystick + a separate throttle with ~100-odd buttons) on "my machine" (Windows 10, build from above patch on MSVC 2022, MediaVPs, Knossos.NET) in limited playtesting. I don't have the capability at the moment to test much beyond that.

[JohnAFernandez]

So it sounds like it fixes issues for joysticks with near the max number of buttons, so I think we just need someone to test the converse: that joysticks with fewer buttons (and mice and keyboards) still work with these changes.

[z64555]

I had wanted to use the button name translation procedural instead of manually defining a name for each one as done here, but I suppose this is still acceptable for now.

I checked SDL's wiki to see if they had a recommended button limit but I didn't come across such a thing. It holds its numbers as a uint16_t and there's the possibility that somewhere in FSO they use the button array as a char or uint8_t. In either case the value 128 is well within the limits of the data types so I don't forsee any conflicts.

For completeness sake, we should pause merging until somebody with a more baseline joystick or controller is able to confirm that the changes don't break anything, as @JohnAFernandez suggested.

[derrickturk]

Awesome, I may be able to do some testing with a Saitek Cyborg Evo (~10 buttons, IIRC) when I get back from some work travel.

[derrickturk]

@z64555 what did you have in mind for a procedural translation? I like the idea but didn't feel comfortable either going from static arrays to a lookup function or introducing some kind of metaprogramming (templates or macros) to generate the static arrays. That second option is the way I would lean but I am a total rando to this codebase!

[JohnAFernandez]

Hey, I'm just converting this to draft until we figure out if we want to make the string generation dynamic or not, so that no one merges it by accident. I'm good with it being static.

[derrickturk]

I summoned something from the dreaming void. It appears to be valid C++20: https://gist.github.com/derrickturk/51c68fb15cbf82211dc4c812832487b3

I think there may be an even shakier, standards-wise, way to "count" using the preprocessor, but it's beyond me. At most I'd probably use an "X-macro" to simplify the generation of arrays entries, like so: https://gist.github.com/derrickturk/2e26b18de7f075b0b069bae63ec24df8. At least that keeps the "counting" simple and in one place, although it introduces the requirement to make sure that the count constants get updated concurrently with the definition list. I think keeping it as is would be just fine too and possibly the least confusing option for most programmers.

[derrickturk]

I guess I should elaborate that the above techniques are both "static" in the sense of operating at or before compile-time and generating honest-to-god constant arrays. There would be a whole other set of approaches for generating these at runtime - probably simpler to program but at the expense of a tiny bit of performance and complexity (when do we initialize them, etc etc).

[JohnAFernandez]

I don't think we'd be able to upgrade to c++ 20 just for this. We do have some c++ 17 features added via small libraries, but we're targeted to c++11 for now. I don't think anyone would object to adding a library to manually add a c++20 feature. The choice is up to you and @z64555 on whether that's worthwhile or not.

[derrickturk]

IMO it's not worth it for the metaprogramming here - I've blown up several "C++20" compliant compilers with similar code (the core idea comes from a named-tuple implementation) so it's a bit "bleeding edge".

My personal comfort zone would be using an X-macro to keep the arrays global, static, and constant, but I don't see that pattern elsewhere in the codebase and I'd be reluctant to throw it in here as a one-off unless it's well-known to other developers.

Probably the best answers, again IMO, are to keep things as is, or perhaps introduce a singleton like io::mouse::CursorManager which generates the tables dynamically once and gets initialized "early" with a static init() function.