Hey. Sorry, I am rather curious: What kind of keyboard-destroying application are you developing that requires sub-millisecond accuracy for keyboard input handling, where people need to spam "REALLLLLLY hard" to make use of that?
The app isn't keyboard destroying at all - it only needs to handle about 12-15 keyboard presses per second. the sub-millisecond accuracy is the important part. There is a function in the game known as Delayed auto shift. Let delay = x milliseconds:
- On key down, action (A) happens
- If key is held down for at least x milliseconds, action (B) happens
Basically, the player wants either (A) to happen, or both (A) and (B) to happen.
Now this is where the keyboard accuracy is CRITICAL.
If the keyboard is accurate to 0ms (i.e. completely accurate...), and the Delay is x milliseconds then we know that:- The player must press the button for between 0 and x milliseconds (non-inclusive) for the game to detect (A)
- The player must press the button for >= x milliseconds for the game to detect (A) + (B)
But if the keyboard is accurate to y ms, and the delay is x milliseconds, then we know that:- The player must press the button for between y ms and x - y milliseconds (non inclusive) for the game to guarantee execute (A) but not (B)
The reason for this is that the input could be detected up to y ms late, so you have to press it y ms early, and you have to release y ms early because if the release is detected y ms late,the game will execute B
- The player must press the button for > x + y to guarantee that (A) + (B) occurs.
Ok, so now that i've explained the gist of it, let me reveal x and y.
x is user configurable - in current implementations it is a multiple of 16ms because the game runs at 60fps. However, we have argued that the user doesn't need to actually see the result of (A) + (B) so realistically x can be a multiple of 1ms. Currently for most people, X is on the order of 60-80ms.
y is currently on the order of 10ms.
That means, with x = 67 (4 frames) and y = 10ms:
The user must press for at least 10ms (easy)
and less than 57 ms (not easy) for (A)
The user must press for at least 77 (easy) to activate (A) + (B)
Notice that the error is 15% for (A) and 15% for (B)As x (the delay) decreases, y will stay the same, so the error will increase. Also note that due to this error, there is a delay floor.
Let's say that the minimum time a player can accurately press a key as a tap (vs holding it) is 50ms. The minimum "controllable" value of x would be a 60ms if the accuracy is 10ms. If the accuracy was 0ms instead of 10ms, then we could set x to 50ms instead of 60ms.
Now you're probably wondering why it needs to be so accurate:
Here's a video. x = 4 frames (64~ms), and y = 16ms (old engine, doesn't properly time inputs). Note that a player capable of playing at
x = 64, y = 16 would also be able to play at
x = 48, y = 0!!!! This would probably lead to a huge increase in performance!!!
https://www.youtube.com/watch?v=v3TJXSFnVS4So, what are (A) and (B)? (A) is tapping the left or right arrow. (B) is holding the left or right arrow. This activates DAS - which instantly shifts a piece to the wall.