Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing stutters in Papers Please on Linux

blog.jhm.dev

Post reply on HN
Print view View original

11–20 of 202 posts

Re: Fixing stutters in Papers Please on Linux

#11

Post by charcircuit »

Diggsey wrote: post #5
charcircuit wrote: post #2

From the description of the problem (a freeze every 3 seconds) I knew exactly what it was. You can fix it by simply upgrading SDL as they fixed this bug 2 years ago. https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

Why is it even doing this on the main thread at all? The obvious thing would be to have a background thread polling for changes and then sending messages asynchronously to the main thread if a change actually occurred...

The simple answer is that it wasn't needed for udev. It may not have blown up on the dev's machine because their input devices were different. It might be tested less than the udev version. As the other commenter stated it's simpler to just check every 3 seconds instead of adding threading.

Re: Fixing stutters in Papers Please on Linux

#12

Post by asdfasgasdgasdg »

Narretz wrote: post #8

Why is the engine even checking input devices so often? Shouldn't the input device be registered via settings and then assumed to exist when the game runs? It seems wasteful to check all input devices every few seconds.

A lot of games will automatically switch between keyboard and gamepad when a gamepad is connected. Perhaps this is some automatic background function that SDL handles.

Re: Fixing stutters in Papers Please on Linux

#13

Post by charcircuit »

Narretz wrote: post #8

Why is the engine even checking input devices so often? Shouldn't the input device be registered via settings and then assumed to exist when the game runs? It seems wasteful to check all input devices every few seconds.

SDL wants to support hotplugging where you can plug a controller in after you have already started the game.

Re: Fixing stutters in Papers Please on Linux

#14

Post by teddyh »

iqanq wrote: post #4
charcircuit wrote: post #2

From the description of the problem (a freeze every 3 seconds) I knew exactly what it was. You can fix it by simply upgrading SDL as they fixed this bug 2 years ago. https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

This is one of the reasons I use Gentoo in my desktops: you can run a "stable" (as in old) system, but pull a more recent version of a library or application if you need it. For example, I remember having problems accessing files that I had stored in my mobile phone. Solution: updating libmtp and libmtp only. I suppose you can't do this in a distro such as Debian without upgrading half the packages. Are there more di…

If you are advanced enough to run Gentoo, you should be able to use Debian and force an install of (or re-compile yourself) a new package of the newer version, working around the fact that the official newer version would otherwise require other new packages.

Re: Fixing stutters in Papers Please on Linux

#15

Post by [deleted] »

charcircuit wrote: post #13
Narretz wrote: post #8

Why is the engine even checking input devices so often? Shouldn't the input device be registered via settings and then assumed to exist when the game runs? It seems wasteful to check all input devices every few seconds.

SDL wants to support hotplugging where you can plug a controller in after you have already started the game.

[deleted]

Re: Fixing stutters in Papers Please on Linux

#16

Post by salicideblock »

charcircuit wrote: post #2

From the description of the problem (a freeze every 3 seconds) I knew exactly what it was. You can fix it by simply upgrading SDL as they fixed this bug 2 years ago. https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

From one of the printouts in the post, it seems that Papers Please is using a bundled and statically linked SDL.

So it would be the game developer that would have to update the version of the SDL library. The binary patching done seems like a good-enough alternative in the meantime.

I have the feeling such bundling of dependencies is fairly common when porting games for Linux.

Re: Fixing stutters in Papers Please on Linux

#17

Post by charcircuit »

salicideblock wrote: post #16
charcircuit wrote: post #2

From the description of the problem (a freeze every 3 seconds) I knew exactly what it was. You can fix it by simply upgrading SDL as they fixed this bug 2 years ago. https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

From one of the printouts in the post, it seems that Papers Please is using a bundled and statically linked SDL. So it would be the game developer that would have to update the version of the SDL library. The binary patching done seems like a good-enough alternative in the meantime. I have the feeling such bundling of dependencies is fairly common when porting games for Linux.

At least for Steam you are recommended to link against Valve's Steam Linux Runtime which is a set of dynamic libraries including SDL.

Re: Fixing stutters in Papers Please on Linux

#18

Post by masklinn »

yxhuvud wrote: post #10
Narretz wrote: post #8

Why is the engine even checking input devices so often? Shouldn't the input device be registered via settings and then assumed to exist when the game runs? It seems wasteful to check all input devices every few seconds.

Yes, and even if it checks for new devices, it should only need to check devices it hasn't already checked.

Ah, but are /dev/input entries reusable?

Let's say you have /dev/input/event{0,10}, event5 is a USB keyboard, you unplug it, I assume event5 goes away.

But then you plug in a controller, does this get mapped to event11, or does event5 get reused? Is the behaviour reliable in all versions of linux?

You might argue that metadata should do the trick, but in my experience, on device files, anything beyond read/write is a crapshoot, whether metadata makes any sense is basically a roll of the dice.

So if you have to open device files in order to check their identity, you might as well skip the identity bit and just check if you're a gamepad.

edit: per charcircuit's comment below, it looks like the metadata of /dev/input at least are considered reliable, and this was used to mitigate the issue by checking the mtime of /dev/input itself against a stored timestamp: https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

Re: Fixing stutters in Papers Please on Linux

#19

Post by tankenmate »

arghwhat wrote: post #7

The issue has been identified before, but seems like it stalled: https://gitlab.freedesktop.org/libinput/libinput/-/issues/50... , https://patchwork.kernel.org/project/linux-input/patch/20201... .

I just did a quick check the posted fix is not in the most recent -rc branch in the public git repo.

Re: Fixing stutters in Papers Please on Linux

#20

Post by viraptor »

salicideblock wrote: post #16
charcircuit wrote: post #2

From the description of the problem (a freeze every 3 seconds) I knew exactly what it was. You can fix it by simply upgrading SDL as they fixed this bug 2 years ago. https://github.com/spurious/SDL-mirror/commit/59728f9802c786...

From one of the printouts in the post, it seems that Papers Please is using a bundled and statically linked SDL. So it would be the game developer that would have to update the version of the SDL library. The binary patching done seems like a good-enough alternative in the meantime. I have the feeling such bundling of dependencies is fairly common when porting games for Linux.

It's common in application of certain size and compatibility expectations. Windows and Mac games will bundle their dependencies as much as possible as well. Same for large apps. Nobody wants to end to in a situation where their relatively expensive purchase doesn't work because of the version of local libs.
Post reply on HN