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

Added Windows gamepad support #579

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

AmelieHeinrich
Copy link
Contributor

@AmelieHeinrich AmelieHeinrich commented Aug 23, 2022

Gamepad support for Hazel

This pull request contains the basic implementation of a gamepad input system. It only supports regular gamepads, so it isn't possible to connect a guitar hero controller for example.

Why?

Having an interface for gamepad input will be useful if Hazel ever gets ported to console. It's also very important for an engine to support gamepad input, as it is one of the most popular input methods in the industry.

How does it work?

Additional functions have been added to the input class to poll button state, trigger state, joystick state and vibration state.
Some additional enum values have been added to map ABXY buttons to the Dualshock's square, cross, rectangle and triangle button.
The input system handles deadzone values as well.
You may also notice that there is three new functions in the input class: Init, SetEventCallback and Update.
Init is used to initialise input polling libraries (XInput on Windows for example)
SetEventCallback is used so that the input system can send GamepadConnected and GamepadDisconnected events.
Update is used to actually update the state of the gamepads.

Example code

if (Input::IsGamepadButtonPressed(0, Gamepad::A))
    Input::SetGamepadVibration(0, glm::vec2(1.0f)); // Full speed on both motors

glm::vec2 leftJoystick = Input::GetGamepadLeftJoystick(0);
playerPosition.x += leftJoystick.x * dt;
playerPosition.y += leftJoystick.y * dt;

What you might ask

  • Why the fuck didn't you use GLFW for gamepad polling you absolute idiot?
    Because GLFW doesn't support gamepad vibration.
  • Why is gamepad connect and disconnect an event? Can't you just add a Input::IsGamepadConnected function?
    No, because gamepad connection and disconnection should be handled as notifications : not just a plain old boolean state
  • Without GLFW, it's not cross-platform, dude...
    LOL as if Hazel was cross-platform KEKW (on a serious note, when Hazel will be able to build on both Mac and Linux, I'll add
    the necessary backends for Apple's GameController framework and Linux joystick file descriptor)

What could be added

  • Swap A & B buttons if the controller is a Nintendo Switch gamepad
  • Get the battery state of the gamepad (XInputGetBatteryInformation)

@gamecoder-nz
Copy link

Nice. I wasn't aware that glfw doesn't support gamepad vibration

@gamecoder-nz
Copy link

Have you implemented this for mac and linux already?

@AmelieHeinrich
Copy link
Contributor Author

Have you implemented this for mac and linux already?

Already adressed in the QNA:

LOL as if Hazel was cross-platform KEKW (on a serious note, when Hazel will be able to build on both Mac and Linux, I'll add
the necessary backends for Apple's GameController framework and Linux joystick file descriptor)

@drsnuggles8
Copy link

Any specific reason for moving the EventCallbackFn?

@VagueLobster
Copy link
Contributor

VagueLobster commented Nov 22, 2022

Any specific reason for moving the EventCallbackFn?

I think the OP chose to move it so it was easier to use: static void SetEventCallback(const EventCallbackFn& callback);
inside of Input.h and virtual void SetEventCallback(const EventCallbackFn& callback) = 0; inside of window.h, but maybe it won't even work if not moved, i haven't delved too much into it 🙂

@AmelieHeinrich
Copy link
Contributor Author

I think the OP chose to move it so it was easier to use: static void SetEventCallback(const EventCallbackFn& callback);

inside of Input.h and virtual void SetEventCallback(const EventCallbackFn& callback) = 0; inside of window.h

Correct. It's just so that the input system can also access the EventCallbackFn type. No reason not to move it for clarity.

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

Successfully merging this pull request may close these issues.

4 participants