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

21–30 of 202 posts

Re: Fixing stutters in Papers Please on Linux

#21

Post by edflsafoiewq »

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.

SDL has its own "dynapi" layer, where you can override it with your own copy of SDL even if it was statically linked: https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

Re: Fixing stutters in Papers Please on Linux

#22

Post by 10000truths »

masklinn wrote: post #18
yxhuvud wrote: post #10

Earlier quoted context omitted.

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…

Isn’t this the whole point of using file descriptors? As long as you have an open file descriptor, the kernel resource it references should remain stable. And if the resource is unexpectedly destroyed from under the process’s nose, the file descriptor should report an I/O error the next time you try to read or write from it.

Re: Fixing stutters in Papers Please on Linux

#23

Post by pas »

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.

Exactly. It should enumerate them when the player opens settings. Or at startup.

But even if it wants to do this, why is it doing it on the main thread!? :(

Re: Fixing stutters in Papers Please on Linux

#24

Post by dkersten »

asdfasgasdgasdg wrote: post #12
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.

SDL has an event for when a new gamepad is detected or removed: http://wiki.libsdl.org/SDL_ControllerDeviceEvent although I don’t know what it does internally in order to detect this (well, the article describes what it does).

But you can also manually enumerate devices as in the example here: http://wiki.libsdl.org/SDL_GameControllerOpen

Re: Fixing stutters in Papers Please on Linux

#25

Post by ck45 »

edflsafoiewq wrote: post #21
salicideblock wrote: post #16

Earlier quoted context omitted.

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.

SDL has its own "dynapi" layer, where you can override it with your own copy of SDL even if it was statically linked: https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

Is the version statically linked recent enough to support it? Also, can’t decide if it’s genius or insane, that extra layer of dynamic linking…

Re: Fixing stutters in Papers Please on Linux

#26

Post by lawl »

arghwhat wrote: post #9
Diggsey wrote: post #5

Earlier quoted context omitted.

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

It is appropriate to use your main thread for your OS interaction - polling fds, talking to display server, whatever I/O you need, etc. An open/close call should never take this long, and you should never need to make a large amount of them in sequence after startup. What should not be on your main thread is any long blocking compute, which is why rendering/game logic often goes to another thread - although simple ga…

> An open/close call should never take this long

> What should not be on your main thread is any long blocking compute

Isn't that contradicting yourself? I'm pretty sure open() can block.

Re: Fixing stutters in Papers Please on Linux

#27

Post by charcircuit »

ck45 wrote: post #25
edflsafoiewq wrote: post #21

Earlier quoted context omitted.

SDL has its own "dynapi" layer, where you can override it with your own copy of SDL even if it was statically linked: https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

Is the version statically linked recent enough to support it? Also, can’t decide if it’s genius or insane, that extra layer of dynamic linking…

According to [1] it was added (but not released) January 8th, 2014. Papers Please came out on Linux February 12, 2014 so I'd figure it's not in there unless the version of SDL was updated in a later update.

[1] https://old.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a...

Edit: (what I believe to be) This freezing bug was only added 3 years ago, so it might actually have it.

Re: Fixing stutters in Papers Please on Linux

#28

Post by masklinn »

10000truths wrote: post #22
masklinn wrote: post #18

Earlier quoted context omitted.

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…

Isn’t this the whole point of using file descriptors? As long as you have an open file descriptor, the kernel resource it references should remain stable. And if the resource is unexpectedly destroyed from under the process’s nose, the file descriptor should report an I/O error the next time you try to read or write from it.

> Isn’t this the whole point of using file descriptors?

Opening the same file multiple times will yield different fds, and the paths can be modified independently of the fd.

The goal here is to find if:

1. there are new input devices

2. which are joysticks (a category which, for SDL, includes gamepads, so basically "has the user plugged in a new gamepad they might want to use for the game")

How would keeping a bunch of fds around help?

Re: Fixing stutters in Papers Please on Linux

#29

Post by fleabitdev »

asdfasgasdgasdg wrote: post #12
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.

Windows uses a similar polling-based approach, with a warning that you shouldn't poll for new gamepads every frame for performance reasons:

https://docs.microsoft.com/en-us/windows/win32/xinput/gettin...

In general, "notifying the program when a new device has become available" seems to be a surprisingly difficult problem. I've encountered trouble with multiple device types across multiple platforms.

Re: Fixing stutters in Papers Please on Linux

#30

Post by the_af »

This is interesting. I never noticed these pauses using the native port from GOG on Ubuntu. I'm very sensitive to this kind of thing (low refresh rates on CRT monitors used to drive me crazy when nobody else noticed).

Will have to fire up my copy again. A good excuse to play this marvelous game again.

Post reply on HN