In (at least my) ideal world, both values n1 and n2 should never be more than 1 or less than 0, as to every keyPressed() event there should be a corresponding keyReleased() event. However, very easily, I can end up with this:
I find this to be problematic, as I’d like my keyPressed() events to be triggered.
If I’m pressing a single key without holding any other, events are never missed.
After I start holding the first key, only the first press of the second key may be missed - all subsequent presses of the second key are not missed.
This happens only on P2D and P3D engines, and doesn’t happen on JAVA2D engine (if I disable key repeating - else the keyPressed() gets activated very quickly a lot of time).
This happens with any pair of keys, not just keys 1 and 2 - arrow keys, J and ENTER, any.
This happens when I use both Processing by itself, and when I use Processing libraries in Eclipse.
This does not happen in any other non-Processing applications or games I’ve tried.
I’m running on Arch Linux with all packages updated, with Processing installed from Arch Linux repositories, package version 3.5.3-2, while Processing labels itself as “Processing 0269”
Here’s even a proof of concept (shoddily filmed from a phone; I’m sorry!) video:
Anyone have any ideas on how to get more reliable key press/release events on P2D and P3D engines? Is this a bug?
Definitely a bug which exists for you, but I haven’t observed your issue. But in any case you don’t need to use integer anymore do you ? You said it yourself in an ideal world you only are supposed to get 1 or 0 and you already have that… The boolean so you don’t really need the numbers to check if the keys are being pressed. But if you still want to use the numbers to observe if they are pressed.
Sharing an initial exploration into what your code is doing.
I used “keyCode” in place of “key”.
You can see the “keyCode” in the console; “Shift 1” is “keyCode” 3 etc.
Using the console is a good tool for debugging.
Your sketch did not present any problems here unless I hit the “Shift” key and numbers 1 and 2 on numeric keypad rapidly on and off :
Actually I’ve meant that in an ideal world, code inside of keyPressed would be run every single time a key is pressed down, regardless of what other keys are held or not in the meanwhile.
In all of my code, when needed, I obviously use booleans. The problem still exists though, as sometimes the keyPressed() event is not triggered, so n1 stays as 0 and held1 stays as false even if I’ve pressed and am holding 1, which means that I can’t observe either the boolean or the integer to reliably get the current state of the key.
In my example I’ve used integers only to demonstrate my problem.
Isn’t this because SHIFT+1 is actually ! (exclamation mark), which does not count as 1? If so, I guess that means that you can hold down 1, but then release an unrelated key !, without ever releasing 1 or pressing ! in the first place.
I guess that’s how the counter is going off into negatives in your case, i.e. not the same thing
Yeah, I figured. I don’t like it though, and I’m sure there’s someone else in the world dealing with the same problem and not knowing that this forum exists or not bothering to ask about it… maybe…
All I want to do right now is get to the core of this problem, find out why I’m experiencing it, and get rid of it, and I’m looking for anyone’s help with this as I don’t think I can dig that deep into Processing source code to get to it.
It’s at software level - I’ve tried it on the built-in laptop keyboard and 2 USB keyboards, and the problem still existed there, only on P2D/P3D Processing sketches, and absolutely nowhere else.
Would be weird if a keyboard knew what software I was using it in and would have a sentient mind of their own, deciding to not send key press events on that specific kind of software just to mess with me!
so you install win 7 over win 10 on that laptop?
might have lost a needed keyboard driver?
i am not good with that stuff, but my point is that we have some reports about
how many keys ( pressed at the same time ) can be detected ( by processing )
and it was always the keyboard what caused problems.
No, I’ve nuked Windows 10 and installed Arch Linux ontop, which I’ve noted to be my OS in the first post.
Drivers and the keyboard must be allright, considering that out of many applications, including those using SDL, OpenGL, basic drawing on the window, GTK/QT frameworks, Steam, WebGL browser games, Processing JAVA2D, internal Linux TTY console(outside of anything that renders windows) and more, only Processing P2D/P3D sketches act this way.
I’m uncovering more right now - the problem seems to be related to key repeat delay/rate i.e. the function of the OS where holding a key for long enough it starts repeating the keyPressed() event.
If I disable key repeating (with terminal command xset r off) the problem goes away instantly and I can’t reproduce the issue.
However, if I set repeat delay to 0 (i.e. so that it starts repeating the key instantly as soon as I start holding it, making it impossible to type) and repeat rate to 255 (maximum possible, 255 characters per second) (both with command xset r rate 0 255), the keyPressed() event of the second key misses almost always.
From that I guess that it misses keyPressed() event of a key only if another key is pressed at the same time due to being repeat-pressed by the OS.
I guess this can be explained by P2D/P3D dropping repeated keyPressed() events too sparingly, and by dropping such event at the same time another key is pressed, it drops the keyPressed() event for that key instead, and results in missing it. That is reinforced with JAVA2D renderer not dropping repeated keyPressed() events and not having this issue.
I believe that this is a bug in Processing’s P2D/P3D engine’s key processing code, specifically the one responsible for dropping repeated key events.
I guess I’m the one who points it out after so much time is because my preferred key repeat delay/rate are a bit too extreme compared to normal user’s (xset r rate 170 60, i.e. 170ms delay and 60 presses per second - coincides with P2D’s 60 frames per second therefore I’m having the issue?)
I think I’m ready to go write a smart sounding GitHub issue for it to be fixed now, but I’ll wait for anyone to come maybe say something smart beforehand.