Add controller support

[Xaeroxe]

What it says on the tin. Enhance the Input system to support arbitrary game pads. Some APIs I'd like to support include

• Xinput (Windows)
• evdev (Linux)
• OSX game controller framework
• Steam Controller would be great but is dependent on Steam API support first.

[OvermindDL1]

There are quite a number of libraries out for interacting with a steam controller without the steam api, however then it loses the built-in functionality like profiles and such (but you can then control the pads from within code however you want). I'd prefer with the steam api though (I never got around to integrating that api in my engine).

[OvermindDL1]

There are quite a number of libraries out for interacting with a steam controller without the steam api, however then it loses the built-in functionality like profiles and such (but you can then control the pads from within code however you want). I'd prefer with the steam api though (I never got around to integrating that api in my engine).

[OvermindDL1]

Also I'd really really recommend not using evdev for the linux api (or perhaps as a fallback, but I'm unsure that is needed). Should be using libinput only as it is set to replace evdev entirely and has significantly better and more accurate functionality (plus it comes with most systems now and is forced by wayland as wayland uses it). It comes pre-installed with Gnome, KDE, enlightenment and a few other UI's as well due to how broken evdev is in a variety of ways (like erasing calibration settings on gamepads after reattachment).

(EDIT: For note, libinput is a wrapper of evdev and a few kernel calls to actually make it nice to use and work around all the design faults of evdev, it was started by the same group that started wayland)

[OvermindDL1]

Also I'd really really recommend not using evdev for the linux api (or perhaps as a fallback, but I'm unsure that is needed). Should be using libinput only as it is set to replace evdev entirely and has significantly better and more accurate functionality (plus it comes with most systems now and is forced by wayland as wayland uses it). It comes pre-installed with Gnome, KDE, enlightenment and a few other UI's as well due to how broken evdev is in a variety of ways (like erasing calibration settings on gamepads after reattachment).

(EDIT: For note, libinput is a wrapper of evdev and a few kernel calls to actually make it nice to use and work around all the design faults of evdev, it was started by the same group that started wayland)

[Xaeroxe]

@OvermindDL1 So while researching libinput I can't find where specifically it exposes game controllers :/ it does a lot of things, but game controllers don't seem to be one of them.

[Xaeroxe]

@OvermindDL1 So while researching libinput I can't find where specifically it exposes game controllers :/ it does a lot of things, but game controllers don't seem to be one of them.

[OvermindDL1]

@OvermindDL1 So while researching libinput I can't find where specifically it exposes game controllers :/ it does a lot of things, but game controllers don't seem to be one of them.

Not currently, you'll still access evdev for that, but everything else from keyboards, mice, touchpads, touchscreens, tablets, etc... are significantly improved by going through it. They are looking at gaming uses in libinput as well, which does includes gamepads eventually though they are not including them right now as due to the difficulty of handling gamepads it would do little more than just forward evdev's calls straight through and they don't want to commit to such a low level api until a more refined one is developed.

[OvermindDL1]

@OvermindDL1 So while researching libinput I can't find where specifically it exposes game controllers :/ it does a lot of things, but game controllers don't seem to be one of them.

Not currently, you'll still access evdev for that, but everything else from keyboards, mice, touchpads, touchscreens, tablets, etc... are significantly improved by going through it. They are looking at gaming uses in libinput as well, which does includes gamepads eventually though they are not including them right now as due to the difficulty of handling gamepads it would do little more than just forward evdev's calls straight through and they don't want to commit to such a low level api until a more refined one is developed.

[Xaeroxe]

Ah, well that kind of work is actually handled at much lower levels than Amethyst. Problem is our current lower level crates don't support controllers very well, so yeah we'll have to go through evdev.

[Xaeroxe]

Ah, well that kind of work is actually handled at much lower levels than Amethyst. Problem is our current lower level crates don't support controllers very well, so yeah we'll have to go through evdev.

[OvermindDL1]

Ah, well that kind of work is actually handled at much lower levels than Amethyst. Problem is our current lower level crates don't support controllers very well, so yeah we'll have to go through evdev.

Yeah I've noticed that gamepad support is spotty in rust so far (even sdl has... issues still, and so much special casing). libinput will definitely want to be the integration layer for inputs with a shim for evdev for now just for gamepads (to be removed 'eventually') as those will be the most future-proof (it's being built-in to wayland after all).

[OvermindDL1]

Ah, well that kind of work is actually handled at much lower levels than Amethyst. Problem is our current lower level crates don't support controllers very well, so yeah we'll have to go through evdev.

Yeah I've noticed that gamepad support is spotty in rust so far (even sdl has... issues still, and so much special casing). libinput will definitely want to be the integration layer for inputs with a shim for evdev for now just for gamepads (to be removed 'eventually') as those will be the most future-proof (it's being built-in to wayland after all).

[MrMinimal]

About windows controller support, XInput only supports the Xbox 360 controller, and only one at that.
DirectInput could support n joysticks at the same time.

[MrMinimal]

About windows controller support, XInput only supports the Xbox 360 controller, and only one at that.
DirectInput could support n joysticks at the same time.

[torkleyy]

I think we'll be using gilrs. It uses XInput on Windows, but I don't see any restriction to one controller.

[torkleyy]

I think we'll be using gilrs. It uses XInput on Windows, but I don't see any restriction to one controller.

[MrMinimal]

@torkleyy Just tested gilrs on Windows. The problem I see is that not all input hardware is supported.
Joysticks, Steering wheels, certain Gamepads.

I tested (unsuccessfully) with:

• Thrustmaster Warthog Stick
• Thrustmaster Warthog Throttle
• Saitek Pro Flight Cessna Rudder Pedals

[MrMinimal]

@torkleyy Just tested gilrs on Windows. The problem I see is that not all input hardware is supported.
Joysticks, Steering wheels, certain Gamepads.

I tested (unsuccessfully) with:

• Thrustmaster Warthog Stick
• Thrustmaster Warthog Throttle
• Saitek Pro Flight Cessna Rudder Pedals

[Rhuagh]

<hint> it's open source ;) </hint>

[Rhuagh]

<hint> it's open source ;) </hint>

[MrMinimal]

Added an issue to discuss difficulty and approach
https://gitlab.com/gilrs-project/gilrs/issues/51

[MrMinimal]

Added an issue to discuss difficulty and approach
https://gitlab.com/gilrs-project/gilrs/issues/51

[MrMinimal]

Overview

I used today for research on Windows specific input APIs.

• XInput - 4 device limit carried over from Xbox 360
• DirectInput - deprecated in favour of XInput
• Raw Input - can be used to break 4 device limit and gets most detailled (read most low level) information about device events

So for a general device support, not only Xbox 360 compatible gamepads, Raw Input should be the way to go (Unity3D and DCS World do it that way).

Requirements for amethyst

• cross-platform
• cover wide range of devices (Raw Input API)
• pure Rust would be nice

Crates

Project	XInput	DirectInput	Raw Input	Linux	MacOS
rusty-xinput	✓	✗	✗	✗	✗
reminisce (won't compile, old)	✓	✗	✗	✓	✗
multiinput-rust (only lib with joystick events caputured)	✗	✗	✓	✗	✗
gilrs (gamepad focused library)	✓	✗	✗	✓	✗

Direct Input is mentioned for completeness, not that anyone would need a depricated API

[MrMinimal]

Overview

I used today for research on Windows specific input APIs.

• XInput - 4 device limit carried over from Xbox 360
• DirectInput - deprecated in favour of XInput
• Raw Input - can be used to break 4 device limit and gets most detailled (read most low level) information about device events

So for a general device support, not only Xbox 360 compatible gamepads, Raw Input should be the way to go (Unity3D and DCS World do it that way).

Requirements for amethyst

• cross-platform
• cover wide range of devices (Raw Input API)
• pure Rust would be nice

Crates

Project	XInput	DirectInput	Raw Input	Linux	MacOS
rusty-xinput	✓	✗	✗	✗	✗
reminisce (won't compile, old)	✓	✗	✗	✓	✗
multiinput-rust (only lib with joystick events caputured)	✗	✗	✓	✗	✗
gilrs (gamepad focused library)	✓	✗	✗	✓	✗

Direct Input is mentioned for completeness, not that anyone would need a depricated API

[MrMinimal]

As you can tell no solution would provide everything needed for a general purpose game engine.
But the features of the different projects could be merged.

[MrMinimal]

As you can tell no solution would provide everything needed for a general purpose game engine.
But the features of the different projects could be merged.

[francesca64]

@MrMinimal I hadn't realized DirectInput was deprecated; from the way people talk about it in non-programming circles I've always assumed it was "the right thing". For more reference, winit actually contains a complete (thin) wrapper over raw input: https://github.com/tomaka/winit/blob/master/src/platform/windows/raw_input.rs (IIRC the only exclusion is buffered reading).

Additionally, note that gilrs doesn't support macOS yet either. There's also the proviso that it only compiles on Windows 10 due to winapi-rs not supporting older XInput versions; using raw input would circumvent that.

There's another gamepad library that cropped up quite recently, https://github.com/unrust/gamepad-rs. AFAIK it was created specifically because the unrust team was concerned by gilrs's lack of activity.

[francesca64]

@MrMinimal I hadn't realized DirectInput was deprecated; from the way people talk about it in non-programming circles I've always assumed it was "the right thing". For more reference, winit actually contains a complete (thin) wrapper over raw input: https://github.com/tomaka/winit/blob/master/src/platform/windows/raw_input.rs (IIRC the only exclusion is buffered reading).

Additionally, note that gilrs doesn't support macOS yet either. There's also the proviso that it only compiles on Windows 10 due to winapi-rs not supporting older XInput versions; using raw input would circumvent that.

There's another gamepad library that cropped up quite recently, https://github.com/unrust/gamepad-rs. AFAIK it was created specifically because the unrust team was concerned by gilrs's lack of activity.

[torkleyy]

by gilrs's lack of activity.

Well to me it seems quite maintained. Honestly I don't see much point in creating yet another library. The author wants to get OS X support, but understandably that's hard to do without a Mac.

[torkleyy]

by gilrs's lack of activity.

Well to me it seems quite maintained. Honestly I don't see much point in creating yet another library. The author wants to get OS X support, but understandably that's hard to do without a Mac.

[torkleyy]

The API also has good documentation and I think its structure is really easy to understand.

[torkleyy]

The API also has good documentation and I think its structure is really easy to understand.

[francesca64]

I agree, and I think avoiding duplication of effort is our best bet at having complete support. @edwin0cheng, are you still open to using gilrs?

Regardless, I'd be able to add macOS support to gilrs, along with raw input on Windows.

[francesca64]

I agree, and I think avoiding duplication of effort is our best bet at having complete support. @edwin0cheng, are you still open to using gilrs?

Regardless, I'd be able to add macOS support to gilrs, along with raw input on Windows.

[edwin0cheng]

@francesca64, I did try to contact gilrs author to help to implement macOS support, but after 3 weeks there is no replied (maybe i am a little bit impatient) and we didn't want to fork gilrs. So that's why my team decided to create yet another library for that unrust/gamepad-rs. 😅

But as we all think avoiding duplication of effort is important, it is not hard to backport gamepad-rs macos side to gilrs. if @francesca64 is interested to do so, you can reference how gamepad-rs works in macos.
(The macos implementation of gamepad-rs is referencing the original sdl2 controller c++ implementation so it should work in all machine.)

For your information, there are missing the whole io-kit binding in core-foundation-rs crate, but there is a crate named "IOKit-sys" which handle part of it, so i forked it(edwin0cheng/iokit-sys), and implemented the missing part useful for gamepad binding. (I will make another PR to the original iokit-sys after it is stabled, so you can use it afterward.)

[edwin0cheng]

@francesca64, I did try to contact gilrs author to help to implement macOS support, but after 3 weeks there is no replied (maybe i am a little bit impatient) and we didn't want to fork gilrs. So that's why my team decided to create yet another library for that unrust/gamepad-rs. 😅

But as we all think avoiding duplication of effort is important, it is not hard to backport gamepad-rs macos side to gilrs. if @francesca64 is interested to do so, you can reference how gamepad-rs works in macos.
(The macos implementation of gamepad-rs is referencing the original sdl2 controller c++ implementation so it should work in all machine.)

For your information, there are missing the whole io-kit binding in core-foundation-rs crate, but there is a crate named "IOKit-sys" which handle part of it, so i forked it(edwin0cheng/iokit-sys), and implemented the missing part useful for gamepad binding. (I will make another PR to the original iokit-sys after it is stabled, so you can use it afterward.)

[derekdreery]

@francesca64, I did try to contact gilrs author to help to implement macOS support, but after 3 weeks there is no replied (maybe i am a little bit impatient) and we didn't want to fork gilrs. So that's why my team decided to create yet another library for that unrust/gamepad-rs. sweat_smile

Rather than create a new library, you can fork the library, add the missing functionality, and publish to crates.io under a different name. If/when the lib author has time to talk and get your stuff merged, you can move back to using their lib and add a note to crates.io to use the original crate.

[derekdreery]

@francesca64, I did try to contact gilrs author to help to implement macOS support, but after 3 weeks there is no replied (maybe i am a little bit impatient) and we didn't want to fork gilrs. So that's why my team decided to create yet another library for that unrust/gamepad-rs. sweat_smile

Rather than create a new library, you can fork the library, add the missing functionality, and publish to crates.io under a different name. If/when the lib author has time to talk and get your stuff merged, you can move back to using their lib and add a note to crates.io to use the original crate.

[torkleyy]

When I contacted Arvamer (I think) they always responded quite promptly. Maybe just retry?

[torkleyy]

When I contacted Arvamer (I think) they always responded quite promptly. Maybe just retry?

[edwin0cheng]

@derekdreery Maybe that is a better solution, I would do it next time if i face the same situation.

Since someone was already contributed to rewrite the Windows Implementation and we already added wasm-unknown-unknown platform support which may not be backport-able. So i think i do not have interests to works on girls now. Sorry about that.

But as i stated, all road blocks for implementing macos features in low level api was clean, it seem to be not hard to implement it in girls now.

[edwin0cheng]

@derekdreery Maybe that is a better solution, I would do it next time if i face the same situation.

Since someone was already contributed to rewrite the Windows Implementation and we already added wasm-unknown-unknown platform support which may not be backport-able. So i think i do not have interests to works on girls now. Sorry about that.

But as i stated, all road blocks for implementing macos features in low level api was clean, it seem to be not hard to implement it in girls now.

[Lokathor]

Hey hey, author of rusty-xinput here.

Please do not use gilrs without great caution and overhaul. As written currently, it statically compiles against xinput, so if the user doesn't have the exact version of xinput you compiled with they can't even run the program. The major advantage of rusty-xinput is (1) dynamic loading the lib prevents this problem (if xinput isn't there you can't read a controller obviously, but you can probably continue with keyboard+mouse), (2) my lib works on win7 (because it doesn't support the win10 only xinput stuff), and (3) rusty-xinput uses the winapi 0.3 series.

[Lokathor]

Hey hey, author of rusty-xinput here.

Please do not use gilrs without great caution and overhaul. As written currently, it statically compiles against xinput, so if the user doesn't have the exact version of xinput you compiled with they can't even run the program. The major advantage of rusty-xinput is (1) dynamic loading the lib prevents this problem (if xinput isn't there you can't read a controller obviously, but you can probably continue with keyboard+mouse), (2) my lib works on win7 (because it doesn't support the win10 only xinput stuff), and (3) rusty-xinput uses the winapi 0.3 series.

[Lokathor]

(also, the current version of gamepad-rs duplicates every problem with gilrs ;_; )

[Lokathor]

(also, the current version of gamepad-rs duplicates every problem with gilrs ;_; )

[Moxinilian]

As a side note, it would be important for this controller feature to be expandable, especially if we plan to create NDA-protected extensions of the engine for proprietary platforms such as Nintendo Switch or PlayStation.

[Moxinilian]

As a side note, it would be important for this controller feature to be expandable, especially if we plan to create NDA-protected extensions of the engine for proprietary platforms such as Nintendo Switch or PlayStation.

[Lokathor]

Might I suggest that controller input be made generic over the raw data type, with an into_inner sort of setup (or similar).

Controllers are where you sometimes want the ability to abstract as little as possible. For example with rumble, you want to know if it's available, and even if it is then the switch and the 360 don't think of rumble as working the same way, so you want to be able to side step whatever high level api and get at what's really going on.

[Lokathor]

Might I suggest that controller input be made generic over the raw data type, with an into_inner sort of setup (or similar).

Controllers are where you sometimes want the ability to abstract as little as possible. For example with rumble, you want to know if it's available, and even if it is then the switch and the 360 don't think of rumble as working the same way, so you want to be able to side step whatever high level api and get at what's really going on.

[Moxinilian]

The controllers are, with the filesystem, the only place where code will have to differ between platforms. So this approach seems perfectly reasonable to me.
I think that we can however find similarities between controllers.
For example, an Xbox controller, a Joy-Con and a keyboard share the high level ability of having a directional pad. The abstraction could happen with groups like this. You get your mysterious generic controller object, you request access to its DPad. This allows for some level of abstraction, sometimes the only stuff that really is needed, while allowing specific use cases depending on the controller.
In other words

my_controller.dpad?.is_up();
if Some(hd_rumble) = my_controller.hd_rumble {
    hd_rumble.do_hd_rumble_stuff_idk_what_it_is_anyway_i_just_know_they_say_its_something();
}

[Moxinilian]

The controllers are, with the filesystem, the only place where code will have to differ between platforms. So this approach seems perfectly reasonable to me.
I think that we can however find similarities between controllers.
For example, an Xbox controller, a Joy-Con and a keyboard share the high level ability of having a directional pad. The abstraction could happen with groups like this. You get your mysterious generic controller object, you request access to its DPad. This allows for some level of abstraction, sometimes the only stuff that really is needed, while allowing specific use cases depending on the controller.
In other words

my_controller.dpad?.is_up();
if Some(hd_rumble) = my_controller.hd_rumble {
    hd_rumble.do_hd_rumble_stuff_idk_what_it_is_anyway_i_just_know_they_say_its_something();
}

[torkleyy]

@Lokathor the problem is that Windows is not the only system we are targeting.

[torkleyy]

@Lokathor the problem is that Windows is not the only system we are targeting.

[omni-viral]

@torkleyy I think we can use different crates for different platforms sometimes.
However I'd suggest to hide it in it's own amethyst crate.
Amethyst API should be the same on all platforms where possible of course.

[omni-viral]

@torkleyy I think we can use different crates for different platforms sometimes.
However I'd suggest to hide it in it's own amethyst crate.
Amethyst API should be the same on all platforms where possible of course.

[torkleyy]

Yeah, I just fear that Linux / OS X will be second-class platforms, as it is the case with (too) many frameworks..

[torkleyy]

Yeah, I just fear that Linux / OS X will be second-class platforms, as it is the case with (too) many frameworks..

[omni-viral]

Amethyst will support as first-class all platforms contributors care about.
I hope we will have some for many modern platforms 😄

[omni-viral]

Amethyst will support as first-class all platforms contributors care about.
I hope we will have some for many modern platforms 😄

[Lokathor]

@torkleyy I'm not even sure what you mean when you say that there's some sort of problem for non-windows.

[Lokathor]

@torkleyy I'm not even sure what you mean when you say that there's some sort of problem for non-windows.

[torkleyy]

Well, last I checked XInput was Windows-only. Also, according to previous comments its support is rather limited.

[torkleyy]

Well, last I checked XInput was Windows-only. Also, according to previous comments its support is rather limited.

[Xaeroxe]

The best solution it seems is going to require multiple crates. @Lokathor 's crate could be our windows solution.

[Xaeroxe]

The best solution it seems is going to require multiple crates. @Lokathor 's crate could be our windows solution.

[Xaeroxe]

Also a 4 controller limit on Windows seems highly unlikely to come up, most people play PC single player

[Xaeroxe]

Also a 4 controller limit on Windows seems highly unlikely to come up, most people play PC single player

[Lokathor]

I'm not suggesting that you support only xinput. That would be foolish.

However, if you are on windows, and you're not using xinput, then you'll get bad inputs from the single most common controller people have hooked up to their machines (xbox controllers, and things that register themselves to the system as xbox controllers, such as the logitech controller). So you really need to be using xinput when the controller has an xinput path available. And the current xinput code in gilrs (as well as gamepad-rs) is going about it in rather the wrong way.

[Lokathor]

I'm not suggesting that you support only xinput. That would be foolish.

However, if you are on windows, and you're not using xinput, then you'll get bad inputs from the single most common controller people have hooked up to their machines (xbox controllers, and things that register themselves to the system as xbox controllers, such as the logitech controller). So you really need to be using xinput when the controller has an xinput path available. And the current xinput code in gilrs (as well as gamepad-rs) is going about it in rather the wrong way.

[Frizi]

I'm currently doing some development targeting sdl2 as a direct dependency for amethyst_input. This is the only thing that was both even remotely able to provide support for mac and stay cross-platform. Also there is a quite large database of controller bindings in the wild. I'm perfectly fine for it to be treated as a base for further development if any other library will be chosen down the line. I do believe that right now having any gamepad support will be enough of a success, even with sdl limitations.

I did tested that locally on mac with Xbox 360 controller and some random version of logitech WingMan. I might as well buy another random one and test it on more platforms if need be.

[Frizi]

I'm currently doing some development targeting sdl2 as a direct dependency for amethyst_input. This is the only thing that was both even remotely able to provide support for mac and stay cross-platform. Also there is a quite large database of controller bindings in the wild. I'm perfectly fine for it to be treated as a base for further development if any other library will be chosen down the line. I do believe that right now having any gamepad support will be enough of a success, even with sdl limitations.

I did tested that locally on mac with Xbox 360 controller and some random version of logitech WingMan. I might as well buy another random one and test it on more platforms if need be.

[Xaeroxe]

#818 has just been r+ed, thanks to @Frizi for all the work they've done on this! 🎉

This gets us basic controller support. He also added a very generic API for pumping controller events in from external sources. Currently our only provider of these events is SDL2, I'd like to migrate away from this as having these C dependencies complicates our build process, so in the future I plan on adding event providers for each of the APIs I've outlined in the original issue description.

[Xaeroxe]

#818 has just been r+ed, thanks to @Frizi for all the work they've done on this! 🎉

This gets us basic controller support. He also added a very generic API for pumping controller events in from external sources. Currently our only provider of these events is SDL2, I'd like to migrate away from this as having these C dependencies complicates our build process, so in the future I plan on adding event providers for each of the APIs I've outlined in the original issue description.

[Lokathor]

Winit is working on and/or already has released rawinput support on windows, I'd suggest contacting them and perhaps the two projects could come to an agreement of some sort regarding desired api

[Lokathor]

Winit is working on and/or already has released rawinput support on windows, I'd suggest contacting them and perhaps the two projects could come to an agreement of some sort regarding desired api

[francesca64]

Yeah, rawinput+xinput support are already living side by side on a branch I have, and the main reason I haven't put time into the other platforms is because (as always) I'm insecure about API design. If people tell me what requirements they have, it would be a lot easier for me.

(I can also guarantee that stdweb gamepad support will be happening, too!)

[francesca64]

Yeah, rawinput+xinput support are already living side by side on a branch I have, and the main reason I haven't put time into the other platforms is because (as always) I'm insecure about API design. If people tell me what requirements they have, it would be a lot easier for me.

(I can also guarantee that stdweb gamepad support will be happening, too!)

[Xaeroxe]

@francesca64 well if you'd like to see real world use we're merging in our API as we speak. I'd probably hook up winit events to our events if that could get merged and released.

[Xaeroxe]

@francesca64 well if you'd like to see real world use we're merging in our API as we speak. I'd probably hook up winit events to our events if that could get merged and released.

[Frizi]

@francesca64 My biggest "fingers crossed" moment when implementing this feature was about controller layout. SDL doesn't really handle it in a generic way. It just defines a very specific set of known buttons and axes, and everything that doesn't conform is just a "joystick" without any particular layout in mind. That does mean that you have a hardcoded limitation to basically supporting only xbox-like input, and anything beyond that requires serious effort and handling the mapping fully in your code.

This is really something I love if I just want a generic controller support, but it limits me from accessing features of say embedded touchpads (ps4) or steering wheels. I'm a bit clueless how it could be approached though, as I'm not sure what level of detail the controller is able to tell about itself to the system.

There is also a very important upside to that SDL approach, which is a standardised mappings format that allows for project like https://github.com/gabomdq/SDL_GameControllerDB to exist. If I could request one important fetaure, it would be to have something that allows the community to easily extend support to all weird devices that we can find in wild.

[Frizi]

@francesca64 My biggest "fingers crossed" moment when implementing this feature was about controller layout. SDL doesn't really handle it in a generic way. It just defines a very specific set of known buttons and axes, and everything that doesn't conform is just a "joystick" without any particular layout in mind. That does mean that you have a hardcoded limitation to basically supporting only xbox-like input, and anything beyond that requires serious effort and handling the mapping fully in your code.

This is really something I love if I just want a generic controller support, but it limits me from accessing features of say embedded touchpads (ps4) or steering wheels. I'm a bit clueless how it could be approached though, as I'm not sure what level of detail the controller is able to tell about itself to the system.

There is also a very important upside to that SDL approach, which is a standardised mappings format that allows for project like https://github.com/gabomdq/SDL_GameControllerDB to exist. If I could request one important fetaure, it would be to have something that allows the community to easily extend support to all weird devices that we can find in wild.

[jojolepro]

If you talk just about standard controllers, like steering wheels, gamepads, aircraft controllers, etc...
You have just 2 elements: Axes and Buttons.
If you make it so that controller has any number of axes and buttons, then you'll only have issues when you start to make more complicated things.
For example: Phone gyroscopes.

[jojolepro]

If you talk just about standard controllers, like steering wheels, gamepads, aircraft controllers, etc...
You have just 2 elements: Axes and Buttons.
If you make it so that controller has any number of axes and buttons, then you'll only have issues when you start to make more complicated things.
For example: Phone gyroscopes.

[OvermindDL1]

Even buttons can (should?) be an axis as well, they just jump from 0.0 to 1.0 and back (which makes it transparent to support buttons that are actually axis's where you can read the depressed amount). I just pretended everything was 0.0<->1.0 axis in my engine and it worked well.

[OvermindDL1]

Even buttons can (should?) be an axis as well, they just jump from 0.0 to 1.0 and back (which makes it transparent to support buttons that are actually axis's where you can read the depressed amount). I just pretended everything was 0.0<->1.0 axis in my engine and it worked well.