Rework inputs #87
Labels
No labels
0. Imported
1. Bug
1. Clean-up
1. Feature
1. Improvement
2. Deliverable
2. Epic
3. Duplicate
3. Invalid
3. Need investigation
4. Assets
4. Birb Core
4. Debug
4. Dependencies
4. Inputs
4. Lang
4. Scenes
4. Screen
4. World
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: epervier/epervier-old#87
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In love, inputs are handled two ways
In our system, we don't have an equivalent of the first, but we would prefer to go more to an event-based system. The current input system is kinda overcomplicated, and it would be good to simplify it, try as much as possible to transform inputs into a thin translation layer.
We have two possibility here:
TODO
It would be interesting to rethink to replace the virtualpad API by a "binding" API, a bit like :
And then events would be:
API list for bindings:
<keyname>
called if key is down<keyname>:pressed
called if key have been pressed<keyname>:released
called if key have been released<dirname>
called every frame (argument is a point with value between 1 and -1)<dirname>:axis
called every frame for an axis (give its value between 1 and -1)<dirname>:key
is the equivalent of<keyname>
for a keyThe input would be passed like that:
-> If the scene have an action for the input, call the input
-> If a gui element is active/have foucs, catpure all remaining event
-> If the world have an action for the input, call the input
-> If the player object have an action for the input, call the input
Not for the moment, maybe one day