-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Key repeat behavior on macOS #127
Comments
Here's an example output:
Using the following struct Test;
impl Input for Test {
fn update(&mut self, event: input::Event) {
println!("{:?} at {:?}", event, SystemTime::now());
}
fn new() -> Self { Self }
fn clear(&mut self) {}
} You can see the first |
I guess one approach to solve this problem is to do custom tracking of keyboard state. It would probably be something like:
But I wonder if this should "just" be handled by the engine instead, similar to what ggez is doing? |
Another problem I noticed with this (which would be solved by my above suggestion of keeping state around), is that holding down two keys simultaneously does not trigger the repeat event for one of those keys (which, my guess would be, is the one that was pressed first):
I removed the |
Alright, I should have checked the The reason why I forked the implementation though, is because I wanted to have access to the I'll create a PR to see if you are okay exposing those details in the public API. |
I have a small example that moves a circle across the screen based on
WASD
input.From experimenting on macOS, it appears that Coffee respects macOS's key repeat preferences:
On the one hand, this is obviously a nice thing to have, as it gives the player control over the behaviour. On the other hand, this is unexpected behaviour for games.
Specifically, even with my preferences set to fast/short, there is still a noticeable delay from the "Delay Until Repeat" option. This means that if I press and hold
A
to move the circle to the left, it will move to the left once on press down, it will then stop moving for a moment even though A is still held down, and then start moving again as soon as the "repeat" kicks in, until I release the A key.I've experimented with ggez as well, and that game engine behaves as "expected" on macOS (quotations here because the game behaviour differs from default operating system behaviour, but I believe ggez' behaviour is what people expect in a game).
Given that both engines use
winit
as a dependency, but ggez is still using0.19
and Coffee uses0.22
, I suspect it's actually a change in behaviour between winit versions, and I would also suspect that change in behaviour is considered to be a fix, since regular macOS windows are expected to behave this way, but I don't think this is expected for games.Alternatively, Coffee shouldn't treat key input as "text input". There's some investigation for Piston I found here: PistonDevelopers/piston#1220 (comment).
Another reference is to a long-standing issue for Winit to discuss a better input model, see: rust-windowing/winit#753
And finally, looking at ggez, it appears that they've implemented this behavior themselves by tracking
is_key_repeated
.Although I'm not quite sure (yet) how that works, as that still doesn't explain why ggez doesn't have a delay between the first key and the repeat, whereas Coffee does.
The text was updated successfully, but these errors were encountered: