Better gamepad support

[Elias Daler]

Hello, everyone!

Everyone who ever dealt with gamepad input, probably knows how hard it is. Gamepads are extremely inconsistent - even the same device can work inconsistenly on different systems.

Currently, we have sf::Joystick, which is not easy to deal with, when you try to support different gamepads. Not only axes and buttons get identified differently - even the direction of axes is hard to predict.

For example, we have this issue which is causes by gamepad drivers. But what if we could hide all that inconsistency behind a pretty interface?

Here's what SDL does. It has a Gamepad interface built on top of Joystick interface. It allows users to get a wide range of gamepads working without hardcoding everything manually. It allows them to get "Left stick" state, instead of "X" axis state. It allows them to get "A" button, instead of "button 0". ("A" button is "Cross" on Playstation-style gamepads, usually). Another solution would be to call "ABXY" buttons as "North, West, South, East" buttons, to support gamepads which have "A" and "B" (also "X" and "Y") switched.

This works by storing a community-driven database of gamepads and how they work on different systems. We can do the same too!

The interface can look like this, for example:

bool isPressed = sf::Gamepad::isButtonPressed(gamepadId, sf::Gamepad::Button::A);
float pos = sf::Gamepad::getAxisPosition(gamepadId, sf::Gamepad::Axis::LeftStick);

Won't it be wonderful to have?

So, here's what I'm proposing. Let's build a Gamepad interface on top of Joystick interface. We won't deprecate any current behaviour by this. We'll just add a nice interface for developers to use. I think we can agree, that most people want "Joystick" mostly for gamepads, not for steering wheels or, well, joysticks.


I think that I'll be able to provide Windows and Linux implementation if everything is agreed upon. There'll be need for Mac OS X and Android/iOS implementations, as they treat gamepads differently too.

Some things to consider as well:

* XInput. SDL supports XInput, and we can have it too. There are currently a bunch of gamepads supporting it, not just an Xbox 360 one. We need it for letting the developers properly use it with gamepad triggers (right now they are one axis in SFML). This was a huge deal-breaker for some professional developers that I know. They went to SDL, because SFML couldn't handle this properly. We don't want to lose developers like this.
XInput will also allow us to make gamepad vibration (force feedback) available.
* D-pad should be interpreted as 4 buttons, even though drivers usually have them as axes.
* SDL Gamepad DB. It's huge. We need to ask SDL devs if it's okay to reuse it for SFML and see if it can be used at all. Yes, we may create our own database from scratch. But Valve has a lot more resources to get all the info about gamepads, and this is shown by the huge db that was partly made using help of Steam users.

[Laurent]

Let's build a Gamepad interface on top of Joystick interface

I think that I'll be able to provide Windows and Linux implementation if everything is agreed upon. There'll be need for Mac OS X and Android/iOS implementations, as they treat gamepads differently too.

If it's built on top of Joystick, why do you need OS-specific implementations?

[Elias Daler]

Let's build a Gamepad interface on top of Joystick interface

I think that I'll be able to provide Windows and Linux implementation if everything is agreed upon. There'll be need for Mac OS X and Android/iOS implementations, as they treat gamepads differently too.

If it's built on top of Joystick, why do you need OS-specific implementations?

Hmm, you're right - we probably already got all the OS-specific differences inside the Joystick interface. It's very likely that the account for differences in mapping database will be enough for it to work.

But still, if we consider implementing XInput, we'll need to do it in Windows-specific way. I'm not sure how other platforms deal with XInput-based gamepads. I'll have to check. And while this can be considered a separate topic, I still think that it should be viewed in the same scope - improving gamepad interface.

[rubenwardy]

I've been struggling with this on my game, and ended up having to hardcode particular controllers. Well, I say that - currently I only support my own.

sf::Joystick::Identification info = sf::Joystick::getIdentification(joystick_id);

if (info.name.find("xbox")) {
        type = XBOX360;
} else {
        type = GENERIC;
}

// Just assume that all controllers are like XBOX for now

buttons_map[BTN_A] = 0;
buttons_map[BTN_B] = 1;
buttons_map[BTN_X] = 2;
buttons_map[BTN_Y] = 3;

// Whether LT & RT are axes or buttons varies - detect this here
if (sf::Joystick::hasAxis(joystick_id, sf::Joystick::Axis::Z)) {
        buttons_map[BTN_LT] = -1;
        buttons_map[BTN_RT] = -1;
        trigger_lt = sf::Joystick::Axis::Z;
        trigger_rt = sf::Joystick::Axis::R;
} else {
        buttons_map[BTN_LT] = 6;
        buttons_map[BTN_RT] = 7;
        trigger_lt = -1;
        trigger_rt = -1;
}

[Elias Daler]

One more interesting note - in the current implementation two triggers work correctly on Linux. They're identified as Z and R for me. I wonder how it works on other platforms.
But for Windows we definitely need XInput to support it.

P. S. Also on Windows pressing Up-Right on D-pad gets you PovX=70.71,PovY=70.71. Not cool

[Elias Daler]

Tried implementing XInput support for joysticks on Windows. And it works pretty well. Look, now we can have two independent triggers! I plan to make a PR once the code is pretty enough.

[Hiura]

Having a unified interface would undeniably be useful to the community, I guess. I'm not familiar with SDL approach. Is this DB of runtime nature or is it embedded in its source code? Realistically, if we cannot reuse this DB, do we have enough resources to build our own?

[rubenwardy]

The DB is a text file, and is licensed under ZLIB iirc. It's not specific to SDL so can be reused

[Elias Daler]

DB is a .txt file and can be loaded during runtime, but it's also embedded into SDL itself and we can do the same too.

And I'm almost certain that we can reuse the db. I've started working on the first implementation. And what's great, I can do this without modifying SFML itself! (Though there might be cases where it won't work. I'll check it soon).

[Hiura]

If we (well, mostly you  ) can do this without modifying SFML, I'm wondering if it would make more sense to have this as an extension to SFML. I'm not against having this officially supported and embedded inside SFML, I'm just pondering alternatives. I'm on the train right now so it's a bit tedious to make research, but my main concern is maintainability of this DB: we have no guarantee the format will stay the same for example, do we? I guess we can assume it will be maintained (and not thrown away) for the foreseeable future if it's properly integrated into SDL, so that goes on the plus side.

I guess, having a first (draft of an) implementation would also help determining whether this is something we can maintain or not, although I have to admin that the implementation complexity is not my main concern at this point.

[Elias Daler]

Yes, I think that it would make sense to keep it as an extension to SFML + I don't want to write it in C++03, to be honest. I wonder if we could have a system similar to SDL's extensions. With libs which are closely related to SDL, but are worked on independently.

[Laurent]

I wonder if we could have a system similar to SDL's extensions. With libs which are closely related to SDL, but are worked on independently.

What's specific with "SDL extensions"? If you create a SFML-style library it can be considered an extension, but technically it's just a library. There are already a few of these "add-on" libraries for SFML: Thor, Selba ward, etc. If what you mean is to provide support for these libraries on the official website/forum, then it's not something that we want to do.

[aggsol]

Yes, I think that it would make sense to keep it as an extension to SFML + I don't want to write it in C++03, to be honest. I wonder if we could have a system similar to SDL's extensions. With libs which are closely related to SDL, but are worked on independently.

I vote for a C++14 library instead of adding it to SFML. Once SFML is C++14 ready then we could integrate it back. So pick the same license as SFML.

[Phanoo]

I'd like to add gamepad support for my game, is there some place I can found something already written ?

I can help but please, don't debate endlessly if it should be included or not in SFML, most likely it should. If SDL did something, it's probably for a good reason, it's worth for SFML to take inspiration from it.

[Tigre Pablito]

I'd like to add gamepad support for my game, is there some place I can found something already written ?

I can help but please, don't debate endlessly if it should be included or not in SFML, most likely it should. If SDL did something, it's probably for a good reason, it's worth for SFML to take inspiration from it.

Hi Phanoo

I don't know why, it seems that you like SDL more than SFML. As far as I know, nobody is forcing you to stay in SFML if you like SDL more. It is completely up to you to decide where you are

I have played the game Ach Ball (and it's good), but soon it will be launched the game Break Balls, that took inspiration in your posts with hard arguing on feature requests that have nothing to do with a multimedia library and comparisons between SFML and SDL and prompting people to switch to SDL

Unless that you are staying in SFML for charity, if SDL suits you best, you are free to switch wherever you want, so as others are, plus they don´t need to be given directives about where to switch to or stay in

This is SFML and "there is what there is" (HAY LO QUE HAY, in Spanish). Actually I started in SDL and switched to SFML, but everyone is free to go/switch/stay wherever he/she wants to. But when I switched to SFML I did not make a mess and a movement in the SDL mailing list.

Regards