[GamePad] Proposal to remove MonoGameJoystick.cfg

[flibitijibibo]

Back in the early days, when this was a fork of MonoGame still using Tao.Sdl and SDL 1.2, one of the problems with the GamePad implementation was that there was no way to configure joysticks for the required 360 controller layout. For most games using SDL_Joystick, you would just make your own config file using the input index values, blah blah. We've all seen this before.

The solution I made is called MonoGameJoystick.cfg, and until SDL2# came along, this ended up being a pretty good solution. Even better, it was a standard config file for all of my titles, so you only had to configure a single time for all of my games.

Then SDL_GameController came along:

https://wiki.libsdl.org/CategoryGameController

We ended up keeping both controller types, for two reasons:

1. Backward compatibility with previous configurations. I've put a lot of emphasis on this, but the amount of bug reports I get regarding non-controller joysticks in comparison to how often people actually use this seems to be getting more and more overwhelming due to the second point...

2. SDL_GameController wasn't widely adopted yet. This sound stupid now, but back then, configuration was hard to do. There's a controllertest program in SDL's test folder, but you have to build/distribute that for general users to configure with. Additionally, you have to set the result as an environment variable, which is a .bashrc edit for Linux/OSX and who-knows-what for Windows.

Then Valve, as part of giving this format to us, made it the standard format for Steam Big Picture, and it passes this to all SDL2 titles to autoconfig our games with their data. Needless to say, this made adoption of the format pretty outstanding.

With this in mind, I'm now considering removing the MonoGameJoystick.cfg fallback in FNA. I already have a branch that does this, if developers want to try it out:

https://github.com/flibitijibibo/FNA/tree/nomorecfg

There are two concerns I have with this before making it official:

1. Non-Steam configurations are still kinda hard to do. To be honest, I wouldn't be opposed to publishing binaries of the controllertest, but that's still another thing to maintain. In particular, I would need to modify the code to push the config to a file... and this is where things might get interesting.

I would actually be interested in making another standard config file to replace this one, located at FNA/SDL_GameControllerDB.txt. The config program could append to this file, and we could even have a default file that's based on the SDL_GameControllerDB:

https://github.com/gabomdq/SDL_GameControllerDB/

How this all works is up for debate though. This has been a topic of discussion for SDL itself, so it may be worth forwarding this up to them as an SDL2 standard file.

2. Input inversion is not in SDL_GameController yet. The one thing MonoGameJoystick.cfg has over SDL_GameController is that you can invert all inputs - most of the time this is only useful for joystick axes, which can sometimes be inverted by default when they shouldn't be (blame your unfriendly neighborhood driver authors). This is more important than you might think - it's enough to make me skeptical about removing the old config format.

This is something we definitely have to bother the SDL maintainers about. Hopefully it's just one extra char to read in SDL_gamecontroller.c, but you never know with these things.

I would appreciate any feedback on this, both from developers and users. In theory this should be a non-invasive change, but there's just enough happening in the background where this is more fragile than it should be.

CC: @elisee @Epsicode @rcgordon

[elisee]

For what it's worth, I don't have any users using MonoGameJoystick.cfg so I'm all for removing it. I haven't heard about any input inversion issue in the wild, then again, most people use Xbox 360 controllers these days and I guess those are pretty well supported.

[flibitijibibo]

It's unfortunately pretty common for other controllers, and sometimes just drivers. A good example is Nintendo's controllers inverting the Y axis, and sometimes only for the left stick for some reason. The Wii Classic Controller and the Wii U GameCube adapter both do this, so in the drivers you have to flip it either in user space or at the driver level, something like this:

https://github.com/ToadKing/wii-u-gc-adapter/blob/master/wii-u-gc-adapter.c#L334

Sometimes we have the power to fix these things (particularly for Linux), but for Windows in particular you can get screwed pretty easily. But again, this is something SDL2 could provide a fix for in the config format.

[flibitijibibo]

2.0.4 should be coming up soon, so after that release this will become the top priority to ensure this hits the 2.0.5 release. As soon as this is fixed in Mercurial, MonoGameJoystick will be removed.

[flibitijibibo]

Updated the branch just now in case anyone's using it for production. Will probably start doing this in more regular intervals as I see more and more bug reports over the config fallback... that's one way to get me to do this before SDL_GameController's fixed :P

[flibitijibibo]

Developers interested in fixing this at SDL2's level should look to this mailing list thread:

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2015-May/000410.html

The interest is there, but we need the patches to make it happen.

[flibitijibibo]

As of now, MonoGameJoystick.cfg is no longer in FNA.

This still needs to be fixed on SDL2's end, but for now we have a workaround environment variable to help support Nintendo hardware in particular:

https://github.com/flibitijibibo/FNA/wiki/7:-FNA-Environment-Variables#fna_workaround_invert_yaxis

If other inputs need inversion variables, I'm open to adding more variables.

[Wowfunhappy]

Oh no!

This explains why Towerfall no longer works with my Wii Remote.

I used to use this: https://steamcommunity.com/app/251470/discussions/0/540744934205936715/. Is there a better way to configure unusual controllers in newer versions of FNA?

[flibitijibibo]

Huh, I thought we posted a follow-up to that; we moved away from this a while ago in TF...

The quick way is to just configure the Wiimote in Big Picture mode, then it should recognize the device. You can also look at the gamecontrollerdb.txt file found in TowerFall.app/Contents/MacOS/, but that actually has a Wiimote entry already...

https://github.com/gabomdq/SDL_GameControllerDB/commit/0eb9b51ab134b96b4dcba621c69480ba1166fad8

I don't remember if this was with a Classic controller though - see if Big Picture does it, then submit any changes to that repository.

[Wowfunhappy]

I'm using the non-steam version of Towerfall, so no big picture mode. I'm also not seeing a gamecontrollerdb.txt file in my copy of the game (1.3.2.0, latest on Humble).

[flibitijibibo]

Ah, in that case you can download it here and throw it in the above location:

https://raw.githubusercontent.com/gabomdq/SDL_GameControllerDB/master/gamecontrollerdb.txt

[Wowfunhappy]

I really appreciate your help, but I still can't seem to get it working. The newer version of Towerfall still doesn't see the controller.

[flibitijibibo]

Have a look at this:

http://www.generalarcade.com/gamepadtool/

[Wowfunhappy]

thank you, that did it! The GUID was wrong.

[flibitijibibo]

Cool, if you want to send that new GUID to the database I can make sure it's in the next update (with the db.txt in by default).

[Wowfunhappy]

I actually don't remember how to do a pull request—it's been a while. The GUID that worked for me is 050000005769696d6f74652028643800. I'm guessing the old GUID is for the newer -TR Wii Remotes.

...while I'm here, the button layout that actually makes sense for Towerfall is: a:b10,x:b9,start:b6,dpup:b1,dpdown:b0,dpleft:b2,dpright:b3,lefttrigger:b5,righttrigger:b7,platform:Mac OS X,

And adding

<!-- Wii Remote -->
    <controller>
        <name>Wiimote</name>
        <guid>05006f74</guid>
        <buttonset>Wiimote</buttonset>
    </controller>

to GamepadName_config.xml and

<!-- Wii Remote -->
    <buttonlist>
        <name>Wiimote</name>
        <player>dualshock/player</player>
        <move>snes/dpad</move>
        <jump>generic/2</jump>
        <shoot>generic/1</shoot>
        <dodge>snes/b</dodge>
        <start>snes/start</start>
        <confirm>generic/2</confirm>
        <back>generic/1</back>
        <alt>snes/select</alt>
        <alt2>noButton</alt2>
        <skip_replay>snes/a</skip_replay>
    </buttonlist>

to GamepadName_Config.xml makes the buttons look much more pretty.

[Wowfunhappy]

Just a heads up, because it felt like this should be documented somewhere—I recently acquired two new Wii Remotes, and noticed they weren't being picked up by Towerfall. Unfortunately for me, I'd completely forgotten about this thread.

After rediscovering this thread and using GamePad tool, I found that my new Wii Remotes used two new, different uuid's: 050000005769696d6f74652028613400 050000005769696d6f74652028396300

I added these to to my gamecontrollerdb.txt file, and now both my new and old remotes work perfectly.