Input Handling (State tracking) about amethyst HOT 11 CLOSED

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

from amethyst.

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.

from amethyst.

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.

from amethyst.

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.

from amethyst.

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.

from amethyst.

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.

from amethyst.

@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.

from amethyst.

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

from amethyst.

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.)

from amethyst.

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.

from amethyst.

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.

from amethyst.