Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Flattr, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by rkfg
Upcoming 'post-cyberpunk' RTS NeuroSlicers looks great, Steam page up
11 August 2020 at 6:04 am UTC Likes: 1

You can play it for free until Aug 13 by joining their playtest at https://gameround.co/detail/7/info/EN, register and press "Get a game key" and it provides a Steam key to activate. Since it already has a Linux config (to address @Linuxer's concerns) it needs a "Force the use of a specific compatibility tool" override or else it downloads 0 bytes.

The game is Windows-only but works fine on Proton 5.9 GE, on the stock Proton the video cutscenes don't play (they can be skipped by holding a mouse button). It's an interesting take on RTS with focus on macro and even different "races" with their unique traits, abilities and playstyle, just like in my first RTS Starcraft. I like the cyberpunk style and music, plan to buy it on launch/EA if they push the Linux build.

Destroy, consume, spread and stop at nothing - CARRION is out now
25 July 2020 at 1:26 pm UTC

lol yeah, bad idea but I really needed this utility to work. I actually used his next version of the same program written in Rust but it also didn't work without this library present somewhere.

About the game itself: I played for several hours and it's really good! Not challenging at all but rewarding. I only got lost a couple of times, even though it feels like metroidvania (you need to go back sometimes after you get the abilities you need to progress), it's still linear. If you don't know how to get somewhere or solve a puzzle (there are no puzzles, only lacking abilities) just put that part aside and you're guaranteed to return to it later. The most common complaint is that the game is short. For me 5-6 hours is quite good because I can finish the game on the weekend and don't get bored. And considering the polished and satisfying experience the price is justified, too.

Destroy, consume, spread and stop at nothing - CARRION is out now
25 July 2020 at 10:11 am UTC Likes: 1

I did it to use this utility, it even says in the README that libsteam_api.so must be available somewhere. Now after fixing my issue I just patched laspad itself with patchelf --set-rpath '$ORIGIN' and put libsteam_api.so to its directory. In general, when something weird happens the low level tools help most, that is tcpdump and strace. I often don't even waste time with guesses and googling as soon as I see something mildly unusual, just run those bad boys and they instantly tell me what's wrong.

Destroy, consume, spread and stop at nothing - CARRION is out now
24 July 2020 at 10:31 pm UTC

Quoting: dpanter
Quoting: rkfgDebian
Debian sid here, runs out of the box.
Here's the report, I read a bit about RPATH/RUNPATH but currently have no idea why only the former works. I had something in my LD_LIBRARY_PATH related to CUDA but after unsetting it the problem still persists. Pretty weird but I remember having such issues with my own programs I compiled with Meson, I had to patch the binaries later to set RPATH for them to work (but I might be mistaken, it was long ago).

Ok, found the issue, my bad. Described it in the aforementioned report.

Destroy, consume, spread and stop at nothing - CARRION is out now
24 July 2020 at 8:00 pm UTC

The Steam version doesn't launch for me, looks like it can't find the libraries in the same directory. I found a workaround which is to patch the binary. Install patchelf from the repository, then do:
 
patchelf --force-rpath --set-rpath '$ORIGIN' Carrion

I don't know the details but it seems that RUNPATH is the modern header field used to search the libraries and RPATH is the legacy one. For some reason on Debian (at least) this RUNPATH, which is correctly set to $ORIGIN in the game binary, is either ignored or not used properly but RPATH works as intended. $ORIGIN means the directory where the binary is located. Usually, developers make a shell script that sets up LD_LIBRARY_PATH to find the libs but RPATH can also be used. It has its issues with transitive library loading (if some other library needs to load its dependency it might fail if you don't patch it the same way) but overall it's a good alternative. I reported this bug, hope the devs fix it soon.

What have you been playing recently?
21 June 2020 at 3:31 pm UTC Likes: 2

Finished Detroit: Become Human and started a second playthrough. It works pretty good on NVIDIA, has some stutters in open areas (not related to shader compilation because it uses Vulkan natively, must be something else in Wine) but otherwise okay. Great interactive story with fantastic visuals and interesting characters!

Steam Beta adds Vulkan shader processing
2 June 2020 at 12:01 pm UTC

Quoting: AwesamLinuxIf anyone has previously played the game with the same GPU and driver version.
I think it's not entirely correct, for Vulkan the GPU and driver version doesn't matter in this case. Steam can grab the platform-independent Vulkan pipelines and serialize them to upload and distribute later, they're the same for any GPU. But to use them, as @DadSchoorse explained earlier, you need to compile them to the native GPU code and it can only be done on the end user machine. This latter option is what has been added in this update and the capture layer existed for a while.

Steam Beta adds Vulkan shader processing
26 May 2020 at 6:19 pm UTC Likes: 1

Quoting: stan
Quoting: rkfgIf you prefer stutter and freezes every time something new appears on screen then yeah. But I don't think it's worth it. If you play games with a lot of shaders (= AAA games) you'd better invest into a bigger and faster SSD because the rest of your hardware should already be quite good. Honestly, bad first time experience isn't worth the saved disk space.
No, I don’t have that problem. And I have 5TB of SSD for games.
It depends on the game and mostly applies to non-native ones. If you don't play them probably you're fine. But some games stutter much more than the others and if you have plenty of space why not download those caches? Also you will help other players by uploading your cache back. It's like torrents but 100% legal!

Steam Beta adds Vulkan shader processing
26 May 2020 at 5:24 pm UTC

Quoting: stanWhen they first introduced this shader caching/sharing thing Steam started to download hundreds of megabytes of shaders… not a very slight increase in disk and bandwidth usage, no. So I disabled it right away…
If you prefer stutter and freezes every time something new appears on screen then yeah. But I don't think it's worth it. If you play games with a lot of shaders (= AAA games) you'd better invest into a bigger and faster SSD because the rest of your hardware should already be quite good. Honestly, bad first time experience isn't worth the saved disk space.

Steam Beta adds Vulkan shader processing
26 May 2020 at 11:36 am UTC

Quoting: DadSchoorse
Quoting: rkfgFortunately, this format is standardized at the spec level so you can use the same shader cache on any GPU, be it AMD, NVIDIA or Intel and you won't need to rebuild it each time you update the driver (remember that pain with OpenGL?). It's not a problem for correctly ported games as the port developer (like Feral) can create a native SPIR-V cache ahead of time so the game just loads the shader it needs directly. That's why Shadow of the Tomb Raider runs so smooth natively and stutters like hell on DXVK.
You are misunderstanding what SPIR-V is. It's not something that the gpu can execute, it still needs to be combined with more pipeline state information and then optimized and compiled to the specific gpu's machine code. This is very expensive to do and causes the stuttering with DXVK. And that's where fossilize comes into play. It collects all pipeline state and all shaders to create the pipelines (basically gpu programs) and then Steam distributes them so that you can compile them for your specific driver and gpu outside of the game. That way the driver can cache the pipelines and doesn't need to compile them from scratch while you're playing.
As for why Feral ports don't stutter like DXVK, D3D11 doesn't give enough information on how a shader will be used before actually using it, that's why DXVK can only compile the pipeline when the game draws something with it. Feral know how shaders will be used since they have access to the game, so that's a big advantage.
Thanks, that's new to me! I thought SPIR-V is executed directly by the underlying driver since it's in the standard. But yeah, the very low hardware level is still different for every GPU so indeed some sort of translation happens under the hood. I didn't know the bottleneck is in the final compilation for the GPU. Good explanation, I was wondering why we need more preprocessing with this new feature if Steam already provides the cache. Now it's more clear.

Also, in the Fossilize README there's this:
QuoteThe goal for this project is to cover some main use cases:
<...>
Serialize state in application once, replay on N devices to build up VkPipelineCache objects without having to run application.
I think this is exactly what happens because when Steam is doing this new task there's a fossilize_replay process mentioned in nvidia-smi output. Would be really interesting to see how smooth it all is now out of the box, will try with a good-looking F2P game later.