DJMAX RESPECT V
@kisak-valve Pinging in case the log helps with more label classification; I've found the Flatpak directory path and uploaded the relevant log file.
So the game worked for a while, but using Proton Experimental my videos are now all messed up.
The game also freezes forever when quitting.
@Hezkore Thank you for the report! You can use WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 %command% in the "launch options" to fix the videos. This override will be included in the next experimental update, but in the meantime this is an easy fix :)
add one more problem that happen recently
After the update of new DLC the game performance has a sharp decline.
(before new DLC : 120-140fps -> after new DLC : 24-31fps)
According to my very small analysis, the game or wine or proton doesn't use CPU multy-Thread.
Before the problem happen my cpu usage is over 70~80 but now there is always stop in maximum 25% (never go up in-game)
I ADD my log file... please help me..
steam-960170.log
add one more problem that happen recently After the update of new DLC the game performance has a sharp decline. (before new DLC : 120-140fps -> after new DLC : 24-31fps)
According to my very small analysis, the game or wine or proton doesn't use CPU multy-Thread. Before the problem happen my cpu usage is over 70~80 but now there is always stop in maximum 25% (never go up in-game)
I ADD my log file... please help me.. steam-960170.log
Same here
Here are some discussions on Steam about the issue:
https://steamcommunity.com/app/960170/discussions/0/3457093950219390561/
https://steamcommunity.com/app/960170/discussions/0/3450339185467463219/
https://steamcommunity.com/app/960170/discussions/0/3457093950213141612/
Same problem as @m4a1carbin4. On a 1060 the performance is 30-40 fps and neither attempting to swap dxvk with wined3d or lowering pulse latency or using gamemode made any difference. The game is artificially heavy. I assume it's due to this XIGNCODE3 cr*p.
Any updates on this topic? I have both a steam deck and a linux desktop pc. The game runs flawlessly on steam deck however on desktop linux (arch gnome) The game plays at around like 20fps leaving it practically unplayable.
Any updates on this topic? I have both a steam deck and a linux desktop pc. The game runs flawlessly on steam deck however on desktop linux (arch gnome) The game plays at around like 20fps leaving it practically unplayable.
Sadly it's still broken, @PolarisPyra. I switched to a 6700 XT and I can't get more than 40 FPS on 1080p running Arch. It's pathetic. I had to make a Windows KVM to make it work fully, and in there I get solid 60 FPS.
It would be great if we could get whatever was made on the Steam Deck to get the game working properly again on PCs with far better CPUs and CPUs, @kisak-valve
Any updates on this topic? I have both a steam deck and a linux desktop pc. The game runs flawlessly on steam deck however on desktop linux (arch gnome) The game plays at around like 20fps leaving it practically unplayable.
Sadly it's still broken, @PolarisPyra. I switched to a 6700 XT and I can't get more than 40 FPS on 1080p running Arch. It's pathetic. I had to make a Windows KVM to make it work fully, and in there I get solid 60 FPS.
It would be great if we could get whatever was made on the Steam Deck to get the game working properly again on PCs with far better CPUs and CPUs, @kisak-valve
Well that stinks. I hope we can also get what ever magical sauce the steam deck got on desktop lol. If you want another log @kisak-valve let me know and I can provide one.
@webodan you're not going to believe this! I got it capped at 60fps and its playable (minus the videos ofc) I am using proton 7.0.5 with gamescope and gamemode. The command args are gamemoderun gamescope -Y -i -n -f -b -W 1920 -H 1080 -w 2560 -h 1440 -r 240 -e --rt -- %command% Even if i set 120 or 240 for refresh rate (in game caps at 240 iirc) i cant get it to go past 60. It feels a little strange to play but i think thats cuz of the 60 cap. Maybe someone else can take it from here. I would upload a log but i'm not sure how to log proton game launches with gamescope and stuff lol
@PolarisPyra Honestly bro, I tried as much as I could with gamemode and gamescope but i never could get the same buttery smooth framerate as in Windows. Close to 60 but not good enough for a rhythm game. This needs code fixes.
Try out PROTON_LOG=1 in the command line of Steam to log proton stuff btw
Yeah.. I figured as much q_q. Well anyways if anyone wants to take a look here are my outputted logs with those args attached.
DJMAX RESPECT V_d3d11.log
DJMAX RESPECT V_dxgi.log
ZFGameBrowser_d3d9.log
ZFGameBrowser_d3d11.log
ZFGameBrowser_dxgi.log
Specs: Nvidia 1080ti, Intel i7-7800x, 32gb DDR4 memory.
DE: Arch 6.1.6, GNOME 43, X11
So i've been doing some more deep diving. Looks Like When VSing the deck the deck has less device info compared to normal linux? Meaning they made some manual changes to get it to run better I assume...
Already reported on ProtonDB, but this game hangs on startup if started with Proton 8.0 or Experimental. Might worth investigating.
Hello @ishitatsuyuki, please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.
If this is a regression for you, please also note the most recent Proton version you know isn't affected.
System Information: https://gist.github.com/ishitatsuyuki/28497a398700078036cbff6c83495dc2
Logs on 7.0 (working):
steam-960170-7.0.zip
Logs on 8.0 (broken):
steam-960170-8.0.zip
While on this, the frame drops seems to be due to the game repeatedly calling QueryDisplayConfig, NtUserGetDisplayConfigBufferSizes and MonitorFromRect in main thread. In Wine this does multiple server calls mostly consisting of registry access, amounting to 80% of total execution time in main thread (likely more if you included time waiting on server replies).
Fixing this, by adding caching of data or other means, will likely fix the frame drop issue.
FWIW looking at the faulting address the crash seems to be occurring within xigncode3, not sure what and how it regressed though.
The crash on Proton 8 seems to be due to the DRM relying on RaiseException() to preserve registers. I'll work on a fix later, but this also means that the crash is dependent on the compiler you use to compile Proton, and independent of Proton version itself (same bug actually exists in Proton 7, technically speaking).
Paul Gofman pushed a fix for the DRM crash in Proton experimental, so it launches now.
As for the screen polling issue, Unity symbols allowed me to determine where it's called from... it seems to be Screen.currentResolution (getter). I'm not exactly sure, but I think it's an oversight on Unity side that this function does not cache results and always call the APIs listed above.
I'll download Unity and try to make a minimal repro when I have time.
Thanks a lot for your work here :D
I think you will test about it soon anyway, but I wanted to know how it differs, so I just did a simple test with 3D Sample Scene which you can find in Unity Hub samples as I know little to nothing about Unity (and even C#), so this can be very inaccurate...
Here are things I did:
- Same Unity version with DJMAX (2021.3.26f)
- add
static Resolution res;in global scope and addres = Screen.currentResolution;inUpdate() - build another one without currentResolution, assign a simple string to a variable instead of
currentResolutioninUpdate() - Environment: openSUSE Tumbleweed, RX570, wine 8.9 with DXVK
- Command:
DXVK_HUD=fps vblank_mode=0 wine ./sample.exe
Results are as follows:
| FPS | Near to objects | Far from objects |
|---|---|---|
currentResolution |
310~320 | 495~500 |
string |
315~320 | 610~615 |
Using currentResolution does have some overhead on WINE from what I see, but I am not really sure if this is a reason for low FPS since DJMAX is running at only 45~60FPS with low CPU/GPU utilization for me unless they are calling Screen.currentResolution for every calculation without caching it (I hope this isn't a case), also, on Windows, different PC but I couldn't see any performance hit with currentResolution.
Please let me know if you find anything else, I'd be more than glad to help you because I can finally blow up Windows in my PC if DJMAX runs well on Proton..
FWIW, I've already have a fix at https://gitlab.winehq.org/wine/wine/-/merge_requests/2957 and tested with this game. With that I can sustain 360fps with no issues.
Thanks a lot! I will try building Proton with it right away lol
EDIT: It works really well, thanks again for the patch :D
FWIW, I've already have a fix at https://gitlab.winehq.org/wine/wine/-/merge_requests/2957 and tested with this game. With that I can sustain 360fps with no issues.
I can confirm that it works as well. Looks like the merge was blocked. Hopefully someone can get it fixed.
There's nothing "blocking" right now, it just need some time to get a review. In the meanwhile, feel free to apply the MR on top of your own builds.
Thanks a lot! I will try building Proton with it right away lol EDIT: It works really well, thanks again for the patch :D
Sorry to ask, how do you build it with a patch?
You can use the repo you are currently on, proton-ge-custom, or wine-tkg-git. (Read README for instructions)
Or use my build if you don't care about downloading random binaries on internet
You can use the repo you are currently on, proton-ge-custom, or wine-tkg-git. (Read README for instructions) Or use my build if you don't care about downloading random binaries on internet
Thanks!
@ivyl https://gitlab.winehq.org/wine/wine/-/merge_requests/2957 could use a cherry pick (now that it's merged upstream) which should improve the game's performance on Proton.
@ivyl https://gitlab.winehq.org/wine/wine/-/merge_requests/2957 could use a cherry pick (now that it's merged upstream) which should improve the game's performance on Proton.
Done. It's now in bleeding-edge. Thanks!
Is this game still working for you all? I've just reinstalled my linux (openSUSE), and I am sure that it's pretty much the same with my previous install. I tried my build, Experimental, 8.0, and they all had same symptom.
Other games work fine, but this game crashes shortly after the caution splash, and if I put PROTON_LOG=1, my system becomes basically unresponsive, and log size is around ~2GB.
7.0 was not an exception, but at least it died gracefully with Unity crash. I'll try it on other distros when I have time, but I just wanted to know if anyone else is like me.
Works fine for me on experimental-bleeding-edge-8.0-48835-20230704-p972f98-wfd34e4-d026aa4-vc1d24a. Note that the performance optimization commit is temporarily reverted in BE as it caused some compatibility issues with other apps using CEF.
Thanks for the fast response! I guess something's wrong with my setup then...
Found a workaround, launching steam with steam -vgui (Old Steam UI) seems to fix it for now. I guess it's because of new Steam overlay (even though I've already had it disabled even in the new UI)
https://github.com/ValveSoftware/steam-for-linux/issues/9586#issuecomment-1601994223
Any well known public versions known to have the fix included? So far I tested various GE-Proton-8-xx versions but nothing worked. Seems the patch is between https://github.com/ValveSoftware/wine/commit/a76fadbf6e9f7d35fa7b6d8e930181903890f959 and https://github.com/ValveSoftware/wine/commit/62f3d9e01a565c80b2478d4778b93c0e472890a3 but couldn't find any public builds using a version between them...
Not as far as I know. The original commit caused a rather major regression and needed to be reverted quickly after it was initially cherry-picked. This regression has been fixed upstream, but we looked into porting over all the changes and the work is non-trivial and has been deemed too risky. It will all get pulled in automatically during the next rebase since it is upstreamed.
Thanks for the context. Then I'll go with personal build by cherry-picking commits, only for this game.
Just for reference for others brave enough to ignore that regression issue: personal build from https://github.com/ValveSoftware/Proton/issues/5520#issuecomment-1578989932 seems to work for fps issue, but it had a video issue which I didn't know how to fix.
Or you can create your own build by cherry-picking commits authored by @ishitatsuyuki , on top of public builds. For me the best outcome was from GE-Proton, using the following command:
git clone --recursive https://github.com/GloriousEggroll/proton-ge-custom.git
cd proton-ge-custom
cd wine
git cherry-pick 88e9ac756ec6a86674a9f7311ac2a2c6e6e80c7c
git cherry-pick a76fadbf6e9f7d35fa7b6d8e930181903890f959
(note: it will break one custom patch included in the GE-Proton, which I just ignored)
I don't know how to show fps in the game, but I can feel it(... trust me. I have a 240hz monitor)
Sorry for the bump but I just wanted to confirm that by doing the custom proton ge, with the cherry picked patches that @blmarket brought up worked flawlessly! The game is actually playable
I tried to use the build listed before and yeah video didn't work... I also saw that it was added to bleeding edge so I tried that with proton experimental and I still had the FPS drop problem just as a FYI. :D I am very happy now. Thank you all so much :D
Game crashes shortly after it gets into the main menu. This has been happening to many games recently I'm not sure what's the cause for it.
Game crashes shortly after it gets into the main menu. This has been happening to many games recently I'm not sure what's the cause for it.
I'm having the same issue. The custom build mentioned earlier fixes the FPS issues but the game will randomly quit while you're playing a song or sometimes even in the main menu.
Are you using SteamOS Beta by any chance?
Edit: I reverted SteamOS back to the stable channel (3.4) and the crashes seem to be gone now.
I was originally going to post here reporting the same crashing issue, but of course now when I try to test the game I can't seem to get the crashing to reproduce anymore... However, there's still a massive performance issue so here's my own report and logs for the issue still occurring even on stable SteamOS 3.5.5 and current Proton Experimental. I'll also add anecdotally that this issue is even occurring on my main desktop PC running Fedora 39, but I don't have the logs to go with that like I do on Deck.
System Information
- GPU: Steam Deck
- Video driver version: Mesa 23.1.3 (git-58f7632462)
- Kernel version: 6.1.52-valve7-1-neptune-61
- Link to full system information report as Gist: https://gist.github.com/CptCookies12/fe445993480e80672f3e1fa4fb53ed1c
- Proton version: Experimental (1699978268 experimental-8.0-20231114c)
Symptoms
Performance is inconsistently low, rarely if ever reaches a target 60 FPS. High power consumption (about 16W or so on average) goes along with this despite the performance overlay reporting low CPU and GPU usage. Performance is slightly better when trying to use Proton 7.0 with gameplay hovering around 55 to 60 FPS but it's still inconsistent and randomly drops; there's possibly some kind of regression with 8.0/Experimental but the inconsistency still remains regardless of version used.
Here's Proton logs running the game both with Experimental and 7.0, loading through the intros, entering Free Play, playing a song, then exiting the game. The logs are zipped because they're over the 25MB size limit.
Proton Experimental:
steam-960170-protonexperimental.zip
Proton 7.0:
steam-960170-proton7.zip
Reproduction
Launch the game and skip past the intros, the framerate will begin randomly dropping at the main menu and anywhere else in-game that's not just a video playing.
The performance issue is diagnosed above. Unfortunately the QueryDisplayConfig optimization is reverted in Proton due to compatibility issues and you'll need to manually re-apply the patch for the near future.
The developer mentioned that they fixed performance issues on the Steam Deck in the V EXTENSION 5 patch. The QueryDisplayConfig calls are indeed gone. Now you should be able to play comfortably on Proton stable or experimental.
Kudos to the devs.
Do note one caveat that if you enable VSync the issue will be back and QueryDisplayConfig is called every frame. Just make sure your limiter settings is not on VSync and it should be fine.
error: decodebinX: Your GStreamer installation is missing a plug-in
Issue transferred from https://github.com/ValveSoftware/Proton/issues/7445.
@rafaelhipercg posted on 2024-01-26T21:36:42:
Videos play on my desktop but not on my notebook. The Proton log on my notebook indicates a missing GStreamer plugin, despite having all the necessary plugins (good, ugly, bad, base, etc.) installed.
Both devices run clean installations of Pop_OS! 22.04 LTS with installed GStreamer plugins. The sole difference is that I copied the .steam folder from another Pop_OS! installation to my desktop.
I've tested this across various Proton versions, including Proton Experimental, 8, and 7. All versions exhibit the same problem, videos failing to execute properly, even though they play flawlessly on my desktop.
I'm looking to resolve this issue, whether it's on my end or within Proton. I'm not inclined to install Windows solely for playing this game.
proton log:
winegstreamer error: decodebin2: Your GStreamer installation is missing a plug-in.
winegstreamer error: decodebin2: ../src-gst_base/gst/playback/gstdecodebin2.c(4704): gst_decode_bin_expose (): /GstBin:bin2/GstDecodeBin:decodebin2:
no suitable plugins found:
Couldn't set avdec_h264-1 to PAUSED
Couldn't set avdec_valve_h264-1 to PAUSED
$ apt list | grep instalado | grep gstreamer
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
gir1.2-gstreamer-1.0/jammy-updates,now 1.20.3-0ubuntu1 amd64 [instalado,automático]
gstreamer1.0-alsa/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado,automático]
gstreamer1.0-clutter-3.0/jammy-updates,now 3.0.27-2ubuntu1 amd64 [instalado,automático]
gstreamer1.0-gl/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado,automático]
gstreamer1.0-libav/jammy-updates,now 1.20.3-0ubuntu1 amd64 [instalado]
gstreamer1.0-pipewire/jammy,now 1.0.0~1701092078~22.04~594e8f5 amd64 [instalado,automático]
gstreamer1.0-plugins-bad/jammy-security,jammy-updates,now 1.20.3-0ubuntu1.1 amd64 [instalado]
gstreamer1.0-plugins-base-apps/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado,automático]
gstreamer1.0-plugins-base/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado]
gstreamer1.0-plugins-good/jammy-security,jammy-updates,now 1.20.3-0ubuntu1.1 amd64 [instalado]
gstreamer1.0-plugins-ugly/jammy,now 1.20.1-1 amd64 [instalado]
gstreamer1.0-pulseaudio/jammy-security,jammy-updates,now 1.20.3-0ubuntu1.1 amd64 [instalado,automático]
gstreamer1.0-tools/jammy-updates,now 1.20.3-0ubuntu1 amd64 [instalado,automático]
gstreamer1.0-vaapi/jammy-updates,now 1.20.1-1ubuntu1 amd64 [instalado]
gstreamer1.0-x/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado,automático]
libgstreamer-gl1.0-0/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado,automático]
libgstreamer-plugins-bad1.0-0/jammy-security,jammy-updates,now 1.20.3-0ubuntu1.1 amd64 [instalado,automático]
libgstreamer-plugins-base1.0-0/jammy-security,jammy-updates,now 1.20.1-1ubuntu0.1 amd64 [instalado,automático]
libgstreamer-plugins-good1.0-0/jammy-security,jammy-updates,now 1.20.3-0ubuntu1.1 amd64 [instalado,automático]
libgstreamer1.0-0/jammy-updates,now 1.20.3-0ubuntu1 amd64 [instalado,automático]
Notebook:
Desktop:
@kisak-valve commented on 2024-01-26T21:55:55:
Hello @rafaelhipercg, what game are you showing in your screenshot?
The codecs installed on your host system are not used with Proton. Instead, the Steam client provides access to the h264 codec, but the game config needs to tell the Steam client that it's needed. There's a manual process mentioned at https://github.com/ValveSoftware/Proton/issues/5196#issuecomment-1502075962.
@rafaelhipercg commented on 2024-01-26T21:57:35:
Hello @rafaelhipercg, what game are you showing in your screenshot?
The codecs installed on your host system are not used with Proton. Instead, the Steam client provides access to the h264 codec, but the game config needs to tell the Steam client that it's needed. There's a manual process mentioned at [#5196 (comment)](https://github.com/ValveSoftware/Proton/issues/5196#issuecomment-1502075962).
DJMAX RESPECT V 960170
Just FYI the Proton 9.0-beta branch and Proton Experimental (now shipping 9.0) includes the QueryDisplayConfig performance fix, and VSync will no longer cause frame drops.
Bleeding edge broke somewhere between yesterday and today. The game is stuck upon launch, "loading" at 75%. @rbernon said they might take a look after vacation.
BE seems fixed again after Friday's revert.
I've recently started getting large amounts of stutter during gameplay. It was fine until now with the liberty v2 update.
AMD 7700X
NVIDA GTX 4070
Performance seems fine on my end. A few things worth clarifying:
- How often is the stutter?
- How long is each stutter? ~x0ms? x00ms?
- Proton version
- Compositor used
- Game graphics settings, especially the frame limit
Can you also attach log with PROTON_LOG=1 (instructions)?
Stutter only seems to be during charts (i get two or 3 VERY noticeable stutters when playing songs)
I'd say they're about 1-3s
GE-PROTON9=21 and Proton Experimental bleeding edge
I have tried borderless windowed, full screen, 120hz, and unlimited fps
I am using wayland ( i was also using wayland when it was working)
steam-960170.log
i don't think I'm seeing seconds of stutter in my environment. I'm on Proton BE, borderless, VSync and 400FPS limit tried. I'm on Radeon 5700 XT though, so GPU vendor might be a cause.
I don't see any suspicious lines in the log. Could you try setting PROTON_DISABLE_NVAPI=1 just in case?
steam-960170.log
unfortunately that did not seem to help. I have attached the logs.
I've recently started getting large amounts of stutter during gameplay. It was fine until now with the liberty v2 update.
AMD 7700X NVIDA GTX 4070
This has also been affecting me, the game didn't use to have these stutters until that specific update was introduced.
I'm on ProtonGE-10 and my setup also has an NVIDIA GPU (RTX 2060)
has anyone noticed some regression being back? it's been fine for months (since early 2025) but after the arcaea dlc I've noticed sometimes it freezes at the free style menu and only a restart seems to fix it. I also noticed some odd frame pacing and some coil whine coming from my GPU at random times when I play a chart... it's random tho and I can't reproduce it each play. it does seem to go away with experimental (I think. I need more plays tho). I am away from my PC at the moment but I can upload logs later today I'm just curious if anyone else has experienced any of these newly discovered issues. I will say the freestyle freeze seems to happen less if not at all on experimental. I will try 9.0.4 later and like to mention i noticed the freeze on proton ge10-15 Please let me know if you want anything from me and I'll produce some logs later this evening
Arch Linux
AMD 7700X
NVIDA 4070
latest Nvidia drivers
Wayland
I played the game for ~30min on Proton Experimental on AMD 5700 XT and it has been running without issues.
There has been past reports of issues and based on just the reports there's a fair chance it is Nvidia specific.
As for coil whine, if you haven't already you can set a frame limit in-game.
I played the game for ~30min on Proton Experimental on AMD 5700 XT and it has been running without issues.
There has been past reports of issues and based on just the reports there's a fair chance it is Nvidia specific.
As for coil whine, if you haven't already you can set a frame limit in-game.
For some reason I've been fine with proton experimental and 9.0.4 ever since last night. I'm assuming i'll just have to chalk up the random one off issues to NVIDIA. I also limited the fps to 400 and that helped with the coil whine. I just figured I would point it out because I've simply never had it before.
Edit: Just tested GE and i cant replicate the entry screen freeze anymore. How odd I wish i managed to grab logs when it happened.
With https://github.com/ValveSoftware/wine/commit/6cd6af2bc12220ba1164ef81d8b4a596c3c548b2, this resolves a CPU usage issue with video playback (was visible from profilers) and frame rate during gameplay is much more stable. Similar improvement for EZ2ON REBOOT:R (1477590).
Huge thanks Conor!
Proton versions
proton experimentalx9 2025-09proton 9.0x1 2024-02proton 7.0x2 2023-11protonexperimentalx1 2023-11proton 8.0x1 2023-05
Launch options
PROTON_DISABLE_NVAPI=1`x1 2024-12PROTON_LOG=1x4 2024-12PROTON_LOG=1`,x1 2023-07DXVK_HUD=fpsx1 2023-06WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1x1 2022-03
Launch lines
gamemoderun gamescope -Y -i -n -f -b -W 1920 -H 1080 -w 2560 -h 1440 -r 240 -e --rt -- %command%x1 2023-01WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 %command%x1 2022-03
Upstream links
- ValveSoftware/Proton/issues/5196x1 2024-01
- ValveSoftware/Proton/issues/7445x1 2024-01
- ValveSoftware/steam-for-linux/issues/9586x1 2023-07
Compatibility Report
System Information
I confirm:
Symptoms
Game launches, but the processing done by XIGNCODE3 that's indicated by the grey progress bar below seems halted; it doesn't fill up like expected and then bring up the game menu selection. Even after ~30 minutes of waiting no progress in bar is indicated.
Same symptom is reported by other users on other system configurations: https://www.protondb.com/app/960170
Reproduction
Log
steam-960170.log
Log events described: Launched game and waited for approximately 15 minutes before closing the game from the Steam client, only moving the mouse when the auto-lock desktop session triggered due to inactivity every 5 minutes or so.
Other notes
Report template says to attach .log file after launching with
PROTON_LOG=1 %command%param, but I think running Steam via Flatpak may place it in another directory due to Flatpak sandboxing as it's not in $HOME/ despite verifying the command param being used to launch the game.Would be a great game to have running properly on a Linux based Steam Deck given it's not graphic compute heavy and has relatively simple controls.