Proton
Proton copied to clipboard
DJMAX RESPECT V (960170)
Compatibility Report
- Name of the game with compatibility issues: DJMAX RESPECT V
- Steam AppID of the game: 960170
System Information
- GPU: RTX 2080 TI
- Driver/LLVM version: Nvidia 495.46
- Kernel version: 5.15.16
- Link to full system information report as Gist: https://gist.github.com/sanecito/183805229a161d62cd05fbd649ff61c3
- Proton version: experimental-6.3-20220119
I confirm:
- [X] that I haven't found an existing compatibility report for this game.
- [X] that I have checked whether there are updates for my system available.
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
- Launch the game
- Watch the XIGNCODE3 progress bar. On Windows it completes the bar within two minutes and brings up the game menu. Linux nothing should change even after 10+ minutes.
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.
@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!