41–50 of 202 posts
I guess that is the kind of challenge to have Windows games on GNU/Linux, fix them instead of playing.
Isn't this a native port though? I remember playing Papers Please even before it had a native port, and enjoying it with zero problems.
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.
Earlier quoted context omitted.
If I start the game without a gamepad attached to the computer, and then attach the gamepad, I'd like to use the gamepad without restarting the game. And one would expect that polling the attached input devices should never take hundreds or thousands of milliseconds, there must be something seriously wrong in the Linux input device stack or maybe in one of the input device drivers.
Or maybe just poll for new input devices when the game is paused, or before the game starts.
Quoted post unavailable.
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.
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.