ValveSoftware / gamescope

SteamOS session compositing window manager
Other
3.07k stars 204 forks source link

Some dropped (or heavily delayed) inputs when using gamescope #791

Open EmeraldSnorlax opened 1 year ago

EmeraldSnorlax commented 1 year ago

i'm at a loss here, and i don't even know if i'm imagining it, because as soon as i try to record it happening with xev open, it magically works perfectly. i close obs and it starts happening again. (my first guess was compositor shenanigans; maybe obs blocks compositing? but i'm skeptical that is the reason, as launching the game already disables plasma's compositor)

i'm pretty confident that this is indeed happening, because i've played for several hours without gamescope, and over an hour with gamescope, and i have noticed dropped (or very heavily delayed inputs) with gamescope -- i know this because this is a rhythm game and i get misses or very late judgements when using gamescope that i'm almost certain i should not be getting (for a while, i thought i was just bad, but i would often completely miss single isolated notes, that i'm 100% sure i hit)

i end up dropping about 1/30-1/60 inputs in project diva mega mix, which makes the game essentially unplayable with gamescope (which also sucks, because it's either this or having no way to change resolution and dealing with poor performance).

has anyone else experienced similar? am i just going insane? does anyone have some way to prove this that doesn't involve obs, because that seems to prevent it from happening?

gamescope 3.11.51-1 on arch linux kernel 6.1.11-arch-1 using an amd gpu (rx 580)

game is launched with this command: XKB_DEFAULT_LAYOUT='us(workman)' WINEDLLOVERRIDES='dinput8.dll=n,b' gamescope -f -w 2560 -h 1440 -W 3820 -H 2160 -U -r 120 %command%

(i've tried changing the frame limiter, disabling upscaling, and it doesn't seem to have made a difference)

bergfried commented 1 year ago

has anyone else experienced similar?

Yes.

am i just going insane?

With respect to the issue at hand: Unlikely.

does anyone have some way to prove this that doesn't involve obs, because that seems to prevent it from happening?

I have the same issue. My case is about https://www.muppetlabs.com/~breadbox/software/tworld/ (Tile World, a FOSS clone of an old game which runs natively on Linux, so you can easily try to reproduce the issue as well). I noticed that I, strangely, perform much worse using gamescope.

To be more precise: AMD CPU, AMD graphics card, Arch Linux, gamescope 3.12.0, trying to play Tile World 1.3.2 like this:

gamescope -w 648 -h 472 -W 2592 -H 1888 -S integer -F nearest -r 20 -o 20 -- tile-world -a 1 CCLP1-Lynx.dac

20 fps should work just fine for that game. However, I noticed heavy input delays, both when pressing keys and when releasing keys. (I don't use the mouse for this game.) So I thought I merely need to tweak the command line a bit to fix it:

gamescope -w 648 -h 472 -W 2592 -H 1888 -S integer -F nearest -r 60 -o 60 --rt -- tile-world -a 1 CCLP1-Lynx.dac

Nope, no improvement. (The monitor's refresh rate is 60 Hz, and the system is tuned for realtime applications.) Running both gamescope and the game together does not result in any noticeable system load.

This is really frustrating. Given the nature of this game, timing is important, and, given the right circumstances, which occur way too often, you can readily observe that the playable character moves across several tiles despite having released the corresponding key ages ago. Or that, when you press a key, the playable character does not start to move immediately but several game ticks later. All these issues are completely gone as soon as you stop using gamescope.