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

Support gamepad mapping via SDL_GameControllerDB #1950

Open
sam20908 opened this issue Dec 31, 2021 · 8 comments
Open

Support gamepad mapping via SDL_GameControllerDB #1950

sam20908 opened this issue Dec 31, 2021 · 8 comments

Comments

@sam20908
Copy link

Subject of the issue

I've been enjoying SFML's Joystick API, however inconsistencies between different controllers will cause different values for buttons and axis. I found out GLFW and SDL supports mappings via SDL_GameControllerDB, and I was wondering if the same thing can be implemented for SFML?

Your environment

  • Windows 10
  • SFML 2.5.1
  • Visual Studio 2022 Preview

Steps to reproduce

Expected behavior

Actual behavior

@sam20908
Copy link
Author

Any updates on this? Right now I have to use both SFML and SDL, which SDL was SOLELY for controller emulation. Even GLFW supports using GameControllerDB, and it'd be really nice if SFML could support it too.

@Bromeon
Copy link
Member

Bromeon commented Feb 13, 2022

I found out GLFW and SDL supports mappings via SDL_GameControllerDB

If I understand this correctly, it means that they recognize several models/vendors of game controllers based on this database, and hardcode what a certain button means for them? But since different controllers often have different labels/symbols for each button and sometimes completely different layout, where exactly does the mapping help?

and I was wondering if the same thing can be implemented for SFML?

I don't think anyone would oppose it, if there is a good use case. Would you be willing to contribute with a pull request?

@sam20908
Copy link
Author

But since different controllers often have different labels/symbols for each button and sometimes completely different layout, where exactly does the mapping help?

It helps being able to have a consistent mapping between all controllers. Yes, different controllers have different buttons and layouts, but having a consistent mapping relieves the burden of handling different controllers. And, if change in mapping is needed, the mapping database can be modified to one's liking.

if there is a good use case. Would you be willing to contribute with a pull request?

I have not familiarized myself with SFML as well as how to implement it, so I was hoping to create this issue so someone else can.

@eXpl0it3r
Copy link
Member

Both @eliasdaler and @binary1248 had once looked a bit into it. Last conclusion I've heard is that one can't really use the DB as-is, because SFML enumerates the inputs differently, so you don't get a 1:1 match.
What I don't know is, whether there's a possibility to implement a sort of translation layer still.

Maybe one of the pinged guys can give an update/hint on this topic.

@binary1248
Copy link
Member

The first thing to understand is that in SDL there are 2 different APIs that you can use to interact with controllers, the Joystick API (comparable to SFML's Joystick API) and the Controller API. The Joystick API is lower level and therefore was also the first to exist. It handles the interaction with the OS.

Because game developers can't be expected to acquire 1000 different controllers and hard code the mapping of controller input objects to actions in their game SDL decided to introduce a kind of "model controller", something that can represent the vast majority of all controllers on the market to a high degree. This shifts the work of mapping enumerated input objects from the game developers to the library developers, but since this work would only have to be done once and could be reused over and over it made sense.

The reason why SFML in its current state can't make use of the DB is because SFML currently does not have a Controller API that the DB would be used for. It's that simple. Before focusing on integrating the DB, a public Controller API would have to be designed and accepted. I don't want to be the bearer of bad news, but such API discussions (especially for completely new APIs) tend to take longer than many people expect (see other similar PRs).

So, in short, SFML could make use of the DB, but only after a Controller API exists. The focus therefore shouldn't be on integrating the DB itself, but designing the Controller API so that it fits into SFML. After that is done DB integration becomes just another implementation detail.

@phgroe
Copy link

phgroe commented Nov 26, 2022

Yes, different controllers have different buttons and layouts

During some experimenting, I noticed that even the same controller can send different button codes based on how it is connected to the host. Saw this when using a XBox 360 controller connected either through USB or Bluetooth.

but having a consistent mapping relieves the burden of handling different controllers.

After experiencing this above I thought, how nice it would be to have an abstraction layer! And surprise, a similar thing would already exist for SDL.

Could we maybe discuss what requirements there would be for such a Controller API for SFML? Can we estimate how much interest there would be from fellow developers to have such an API?

@Bambo-Borris
Copy link
Contributor

Yes, different controllers have different buttons and layouts

During some experimenting, I noticed that even the same controller can send different button codes based on how it is connected to the host. Saw this when using a XBox 360 controller connected either through USB or Bluetooth.

but having a consistent mapping relieves the burden of handling different controllers.

After experiencing this above I thought, how nice it would be to have an abstraction layer! And surprise, a similar thing would already exist for SDL.

Could we maybe discuss what requirements there would be for such a Controller API for SFML? Can we estimate how much interest there would be from fellow developers to have such an API?

I think if you really want to gauge interest or discuss this with just users your best place to visit is the forums or the Discord. From my experience a lot of people who use SFML to make games and would be interested in this don't really check Github issues. So try out contacting the community and see what you get back

@eliasdaler
Copy link
Contributor

FIY: there's some work I did about it here

I don't use SFML anymore so I don't have interested on working on it further, but maybe it'll be somewhat useful as a start.

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

No branches or pull requests

8 participants