chrislo27
commented
3 years ago It looks like this issue is (temporarily?) fixed in GLFW: https://github.com/glfw/glfw/commit/9a3664b4a992a5a9b669179098542b0f882dece7
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.
ZaptorZap
And here's a No-Miss on Polyrhythm 2:
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:
https://user-images.githubusercontent.com/64891705/132144381-a3b5b9d2-8d69-4864-b954-997eb6e8a1ec.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.shRelevant 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.sheliminates the issue! You could probably just add that to theplay_linux.shalthough 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.