I have introduced an error type in FishFight, so that we can convert remote errors into this type, to make it less of a hassle to work with all the various Error types in the various dependencies. It would therefore be helpful to have an Error type in fishsticks, so that I can set the appropriate ErrorKind for these errors in the From implementation used to convert into FishFight error. This does not need to be anything comprehensive; I believe a type Error = &'static str will suffice.

I'll create a PR for this

This adds a From<&GamepadId> implementation to usize so that we can use the index to look up sets of gamepad button mappings, among other things.

@PotatoTech

I want to publish rust-rpg-toolkit to crates.io but that is currently not possible as they do not allow crates to have git as the sole source for any of their dependencies.

I made some additions to Cargo.toml in #15, in preparation for publishing and if you have no objections to publishing now, I can do it, as I have everything set up for it. As it is your project, you might want to do it yourself, though, so you get ownership...

Right now, users query the gamepad context for references to gamepads, which they then query for input state. This makes it difficult to support multiple backends with different gamepad types, as some (e.g. gilrs) have lifetimes, while others (e.g. SDL2) do not. We do not want users to deal with unnecessary lifetimes just because one implementation requires them. A better way is to eliminate all public gamepad references and just have users query the gamepad context directly for input state.

Now that the backend and the public API are more loosely coupled, we should implement gilrs as a second backend. People who do not want to depend on SDL2 just for its game controller subsystem could use this instead.

Previously, users choosing the gilrs implementation were forced to compile SDL2, even when it was not used. Now, they can avoid this by disabling default features.

Fixes #7.

This addresses the lifetime issue described in #12 but uses an alternative solution. We only store the implementation gamepads if the implementation requires us to own them, as is the case with SDL2. If the implementation owns and manages its gamepads, as is the case with gilrs, then we have no need to store them, since we can just query the implementation's context to retrieve references to the gamepads.

Currently, the deadzones for analog inputs are fixed. There should be a way for users to customize them. This could be done when they initialize the GamepadContext, or it could be done by calling a method on the context.

Fixes #5.

I left Axis and Button public for the sake of simplicity, but they can be placed behind wrappers in the future if we want to support users changing the backend arbitrarily.

GamepadId is public as well, but the SDL2 implementation already defines it as a wrapper anyways, and I saw no reason to put a wrapper around a wrapper. One alternative is to define a type alias in the implementation instead of a wrapper. Then, GamepadId can be defined in the crate root as a wrapper around the implementation's id.

Currently, the library only supports using SDL2 as the backend. To support other backends, such as gilrs, Gamepad and GamepadContext should act upon an interface that abstracts away the backends.

Fixes #1.

• Analog interface now returns only f32 and Option<f32>
• Added methods for treating analog inputs like digital values
  • Digital methods use a separate deadzone

I am doing some testing with WASM and I noticed that the Axis type, used as argument to [..]::digital_value varies from backend to backend.

We should probably create a common enum type that can be used in our API and, if needed, be converted to the appropriate type by the individual backends, in stead of using generics.

The library does not compile when targeting wasm32-unknown-unknown and using SDL2. The C library can compile to WASM via Emscripten, so it should be possible to make it work.