-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Keys pressed at the very same frame will not register correctly (likely platform specific to Linux) #24
Comments
It looks like this issue is (temporarily?) fixed in GLFW: glfw/glfw@9a3664b However, the latest stable LWJGL version is 3.2.3 released in September 2019. And LibGDX is currently using the latest stable LWJGL version. So in this chain of libraries (LibGDX depends on LWJGL, LWJGL depends on GLFW), the blocking library is LWJGL. I need to verify this issue first on a Linux machine (not a VM) and then verify that the env var you specified also works. I'm not opposed to including it in the Linux launch scripts but I will have to remember to remove it once LWJGL is updated. |
The Linux launch scripts for the next patch version will have Note that this environment variable tampers with the input method settings, so certain input methods could be affected by this workaround as a result. Refer to the aforementioned Minecraft: Java Edition bug report MC-122421 for more details. |
It looks like libGDX will be using LWJGL 3.3.0 in their next stable release (1.10.1) which has GLFW version 3.3.4 with the fix. This issue will be resolved when libGDX releases the next update and I update the game accordingly. |
libGDX has just released version 1.11.0 which contains LWJGL 3.3.1, and thus the aforementioned GLFW fix for concurrent key presses. Due to it being a major gdx version, I will tentatively do the gdx upgrade for the next feature version, but I will try to see if I can issue a patch version (v1.2.2) sooner. Thanks for your patience. |
I've been working on porting the underlying game toolkit (Paintbox) to libGDX 1.11.0. I have a temporary branch I have a special "v1.2.2" build at https://api.rhre.dev:10443/prmania_prerelease/v1.2.2-test_20220512a/07783200-c7de-4e55-855d-4d6998a46666/PolyrhythmMania_v1.2.2-test_20220512a.zip you can download. I removed the I am not confident in releasing a patch version (v1.2.2) with the new libGDX version since there's way more breaking changes than I expected, so I will have to defer it to the next feature update. Thanks for your patience once again. |
I'll certainly take a look later tonight as my interest in your project hasn't faded much over the months. I don't think anything has changed regarding my system setup, either(did have to double check Debian 11's release date since I did upgrade from Debian 10), so if the issue occurred before it'll still occur now. |
Awesome! Thank you so much for helping to test this. I will leave this issue open until the stable release with the appropriate fixes is released. |
Closed since v2.0.0 has been released with this fix. |
Version
v1.0.1-20210830a
Operating System
Linux
Problem Description
If you press and hold both A and + at the very same time, your + input will be delayed a beat. I know you're likely just thinking this is a human-proficiency issue and that I'm probably just that bad at the game, but this is not a problem isolated to this project, and the delay is consistently offset if holding both keys. If you are to let go of the key before this delay fully expires, the input will be dropped entirely and the block will never raise. Here's a video that'll definitely drive my paranoia of someone just responding "get good", but please trust me: I'm really just holding both buttons at the same time:
polyrhythm.issue.13.mp4
Regardless to say, the game's much more harder if you can't consistently use both lanes at the same time. It's visually random whether or not the input correctly works, but I believe that's down to this game running at a locked 60 frames per second. This means the game is playable with this limitation, sure, but I have to make such a concentrated effort to intentionally delay my
n(A)
+w(+)
button presses in order to play around the issue that I can both say goodbye to any no miss runs and a lot of aces.Steps to Reproduce Problem
./play_linux.sh
Relevant log output
No response
(Optional) Other useful information
It's not all doom and gloom, however! As I mentioned previously, this isn't the first project to suffer from this issue, which appears to be a problem with GLFW of all libraries. That's right, Minecraft: Java Edition on Linux has had the same problem in the past, although it's much more nuanced since you aren't expected to begin inputs so synchronously in Minecraft. Thankfully, the user who submitted issue report MC-122421 included their workaround: modifying an environment variable. This means running Polyrhythm Mania with
env XMODIFIERS="@im=null" ./play_linux.sh
eliminates the issue! You could probably just add that to theplay_linux.sh
although I'm not exactly sure what the implications of that environment variable are. I personally don't run into any issues with the game open and the variable set in KDE plasma, but that very well might not be the case in GNOME, for instance. The aforementioned Minecraft issue report mentions a, now closed, Github issue report and pull request in GLFW's repository, going on to suggest simply recompiling GLFW with the fix in place instead of forcing a variable to change the way X renders things.Now's where I make a bold claim: there's a good chance this doesn't occur on the Wayland display server protocol, since the environment variable to be changed is prepended "X". Recently more and more distributions have been using those systems instead of X.Org, so I wouldn't be surprised if this was impossible to reproduce in those distributions without specifying you'd like to use X.
The text was updated successfully, but these errors were encountered: