Compatibility Report

System Information

• GPU: rx 5700 XT
• Driver/LLVM version: Mesa 19.3.1 (LLVM 9.0.0)
• Kernel version: 5.4
• Link to full system information report as Gist: link
• Proton version: 4.11-11
• headset: Valve Index

Same as OP. Large areas are performing quite poorly, smaller areas are pretty much fine. From what I've heard the game itself is or at least was poorly optimized on Windows, too, so this might be resolved in the future.

So I re-tested with Proton 5.0-1. While there has been a very minor improvement, it is far from fixed. I've been using the original Vive, if that makes a difference.

The performance issues people are getting on Windows seem to be for a specific level. Those having the issue can play earlier levels (like streets) just fine, which I, and I presume @Zamundaaa, cannot.

I've also seen nothing substantial relating to running Boneworks with proton in the past month, but I have no idea where to start fixing the issue. If anyone has any pointers that would be really helpful (especially considering this and HL:A are the only VR games I want to play right now).

I tested some stuff out with the GPU profiler while running the game. In the main menu, none of the graphics options changed the GPU usage. High shadows, 8x MSAA, and ambient occlusion would see ~50-60% usage, and all being minimum getting the same results. There was one exception, though. Adaptive resolution would lower GPU usage in the main menu to ~25%, but it would always be the lowest possible resolution.

When in streets, all the settings did have an effect on performance. Adaptive resolution would on rare occasions actually slightly increase in resolution. In practice, it just means that if you face the corner of a room away from the rest of the level you can see a big wall texture in glorious 480p 60fps. Still unplayably bad on anything but absolute minimum graphics.

The texture resolution setting in the most recent update has made the game playable enough to play if you happen to have it in your library already, with one huge exception. I've played through to the "Central Station" level and enjoyed it with a lead stomach. Problem is, if I walk into the main area of the station (interestingly enough the very room of the Bonetones cover art), the game freezes and then eventually crashes. I don't think I can continue without either a hacked save or an update to proton/boneworks.

I was going to, but I'm currently away from my computer. I should have a crash report during the weekend though.

Github requires that files be smaller than 10MB. Problem is, the Proton log file is 41.6MB. I compressed it into a zip, so sorry if that is an inconvenience.

Perhaps the excessive logging might be part of the performance issues? I wouldn't know, Proton still seems like magic to me.

steam-823500.zip

Using the legacy reprojection makes a huge improvement in performance. Still not solved, but much better. There are clusters of magenta spikes where there used to be blobs of magenta in the performance graph, and other places are consistently within what SteamVR considers good (< 11.0 ms)

To change, go to: SteamVR Settings -> Applications -> BONEWORKS (in dropdown) -> Reprojection -> [X] Use legacy reprojection mode

The Central Station crash is still present though, so it is still not completable.

Adding PROTON_FORCE_LARGE_ADDRESS_AWARE seems to have fixed the Central Station crash. I had dismissed it as being useful because it seemed to not help with crashes a month or two ago (before texture resolution could be lowered and I didn't know about legacy reprojection). Now I'm smacking myself over it.

I'm not going to close this issue though until I know I can complete the game and confirm no one gets any framerate/crashing issues whatsoever.

Using Proton 5, legacy reprojection, disable smooth motion and defining steam vr scale at 50% and PROTON_FORCE_LARGE_ADDRESS_AWARE let me launch the game and set the texture resolution to quarter (I not saw the possibly to set it smaller).

Before that I had crash, now it's like long freeze that goes away if I wait, but looking at the configuration needed let me think my desktop is more in fault that Proton.

https://gist.github.com/kadogo/0fd6e89773a341d35651d32bcc39ec66

Edit:
Checking the minimal configuration again, I'm not so far and I'm using the first Vive too.

Edit2:
Not directly related, but I did a test on my Windows VM where I can only assign 6Go memory because I stil have linux working. The game is very slow in the loading screen, but the computer not crash, I can still use Windows while the game is loading. Maybe the crash are related to Proton or Steam VR for linux?

SteamVR crashes with -203 error

Ha! I found an optimal workaround, for my setup at least, on Proton 5.13 + SteamVR 1.14 under Artix Linux, using Valve Index.

Note that this unexplainable lag workaround needs a very powerful build (tested with AMD Ryzen 7 5700X and AMD Radeon RX 6600 XT) to avoid the stuttery reprojection.

Under SteamVR video settings, set Custom Resolution Multiplier to the lowest possible value before any level transition (or reload the level this way via the Scenes menu or main menu).

Use Legacy Reprojection Mode must be set to On before launching the game.

Launch the game with PROTON_FORCE_LARGE_ADDRESS_AWARE=1 %command% as per the crash workaround mentioned before. Feral GameMode (prepend %command% with gamemode) can help churn out as many frames as possible.

I believe that the reprojection mode workaround doesn't apply to newer SteamVR versions, and that the large address aware fix is unnecessary for newer Proton versions, but the resolution switch should help with the lag in all versions.

Edit: Well, that was embarrassing. The lag I was having was caused by setting texture quality too high, causing my VRAM to get eaten up. Nevertheless, SteamVR 1.14 + Proton 5.13 are still 100% necessary for asynchronous reprojection, in order to avoid the lag fest of dropped frames, considering that reprojection has been broken on all newer versions.

Hey, I'd like to report an issue I'm having with this game. I don't know if it's an issue with Proton or the Nvidia drivers, so I'm posting this bug report both in the Nvidia forum and in here.

I'll copypaste what I wrote in the Nvidia forum:

My system:
EndeavourOS up to date as of today
RTX 4070Ti Super
Driver version 565.77 (nvidia package). GSP off.
AMD 5800X
32 GB RAM
KDE Wayland
Meta quest 3 (streaming the game via WiVRn)
Proton 9.0-4

When playing Boneworks, there’s a persistent white screen after the initial setup, when you spawn in the hub:

This white screen is permanently stuck in the same place relative to your real-world body position and rotation. Meaning that you can’t look away from it or get away from it by rotating or moving your character in the game, the only way to look away from it is to turn around in real life and the only way to get away from it is to walk away in real life. The square renders on top of everything and will cover whatever you’re trying to look at, no matter the distance.

This white square is NOT present in the 2D view of the game on the monitor. It is only present in the headset.

I currently have no means to test this game on any other hardware so I can’t confirm if it’s something exclusive to some GPUs.

Meta quest 3 (streaming the game via WiVRn)
This is not related to Proton.

It seems, you are using OpenComposite version, which does not supports
overlays opacity.

There was workaround in OpenComposite, that removed overlays which
opacity is near zero. If it does not work, try older versions (half a
year ago) which works fine
Best way to completely fix this is implementing alpha multiplication in
compositor for overlays, but it will require creating vulkan pipeline
for this instead of just copying images

Replying to https://github.com/ValveSoftware/Proton/issues/3389#issuecomment-2611070052

I see. Thanks. Sorry for the offtopic, but is this workaround something I need to enable in the config? can you send me some more info on this? Thanks.

https://gitlab.com/znixian/OpenOVR/-/blob/openxr/OpenOVR/Reimpl/BaseOverlay.cpp?ref_type=heads#L124

Uncomment this line, it's workaround for boneworks overlays

But opacity needs to be implemented on compositor's side correctly