[Bug]: Keys pressed at the very same frame will not register correctly (likely platform specific to Linux)

[ZaptorZap]

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

1. Launch the game through ./play_linux.sh
2. Navigate to "Play->Practice Modes->Tutorial I"
3. Reach section 3, where it says "Now, lets use both hands!"
4. Attempt clearing section 3

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 the play_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.

[chrislo27]

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.

[chrislo27]

The Linux launch scripts for the next patch version will have export XMODIFIERS="@im=null" in the script. I don't consider this a proper fix because the real fix will be applied once LWJGL updates its GLFW version; rather, this is just a workaround. I will leave this issue open until then.

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.

[chrislo27]

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.

[chrislo27]

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.

[chrislo27]

I've been working on porting the underlying game toolkit (Paintbox) to libGDX 1.11.0. I have a temporary branch issue_24_v1.2 which is effectively version 1.2.1 with the new libGDX version. The problem is that it's a bit hard to build from source right now (still haven't finished the Paintbox port), but I would really appreciate if you could test that the simultaneous inputs are fixed with the new libGDX version.

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 @im=null from the Linux launch scripts as well. This build is the same as stable v1.2.1 but with libGDX 1.11.0.

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.

[ZaptorZap]

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.

[ZaptorZap]

Alright, I got a bit sidetracked last night. I went ahead and gave compilation a small crack, and I very likely just don't have the newer version. With that zip release, though, it 100% works fine now! Tutorial I is no biggie for me now:

And here's a No-Miss on Polyrhythm 2:

[chrislo27]

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.

[chrislo27]

Closed since v2.0.0 has been released with this fix.