Confirmed. Works great here too. No issues.
System Gist: https://gist.github.com/supashang/6050de4e5ed8854f58d7152521048170

Confirmed.

Distro: Linux Mint 19 Tara
Processor: AMD Ryzen 7 1700
GPU: GTX 1070, Nvidia proprietary driver 396.54
RAM: 32GB
Kernel (custom) - 4.17.14 (optimized for Ryzen)
Resolution: 1920x1080
Proton 3.7-3

I don't know if it's my setup - Arch Linux, kernel 4.18.5, Proton beta - but while the game runs perfectly, saves are lost between sessions.

It seems that they're written to [drive_c]/users/steamuser/Local\ Settings/Application\ Data/Risen/SaveGames/ but the game tries to read them from [drive_c]/users/steamuser/My\ Documents/Risen/SaveGames/. A symlink fixes the problem.

For me, Risen does not start.

Distribution: openSUSE Tumbleweed
Linux: 4.18.5
GPU: AMD Radeon R9 280
GPU driver: amdgpu 18.0.1 / Mesa 18.1.6 / LLVM 6.0.1
GPU memory: 3072MB
CPU: AMD FX 6300
RAM: 16GB
Resolution: 1920x1080
Proton: 3.7-5 Beta

Full specs: https://gist.github.com/buschmann23/f0040553d4bc4bdeb567778bd52f7946
Log file: https://gist.github.com/buschmann23/d32c2e8565302ae150bb607727c386fb

Works fine...
Proton 3.7-6
OS: Linux Mint 18 Sarah
Kernel: 4.4.0-128
Resolution: 1024x768
CPU: AMD Athlon II X2 240 @ 2.8GHz
GPU: GeForce 9500 GT
RAM: 2GB

There's a (fshack related?) regression in Proton experimental, changing resolution ends up with a too small game when decreasing and too big game when increasing the resolution. Doesn't happen on stable Proton.

@DadSchoorse I'm seeing very similar behavior on 6.3-8 as experimental-6.3-20220119. Sometimes it gets the resolution right, and sometimes its too big or too small. If you have specific resolution change steps that are continually problematic on experimental and never problematic on 6.3-8, feel free to leave more details and I can take another look :)

Okay, I did some more tests now: I changed the resolution from 1920x1080 (my display's native res) to 1600x900 and back to 1920x1080.
With experimental every single time out of 20 the game first got too big and then too small when changing back.
With 6.3-8, in 20 tries I have been able to change back and forth successfully 18x times, 2 time the game was too big at 1600x900 but was back to normal at 1920x1080.

So you are right that it's not working 100% correctly on 6.3-8, but experimental is always broken for me.

The game has to be played with Proton 5.0-10 (in my case), and both "Original game from 2009" and "None" version of the game ("Betas" tab) work the same. The game used to work flawlessly (don't remember which Proton I was using) in May/June of 2022, and there was an update this January (2023), which apparently broke something.

Shut up material (as in, I talk too much, more detail etc.):
Found out a new issue with Risen 1 (probably Risen 2 as well, but I have not tested it yet). The game never launches, it freezes before the video starts. It happens with both betas (aka, Original game from 2009 and "None"). I read here (on the PC section) that you have to disable Steam Overlay, which I did, but nothing changed. So I tried other versions of Proton (only Valve Protons, no external toying), and Experimental, 8.0-3, 7.0-6, 6.3-8 do not work, but 5.0-10 does.

I played the game flawlessly a year ago, exactly in May/June 2022, and the game worked flawlessly. I do not remember which Proton version I was using back then. Additional thing is that Risen 1 got an update this year, which might've broken a few (million) things (just like it did with Gothic to me, where the game ran well, but I got more crashes than ever, only because of THQ Nordic's patch in like 2020 or 2021).

https://gist.github.com/4164696f73/b053542782d8940e8bb3b261ae0fa51d

Gistfile1 = System Info
Gistfile2 = Diagnostics
Gistfile3 = the log from PROTON_LOG=1

Also additional info which I just noticed (by accident): I disabled the fullscreen (again, by accident) and I set it back again (with my window manager) while the videos/intros were loading, and, surprisingly, the game did launch, but the game was tiny with everything else being black. Check this screenshot. This happened on Proton Experimental just now when I was taking the Proton log. Also, it taxes the CPU when you do this (30+% CPU usage vs. barely 10% on Proton5).

And I can reproduce it: when the game is launching, it'll create a black screen and your mouse is still visible, during this time you have the opportunity to disable and enable fullscreen with your WM, and the game will launch in a tiny window, fully functional. However, without doing it, it'll hang. From what I saw in the log, it's something pid related? pid 120341 != 120340, skipping destruction (fork without exec?) <- this is the point where the game stops responding, apparently, though check the logs yourself, don't listen to me.

I checked it on Dwm (suckless' Window Manager) and AwesomeWM (logs are from Dwm), and in both cases the same issue (although, I did not toy with the fullscreen in Awesome because I have a few important windows opened that I can not close even for 10 mins currently) - game launches until the videos pop, and then decides it's time for a break.

I'd love to do that, but I don't know how to do that. I'm not that technical, still learning Linux in general. Wouldn't really want to risk anything if there's some files I have to edit, but if it's just installing something (Mesa/RADV), I'm in.

@4164696f73 I was able to confirm that you found a regression of some sort - thank you for reporting! In the meantime while we work on fixing this, feel free to use Proton 5.0 or PROTON_USE_WINED3D=1 %command% as a launch option in order to avoid the regression.

I would still suggest switching to mesa/radv as that generally has better behavior -- unfortunately, I'm not an expert on how to switch if you are using AMDVLK.

So, I searched a little, and according to Gentoo and Arch wiki, AMDVLK is enforced by default, but it can be switched with an environment variable - AMD_VULKAN_ICD=AMDVLK or AMD_VULKAN_ICD=RADV. In my case, my variable was set to RADV all the time, meaning I was, in fact, using Mesa/Radv, not AMDVLK. I decided to respond here because I thought it might be relevant in this situation, and it might also help others as well.