not sure if this is exactly a bug, but i can't imagine any issues from it not having this behavior
when multiple keys are pressed on the same frame or two, snap only registers the first one of the whole bunch, so some are lost. if the sprite isn't open in the editor the effect is worse depending on how long the script takes to run
there were some other issues i had but it's unrelated so i made a seperate post
post before edit (i got things wrong)
every (or most, i haven't actually checked) hat block has a system where it doesn't start again if it's already running, but whatever causes that seems to not allow it to run multiple times in a frame.
if many key presses happen in one frame, they happen one after another on the next frames instead. this even happens on turbo mode.
maybe too many key presses aren't handled on the same frame because it could take too long without yielding? i think it should be handled like a loop in turbo mode, where it tries to do as many as it can before it yields.
no it isn't
i would elaborate here but i'm not sure what i'm even supposed to say, it's just not how the web apis work and there's too much to go over to try and predict every reason you might say that
Actually after re-reading your post, I now understand what you're saying. I don't see why the current behavior should be an issue. You shouldn't be making frame perfect key pressing using the when key pressed blocks anyway.
The Snap! "processing step" is effectively a "tight loop". The JS Event Loop only works when snap is yielding. So keypress is "registered" between animation frames (step) - suspended thread for a hat processing is created but with a "reentrance policy", mostly avoiding duplication.
BTW: @60FPS frame time/delay is 17ms. It is unlikely that a regular PC keyboard emits multiple events in that period.
For more complicated scenario you can use
"^when any key pressed^" combined with multiple ""
i still don't see why that would be an issue, it should still be able to keep track of all the key presses that happen before the next animation frame
also fair enough about the key pressing speed, i can only get one key every 20ms when i tested. the bug isn't actually what i thought it was, there's multiple bugs:
multiple keypresses on the same frame only registers one (not sure which one, probably the first or last)
key pressed can only run every OTHER frame (every ~33ms) (i think)
many different keys all run on frames after, any of the same key doesn't (i THINK, it's a bit hard to test this)
It's quite obvious. The processing step is performed every 17ms so with 20ms keypress auto-repeat delay, one frame is skipped.
Keyboard behavior is highly configurable. I've made a test script that counts the frames and log the keys state {"q", "w", "e"}
There is a log for high delay settings:
Autorepeat starts after 67frames (1s) and repeats every 25 frames (~1/2s)
For the lowest settings:
20 and 2 frames, respectively.
I've also tested frequency of manual keypress. Even on gaming keypad I'm was not able to go below 7
frames (100ms).
I've checked also concurrent keypress and found that my hardware limit it to 2 keys at once
To made the tests more reliable, we can program some MCU as a HID device generating keyboard event with the desired pattern.
I suppose you made a minimal reproducible example to check hardware/OS/JS limitation and how it may affect your problems.
my issue isn't frame perfect keypresses, my issue is that if someone mashes the keyboard it can take a while for it to catch up to everything that was pressed, and some inputs get lost.
my keyboard autorepeat is set to 60hz, and that's not the only way i tested it. i tested it also by pressing many different keys, without holding them. i can press keys every 20ms or so, and i have n-key rollover (your keyboard is 2 key rollover, it only detects two keys pressed at once)
your test script isn't valid either because you're testing it in snap, exactly where the bug happens. you likely can only press keys every 7 frames because you only have two keys you can press, and are testing it in snap where it doesn't detect every keypress.
my issue is that i was dumb enough to NOT set up a minimal reproducible example, i made an actual test project now and only got the first bug, my key repeat is fine. VERY sorry about that.
i'll need to start stripping down my project to figure out why it's having issues
i reported that one after when originally i posted mulitple bugs here, they're two unrelated bugs
the slowdown doesn't reduce the number of keys registered, it does them one after another in order, just late
test script
