Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] GamecontrollerDB support #82

Closed
parkerlreed opened this issue Jan 15, 2020 · 14 comments
Closed

[Enhancement] GamecontrollerDB support #82

parkerlreed opened this issue Jan 15, 2020 · 14 comments

Comments

@parkerlreed
Copy link

https://github.com/gabomdq/SDL_GameControllerDB

SDL2 supports reading from a file in the PWD/environment variable path containing a mapping of controllers centralized around the Xbox 360 mapping. This makes it dead simple to instantly support most every controller out there and easy to add new ones by just appending mappings to the file.

Would be great to have this support in VVVVVV

@JayFoxRox
Copy link

JayFoxRox commented Jan 15, 2020

This is already a feature of SDL2: https://wiki.libsdl.org/SDL_HINT_GAMECONTROLLERCONFIG

So you can set an environment variable with the config(s) for your controller.
Some launchers will set this (I believe Steam does this).

Obviously this won't give you a full set of controllers (at least not on platforms where environment variables have limited length), but I'd consider this a niche feature anyway, because VVVVVV allows remapping buttons. VVVVVV also doesn't visualize buttons or anything else where it would benefit from SDL_GameController.

@parkerlreed
Copy link
Author

Well then something is not working. Controller is not being seen at all. I assumed it was from missing the support (actual mapping definitions not following the newer standards in Input.cpp)

@parkerlreed
Copy link
Author

parkerlreed commented Jan 15, 2020

Here's what SDL2 sees

INFO: There are 1 joysticks attached
INFO: Joystick 0: Nintendo Switch Combined Joy-Cons
INFO:        axes: 4
INFO:       balls: 0
INFO:        hats: 0
INFO:     buttons: 22
INFO: instance id: 0
INFO:        guid: 060000007e0500000820000000000000
INFO:     VID/PID: 0x057e/0x2008
INFO: 

I attempt to remap in game and nothing happens.

@parkerlreed
Copy link
Author

parkerlreed commented Jan 15, 2020

It's a feature of SDL2, but the program has to include the database and use the right button definitions for it to actually be used.

That github repo I linked just hosts a txt file and instructions on how its used. It's still using all the SDL2 built in functions.

@flibitijibibo
Copy link
Collaborator

We can do what I do in FNA and load the txt file directly from the base directory, right after initializing the filesystem:

https://github.com/FNA-XNA/FNA/blob/master/src/FNAPlatform/SDL2_FNAPlatform.cs#L133

@JayFoxRox
Copy link

(This post contains some background knowledge about SDL_GameController / explanations first, then opinion - feel free to skip it)

@parkerlreed It's a feature of SDL2, but the program has to include the database and use the right button definitions for it to actually be used.

I think you misinterpreted what I said / meant.

SDL2 has SDL_GameController which VVVVVV is already using. That maps a standard joystick into the Xbox 360 layout (as you also described).

The per-device configurations for SDL_GameController are loaded from different sources (not a complete list):

  • Included with SDL2 (this should cover popular devices where the config is finalized); on some platforms like Linux, SDL2 is independently updated, so these controller updates reach users quickly.
  • Environment variable (this is used by launchers like Steam, and what I suggested / linked).
    You can take any line(s) from the SDL_GameControllerDB and set it as environment variable (VVVVVVs SDL2 should then pick it up). This is also somewhat implied in the README of SDL_GameControllerDB. They link to a GUI tool which also explain this explicitly.
    This means it's trivial (for the user) to configure your joystick as SDL_GameController for use in VVVVVV.
    The issue is that there's usually a limit to environment variable lengths, so you can't add a couple hundred configurations at once (usually not an issue, as you only care about configurations for devices you actually use).
  • Manually loading config from a file (part of application code) as @flibitijibibo proposed. The benefit of this is a better out-of-the-box experience as a large number of controllers can be added. But it also moves the burden of adding new devices to the project / user (as it requires regular updates of SDL_GameControllerDB).

My personal preference has always been to encourage upstreaming of controller configs from SDL_GameControllerDB to SDL2.

My second preferred option is to recommend launchers (like Steam big picture) or manually setting up their SDL2 environment variables (either completely manually, or through a tool to set the environment variables for you).

My least favorite option has always been to load SDL_GameControllerDB from file because I don't like the idea of having a config per-application when it should be system-wide. I also don't like their recommended 6-button layout as it's incompatible with 6-button Xbox gamepads (to be fair, this probably also propagated to upstream SDL by now). Generally, I like the idea of SDL_GameControllerDB, but the implementation feels like a temporary hack that has gone permanent and leaves its traces in many applications. Unfortunately, loading a per-application SDL_GameControllerDB is slowly becoming the defacto standard (defeating the purpose of general-purpose and system-wide databases).

@parkerlreed
Copy link
Author

Yeah I was focusing less on the DB and just generally supporting the mapping itself. That was the best jumping off point I could think of.

I guess the main issue is the current input handling (in VVVVVV) doesn't seem to be controller agnostic. I'm not sure what it is supposed to recognize but I haven't found a controller I can map as of yet.

@parkerlreed
Copy link
Author

Ok so I finally found my DS4 controller and that DID work. So what would be the reason for it not recognizing another gamepad? That was my whole point of trying to pass in a custom controllerdb entry.

@JayFoxRox
Copy link

JayFoxRox commented Jan 16, 2020

I feel like I explained this in my previous 2 posts: You can just use http://www.generalarcade.com/gamepadtool/ and create a mapping, then use "Set as environment variable".

SDL2 will then expose the SDL joystick as an SDL_GameController and VVVVVV should pick it up (provided you aren't using an ancient SDL2).

You want your SDL2 config to be generic (follow the Xbox 360 button layout). If you want to remap buttons in VVVVVV you should be able to use the VVVVVV options.


Another solution to support more gamepads in VVVVVV would be to open devices as SDL joystick, then allow rebinding those manually (as it exposes all joystick devices, and also all buttons - not just those mapped by SDL_GameController). They could still just be pre-configured from the SDL_GameController configuration (this is how I usually use SDL_GameController myself, because it allows greater flexibility).

For gamepads which aren't even detected as SDL joystick you'll have to use something like vjoy or uinput. But I feel like that's out of scope for VVVVVV (heck, even documenting how to use SDL_GameController should be out of scope - but here we are).

@parkerlreed
Copy link
Author

Ok I think what confused me is I had the txt file and tried to use the function in SDL to use it and that wasn't working. I will try as the variable and see if I can get it working. Thanks.

@flibitijibibo
Copy link
Collaborator

If it's the SDL2 revision that shipped with the current 2.2 release, it's probably just that it's super old and doesn't have that much in the database. Updating the lib that I shipped with should be pretty comprehensive, if not then there's a good chance that adding the gamecontrollerdb.txt functionality should make just about every other device work (and if not, the DB has a guide for adding new entries, and that's probably that @parkerlreed needs to do in addition to adding the LoadMappingsFromFile call after filesystem init).

@JayFoxRox Managing the database is really tricky right now, for a number of reasons:

  • Upstreaming configs is hard because, last I checked, entries were only accepted if Sam can test it locally. I think a couple of us have snuck in some configs in the past, but generally the upstream entries come from Sam.
  • Environment variables are easy on Linux and macOS, where you can just dump them into ~/.bashrc, but on Windows this is impossible to not do clumsily unless you have a launcher like Steam writing them for you.
  • The text file does require updating, but at least the user can do the update themselves if necessary. Decoupling the database from the person making the build has, in my experience, proven to be REALLY useful, especially for me since I have to maintain 50+ games at once... and it also gets users to contribute to the database without having to worry about upstreaming changes to a header file.

There's no real proper fix for the database issue - at best you might be able to upstream searching for the file in XDG_CONFIG_DIRS and that's about it.

@parkerlreed
Copy link
Author

parkerlreed commented Jan 16, 2020

Ok so yeah the environment variable did indeed work. I tried adding the txt file import to main.cpp after the ASCII display and that wasn't working. Is there some place that would work better?

SDL_GAMECONTROLLERCONFIG="060000007e0500000820000000000000,Nintendo Switch Combined Joy-Cons,platform:Linux,a:b0,b:b1,x:b3,y:b2,back:b9,guide:b11,start:b10,leftstick:b12,rightstick:b13,leftshoulder:b5,rightshoulder:b6,dpup:b14,dpdown:b15,dpleft:b16,dpright:b17,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:b7,righttrigger:b8," VVVVVV

@flibitijibibo
Copy link
Collaborator

9eebbc5

@JayFoxRox
Copy link

Note about the patch: This feels like it should have been in input related code, not filesystem related code. @flibitijibibo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants