core: improve InputState #1075

Open
opened 2023-10-18 17:35:47 +00:00 by emidoots · 1 comment
emidoots commented 2023-10-18 17:35:47 +00:00 (Migrated from github.com)

pressed is true the entire time a button is down
justPressed is true only the first frame it is down
justReleased is true only the frame it is released
it also provides easy enumeration of the key state for making event-based input wrappers (for remapping support and to abstract keyboard/mouse vs gamepad)
InputState doesnt really have enough data basically. its just raw state of a button

I'd be OK with adding justPressed and justReleased semantics as you described above (though I'm not sure about the naming of those)

Your pressed case should already be handled by InputState

I don't know what you mean about enumeration of key state, but if it's just the bitsets for the same then I am fine with that.

I don't think InputState/mach-core should handle remapping or abstraction of keyboard/mouse vs. gamepad differences

Ref https://discord.com/channels/996677443681267802/1164251188519252070/1164253490940489748

> pressed is true the entire time a button is down > justPressed is true only the first frame it is down > justReleased is true only the frame it is released > it also provides easy enumeration of the key state for making event-based input wrappers (for remapping support and to abstract keyboard/mouse vs gamepad) > InputState doesnt really have enough data basically. its just raw state of a button I'd be OK with adding `justPressed` and `justReleased` semantics as you described above (though I'm not sure about the naming of those) Your `pressed` case should already be handled by `InputState` I don't know what you mean about enumeration of key state, but if it's just the bitsets for the same then I am fine with that. I don't think InputState/mach-core should handle remapping or abstraction of keyboard/mouse vs. gamepad differences Ref https://discord.com/channels/996677443681267802/1164251188519252070/1164253490940489748
emidoots commented 2023-10-18 17:54:07 +00:00 (Migrated from github.com)

Better naming suggested by foxxne:

down = true always if key is pressed down
up = true always if key is not pressed
pressed = true the frame the key is pressed
released = true the frame the key is released

Also my thoughts:

it's good that InputState handles most folks' use cases (what it is intended to do) but it's not good that it gives the impression it might be the best source of data, since events are that and you lose the ability to handle events mid-frame or outside the render loop
maybe pollEvents should take a parameter or something to decide if InputState should be updated, unsure

Better naming suggested by foxxne: > down = true always if key is pressed down > up = true always if key is not pressed > pressed = true the frame the key is pressed > released = true the frame the key is released Also my thoughts: > it's good that InputState handles most folks' use cases (what it is intended to do) but it's not good that it gives the impression it might be the best source of data, since events are that and you lose the ability to handle events mid-frame or outside the render loop maybe pollEvents should take a parameter or something to decide if InputState should be updated, unsure
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
hexops/mach#1075
No description provided.