You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hate it when I lean on a key and the next thing I see is "Game Over". Even on the fastest computers, key autorepeat generates commands faster than the game can execute and display. If we can avoid commands with multiple keypresses (except via menus, be them GTK, or ASCII) then we can assume that each keypress is one command and so between consecutive frames, only one keypress should be accepted. Either the last one, with the previous ones ignored, or the first one, with the subsequent keys generating a beep, warning and perhaps canceling the first one, too.
Ideally, it should be all sequential: frame, keypress, frame, keypress. But GTK is highly asynchronous and even the wait for the keys is so and the low-level autorepeat mechanism. Moreover, I like it that window resize or font change in our gtk backend is asynchronous. So probably we have to decide some method of trimming the keypress sequence for each frame.
The text was updated successfully, but these errors were encountered:
Instead of ignoring keypresses when there are too many, I will minimize latency so that it's hard to accumulate not yet acted upon keypresses. In particular, any keypress will fast forward all animations. Closing.
I hate it when I lean on a key and the next thing I see is "Game Over". Even on the fastest computers, key autorepeat generates commands faster than the game can execute and display. If we can avoid commands with multiple keypresses (except via menus, be them GTK, or ASCII) then we can assume that each keypress is one command and so between consecutive frames, only one keypress should be accepted. Either the last one, with the previous ones ignored, or the first one, with the subsequent keys generating a beep, warning and perhaps canceling the first one, too.
Ideally, it should be all sequential: frame, keypress, frame, keypress. But GTK is highly asynchronous and even the wait for the keys is so and the low-level autorepeat mechanism. Moreover, I like it that window resize or font change in our gtk backend is asynchronous. So probably we have to decide some method of trimming the keypress sequence for each frame.
The text was updated successfully, but these errors were encountered: