Input Handling (State tracking)

[msiglreith]

The current event system allows handling of the input events from the window.
It's often more interesting to check the current state of the key pressed/released for games requiring manual tracking atm (e.g. pong example https://github.com/amethyst/amethyst/blob/develop/examples/04_pong/main.rs#L132-L144).

[ebkalderon]

Could we maybe make the keyboard events less verbose? I think they could probably be reduced to Event::KeyPressed(VirtualKeyCode) and Event::KeyReleased(VirtualKeyCode) instead.

[ebkalderon]

Could we maybe make the keyboard events less verbose? I think they could probably be reduced to Event::KeyPressed(VirtualKeyCode) and Event::KeyReleased(VirtualKeyCode) instead.

[nchashch]

Maybe we can add an InputHandler to Context, which would be updated according to incoming events in Application::advance_frame, and which would provide methods like: InputHandler::get_key_state, InputHandler::get_mouse_position, InputHandler::get_mouse_button_state, etc. So it won't be necessary to have something like InputState in pong example.

[nchashch]

Maybe we can add an InputHandler to Context, which would be updated according to incoming events in Application::advance_frame, and which would provide methods like: InputHandler::get_key_state, InputHandler::get_mouse_position, InputHandler::get_mouse_button_state, etc. So it won't be necessary to have something like InputState in pong example.

[ghost]

I usually like to write the event list into a state tracker of some sort. Something like this:

https://gist.github.com/csherratt/5647fad71f21d437bd8b561320f9228d

That way you can just query what keys are down each frame, rather then read all the events to listen for the key down event and saving it somewhere. It also has the events that were submitted this frame so that people can handle them in the way they want.

I imagine we might want to expand on something like this to include the config remapping. So you can query if the Forward button is down, and we can reference the W and the Up key. And the mappings would be from a config file.

Not sure how that would work with our current ECS based event system.

[ghost]

I usually like to write the event list into a state tracker of some sort. Something like this:

https://gist.github.com/csherratt/5647fad71f21d437bd8b561320f9228d

That way you can just query what keys are down each frame, rather then read all the events to listen for the key down event and saving it somewhere. It also has the events that were submitted this frame so that people can handle them in the way they want.

I imagine we might want to expand on something like this to include the config remapping. So you can query if the Forward button is down, and we can reference the W and the Up key. And the mappings would be from a config file.

Not sure how that would work with our current ECS based event system.

[nchashch]

I think you can do the remapping by implementing a system, which would listen to input and then update a custom ECS resource which would act simularly to InputHandler or publish custom events, like if InputHandler::get_key_state(VirtualKeyCode::Up) == KeyState::Pressed set MoveDirection resource to MoveDirection::Forward or publish a MoveDirection::Forward event using Broadcaster.

[nchashch]

I think you can do the remapping by implementing a system, which would listen to input and then update a custom ECS resource which would act simularly to InputHandler or publish custom events, like if InputHandler::get_key_state(VirtualKeyCode::Up) == KeyState::Pressed set MoveDirection resource to MoveDirection::Forward or publish a MoveDirection::Forward event using Broadcaster.

[yeliknewo]

Would it be valuable to also have a timestamp as well as the KeyState stored? That way you can tell when it was pressed for things like delayed input.

[yeliknewo]

Would it be valuable to also have a timestamp as well as the KeyState stored? That way you can tell when it was pressed for things like delayed input.

[ebkalderon]

@yeliknewo That would be a good idea. I think that every event should have a timestamp attached to it somehow, and if you wanted to delay an event, you would just set the delivery timestamp forward X number of milliseconds. Most engines take that approach for recording and replaying demos: start with an initial world snapshot, and then replay a stream of recorded events with correct timings to replay the original gameplay.

[ebkalderon]

@yeliknewo That would be a good idea. I think that every event should have a timestamp attached to it somehow, and if you wanted to delay an event, you would just set the delivery timestamp forward X number of milliseconds. Most engines take that approach for recording and replaying demos: start with an initial world snapshot, and then replay a stream of recorded events with correct timings to replay the original gameplay.

[msiglreith]

Feature request from gitter:
Add function to return an iterator over the currently pressed keys

[msiglreith]

Feature request from gitter:
Add function to return an iterator over the currently pressed keys

[ivandardi]

Now that the feature request from gitter has been implemented, this issue can be closed.

[ivandardi]

Now that the feature request from gitter has been implemented, this issue can be closed.

[Aceeri]

I think we might want to keep it open a bit (or maybe open a new one with all interested features like action mapping, etc.)

[Aceeri]

I think we might want to keep it open a bit (or maybe open a new one with all interested features like action mapping, etc.)

[msiglreith]

Should close this and add new issues for the different features. As the current one is pretty vague and only was a starting point to implement basic functionality.

[msiglreith]

Should close this and add new issues for the different features. As the current one is pretty vague and only was a starting point to implement basic functionality.

[ebkalderon]

I am inclined to agree with @msiglreith. Since we have basic input handling support already, we should open separate issues for the other features built upon it. I'll take care of that now.

[ebkalderon]

I am inclined to agree with @msiglreith. Since we have basic input handling support already, we should open separate issues for the other features built upon it. I'll take care of that now.