Event based tetris discussion

[myndzi]

Another thing worth considering is how people use DAS. To use something like instant DAS without error, you have to be able to reliably distinguish durations of keypresses between "less than" some threshold and "more than" some threshold. It doesn't actually matter how MUCH more, or how MUCH less. If the threshold is set at some value, say 100ms, and the variability of the keyboard event timing is 16ms, then effectively you must either tap faster than 100-16=84ms or hold longer than 100+16 = 116ms to be guaranteed the effect you desire. The lower the DAS is, the faster you have to tap; holding isn't really a problem since you can 'overdo' it without harm. A thing to measure: how stable is your tapping duration during normal play?

I'm not convinced anyone needs to be able to play reliably at 2 frame instant DAS to get the most speed they're capable of, but anyone who crams their DAS down fast will need stable down-up key times.

Problem is, at the resolution we're talking about, it's not like we can ask a person if they were accurate in their timing. Perhaps some external macro program, assuming it can be proved to be a reliable timing source, can be used to measure variance of inputs in a target environment by generating key events?

For example, since Chrome rocked the timer test, and presumably this has to do with the timer interval thing, perhaps someone with familiarity with AHK can 1) use the tool above to adjust the appropriate setting, 2) verify whether AHK can reliably produce exact timer intervals and 3) use AHK to send key events to say, a browser, repeatedly, and see what the effective difference is in the browser *receiving* those events?

[XaeL]

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
stuff
[/quote]
Thanks for your input Simon, it's great to have a pr0 dev answer our questions

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
LWJGL timestamps all input events for you.
[/quote]

Yes/No. I only speak for windows, but:

• In 2.x, timestamps are only "rounded" to 16ms values. The test i used was the following: Set game loop to Display.sync(20), call drawDisplay, then look at keyboard.eventlist, printing out all the getEventNanoSeconds(). Spam keyboard and look for smallest non-zero difference. Result was 15-16ms
• 3.x you assign a callback handler, and whenever LWJGL gets input it will call that handler. This method does NOT provide a timestamp, so i used a global frame counter to determine whether inputs were detected on different frames, as well as System.nanoTime() to determine timings. Here, the non-same-frame times were lower - on the order of 10ms. On top of that, numbers above 10ms were *not* rounded to 16ms.

From the evidence, it appears that 3.x has a higher resolution.

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Input latency depends on the API, but is generally extremely low.
[/quote]
Without a voltage meter thingy, it wouldn't be easy to measure input latency. It's out of our control anyway, but the LWJGL library uses Windows API's for keyboard input. It previously used DirectInput, which *may* have a lower latency and potentially higher polling rate. Here's a flowchart:

Code Select Expand


keyboard -> computer -> rawInput/directInput -> windowsKeyboard -> lwjgl -> yay you got input


the rawInput/directInput resolution is 1ms from what I have read.
The windowsKeyboard has an unknown polling rate (it might poll rawInput once every 16ms for instance). It might add delay, or it might be negligible.
The lwjgl stage has negligible input (i read the code it just calls the windowsKeyboard straight up)

We could write a windows specific driver that bypasses it, but we wouldn't know if it actually increases accuracy until we've written it.

So right now, the windowsKeyboard stage could potentially be clamping inputs to 5ms by only updating every 5ms or so. but WE DON'T KNOW.

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Timer resolution can be set to 1ms under Windows, but there's no reason to use timers in an event-based engine anyway.
[/quote]
I agree. if your code is something like

if (left_key_down) {
  start_a_newThread_that_waits(80milliseconds);
}

that is bad because of thread overhead and sleep accuracy.

Instead:

Code Select Expand

if (left_key_down) {
   left_key_timestamp = blah;
   global.event_queue.addEvent(left_key_timestamp+dasDelay, dasEvent);
}

//later
//at start of frame:
//parseAll inputs with timestamps by dumping them into your own event queue. NOT by immediately evaluating them.
//process everything in event_queue up to this.currentTime
//this means that if we pollInputs and you have a "release_das", it could go *after* your dasEvent

//also means game loop only updates 60hz but is still perfectly accurate in terms of events timing.



[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Timer resolution should not be set to 1ms for energy consumption reasons. Less important for games.
[/quote]
Setting to 1ms can be good if it has an impact on how accurate windows input-polling is. In lwjgl 2.0 and 3.0, it appears to have no impact. But in web-browsers, i *think* it does.

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Measuring time can be done cycle accurate (ns).
[/quote]
I agree. Measuring time intervals for das can be done like 0.000x millisecond accurate. Detecting keyboard presses (ups and downs) is the "bottleneck"

CONTINUED in next post. reached max quotes

[XaeL]

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Low-speed USB devices communicate events with polling, usually at <100 Hz. That's why you won't get low latency out of an USB keyboard.
[/quote]

I have a "gaming keyboard" which claims to be 1000hz. from Lwjgl i get 10ms minimum time difference between items not polled on the same lwjgl.poll cycle.

PS/2 keyboards, which are "interrupt-driven" aren't much better: they only send 1 key-event at a time from my testing. If you send 8 inputs simultaneously, it will report it across 40ms with 5ms gap, but in reality it was pressed within a 10-15ms window.

Here's a diagram to illustrate what I think happens

Code Select Expand


Time Pressed (this is a guess) (ms) | 0 2 4 6 8 10 12 14
Time reported(lwjgl) | 10 10 10 10 10 10 10 20
Time Reported(ps/2) | 0 5 10 15 20 25 30 35 40


For our use case, since less than 20 inputs per second, and almost no chance of pressing multiple keys in the same 16ms window, ps/2 has the clear advantage. However the time reported is VERY important since DAS delays are on the order of 50ms (3/60 frames of das) !!
[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Redraws happen at most at screen refresh rate. There's no reason to render at above screen refresh rate. You wouldn't see the results quicker.
[/quote]
Agree, but you can run your input handling code not at screen refresh rate. you should be handling events at infinite resolution (this is what lwjgl 3.0 lets you do) and rendering every 1/60. This reduces chances of framerate dropping. Here's a diagram illustrating what i mean. Basically i'm saying that during the "sleep till end of 1/60" if an input occurs you could be processing that input, giving you more leeway before the next 1/60 "deadline"
[!--ImageUrlBegin--][a href=\\\"https://sites.google.com/site/xaelous/semi-clear%20diagram.png\\\" target=\\\"_new\\\"][!--ImageUrlEBegin--][img width=\\\"500\\\" class=\\\"attach\\\" src=\\\"https://sites.google.com/site/xaelous/semi-clear%20diagram.png\\\" border=\\\'0\\\' alt=\\\"IPB Image\\\" /][!--ImageUrlEnd--][/a][!--ImageUrlEEnd--]





[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
This means you should do DAS at refresh rate (often 60Hz/~15ms), timestamp events (extremely accurately) and do the appropriate calculations at infinite resolution.
[/quote]

If you are saying do DAS in multiples of 15~ms, i disagree. You don't have to SEE your piece to das it. E.g. if your DAS is 3.5 frames you can still execute a das 3.5 frames and then tapback without SEEING it.  Do you think players look at their pieces when they das and WAIT for visual confirmation before pressing the next input? That would be incorrect since human reaction speed is order of 100+ms and DAS for even moderate players is on the order of 80ms. They are not "reacting" to something they see, they are just pressing inputs at a predefined/practised timing. If you are not reacting to visuals then why would you lock inputs to the visuals?

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
That's (almost) what I do in Cultris II. Problem is though, that in practice there are shitty drivers, shitty hardware and shitty configurations that will severely limit what you can achieve.
[/quote]

Agree that windows is a POS.

I'm not convinced anyone needs to be able to play reliably at 2 frame instant DAS to get the most speed they're capable of, but anyone who crams their DAS down fast will need stable down-up key times.

I agree no one can probably play at 2 frame das coz their up down speed must be probably inhumanely fast. The main reason for millisecond accuracy vs 1/60hz is that this enables 3.5 frames (for example) das which IS probably achievable vs 3 frames (which is probably not). Again I agree with your accuracy of the input changing the window that they are able to tap/vs hold in.


[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
If the threshold is set at some value, say 100ms, and the variability of the keyboard event timing is 16ms, then effectively you must either tap faster than 100-16=84ms or hold longer than 100+16 = 116ms to be guaranteed the effect you desire.
[/quote]
Very very good sentences here. I think the current "bottleneck" is this variability

[Okey_Dokey]

• Timer resolution can be set to 1ms under Windows, but there's no reason to use timers in an event-based engine anyway.
• Timer resolution should not be set to 1ms for energy consumption reasons. Less important for games.

You are setting timer resolution to 1ms in Cultris 2, arent you? At least, that's what the program tells me that Xael linked.

I know, that Cultris 2 uses 2 threads. One for graphics and one for updating keypresses/gamelogic. Do you tell the latter thread to sleep? Speaking of DAS in Cultris 2, it feels rather slow on my computer. Either I have to use a high repeat delay or I encounter misdrops (pieces move to the wall when I just tap). But that's pobably because of the expensive graphics rather than the update logics.

[myndzi]

Again "pressing a bunch of keys at once" is not a very good gauge of efficacy. I could potentially see one interrupt getting handled at a time from a PS/2 keyboard being the cause of the "increasing timestamps per key", whereas polling USB almost certainly returns a batch of data every one call. However, in actual play, you might have two keys at one time -- shift and rotate -- and even then it's pretty hard to press them exactly at once to begin with, nor is it necessary. Since the ordering of key inputs is very deliberate especially when utilizing perfect finesse, the player is definitely being distinct about "before or after" with many inputs.

So, who really cares if you can't send 10 inputs at once? What matters is ordering and accuracy of down-up timings. Any other latency in the pipeline should apply to everything equally, and we're already used to that sort of thing (see: fast players on TGM3 which is known to have pretty bad input lag even on the hardware).

The biggest problem is unexpected behavior, not time-shift (though minimal input delay is certainly the most desirable)

(In summary, the prior conclusions still seem to be accurate: process keyboard events as best you can, with timing and ordering info, and don't sweat the rest)

[XaeL]

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
Again "pressing a bunch of keys at once" is not a very good gauge of efficacy.
[/quote]
I think it's an ok test for attempting to find the minimum distance between messages. Remember just doing a down-up test with one key is also bad because your keyboard has debounce. other keyboards might have shorter debounces. The "bunch of keys at once" test is just to test that if a keyboard had 0 debounce, how fast can it send an down-up through the OS etc. The down-up test is the same test but also adds the debounce factor. If you can consistently get say x milliseconds between inputs it would lead to strong evidence that your das keydowns and key-ups are accurate to x milliseconds.

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
I could potentially see one interrupt getting handled at a time from a PS/2 keyboard being the cause of the "increasing timestamps per key", whereas polling USB almost certainly returns a batch of data every one call.
[/quote]
Yes i think i forgot to mention that but i was trying to imply that just because PS/2 had increasing timestamps didn't mean it was any more accurate than USB.

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
However, in actual play, you might have two keys at one time -- shift and rotate -- and even then it's pretty hard to press them exactly at once to begin with, nor is it necessary. Since the ordering of key inputs is very deliberate especially when utilizing perfect finesse, the player is definitely being distinct about "before or after" with many inputs.
[/quote]
again the mash keys test isn't to test whether hitting shift+rotate on same frame will occur, since this won't happen in practice, it's just a different way of testing down-up accuracy.

[!--quoteo--][div class=\\\'quotetop\\\']QUOTE[/div][div class=\\\'quotemain\\\'][!--quotec--]
(In summary, the prior conclusions still seem to be accurate: process keyboard events as best you can, with timing and ordering info, and don't sweat the rest)
[/quote]