Works flawlessly for me as well on Linux Mint 19/Nvidia GTX 1080. My steam_systeminfo.txt
I can conform FF VII works for me too.
my system info:
https://gist.github.com/Zero86Sk/d629f657c1ae861c36657cdf238a7765
I just tested it on Arch Linux using a Steam controller. Worked without a hitch.
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
Also works great on Kubuntu 18.04.1 with AMDGPU/RadeonSI.
Black screen after the transition screen to the first battle (and any another battle). Don't you have this problem ? @nvidiausers
Archlinux 64bit up to date with esync limit modified
Intel I7 4770k
GTX 980 (396.54.05 but does the same on the stable one)
Proton 3.7-6
Game works flawlessly.
System information: https://gist.github.com/der-coder/c73c297e666a64c5acae3e85c7d318fe
Game worked perfectly for me... with mouse and keyboard; it wouldn't detect my Xbox 360 controller though (possibly related to [#1549](https://github.com/ValveSoftware/Proton/issues/1549)).
https://gist.github.com/dearlygparted/d970f00749734326bc332cdebfb90085
It detected my Steam Controller.
Xbox one controler works fine.
On both Windows and Linux, Its a but too sensitive tho, like pressing A sometimes it goes through multiple menus. And tapping the analog does the same.
In my case, the Xbox 360 wired controller works in Steam BPM, native Steam for Linux games, and even in other Steam Play titles like Kingdom Come: Deliverance (where I also noticed it was too sensitive), but not in FF7.
I see that there are people possessing a nvidia card, who manage to run the game without problem. Did you do a special manipulation?
I'm now on Arch 64bit, llvm 7, nvidia 410.57 and proton 3.7-7 and always have a black screen after the transition of a battle start.
I experience a reproducible crash just when the game is about to do the first Chocobo Race in Corel Prison. I am running Steam via Flathub on Fedora 28 with this graphics chip:
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
Here are some debug logs that were printed on the console:
wine: Unhandled page fault on write access to 0x65746962 at address 0x76bb05 (thread 0037), starting debugger...
ERROR: ld.so: object '/home/game/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 827 for game ID 39140
Unhandled exception: page fault on write access to 0x65746962 in 32-bit code (0x0076bb05).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:0076bb05 ESP:00334fa0 EBP:65746972 EFLAGS:00210202( R- -- I - - - )
EAX:000001f8 EBX:7b638ff4 ECX:00000007 EDX:00000007
ESI:0013e5fc EDI:00000000
Stack dump:
0x00334fa0: 00000000 0013e5fc 735c6174 74726f68
0x00334fb0: 7073735c 65746972 0076bb00 00335024
0x00334fc0: 01680f38 00000001 00000000 0013e5fc
0x00334fd0: 0076e0f8 00000000 00000000 00000140
0x00334fe0: 000001e0 00334ff4 0077c445 01680f38
0x00334ff0: 00335024 00335098 0076d72c 01680f38
Backtrace:
=>0 0x0076bb05 in ff7_en (+0x36bb05) (0x65746972)
0x0076bb05: movl $0x0,0xfffffff0(%ebp)
Modules:
Module Address Debug info Name (144 modules)
PE 340000- 3be000 Deferred libvgmstream
PE 400000- fd5000 Export ff7_en
PE fe0000- 1232000 Deferred d3dx9_29
PE 1ee0000- 201d000 Deferred steam
PE 10000000-10037000 Deferred af3dn.p
PE 3b400000-3b41d000 Deferred steam_api
PE 65ec0000-66c1e000 Deferred avcodec-53
PE 68b80000-68bab000 Deferred avutil-51
PE 6ab00000-6abfe000 Deferred avformat-53
ELF 78174000-7818a000 Deferred msadp32<elf>
\-PE 78180000-7818a000 \ msadp32
ELF 79273000-7a800000 Deferred steamclient.so
ELF 7a800000-7a93d000 Deferred opengl32<elf>
\-PE 7a820000-7a93d000 \ opengl32
ELF 7aa72000-7aaff000 Deferred libvorbisenc.so.2
ELF 7b400000-7b7ea000 Deferred kernel32<elf>
\-PE 7b410000-7b7ea000 \ kernel32
ELF 7b7ea000-7b814000 Deferred libpng12.so.0
ELF 7b940000-7b96f000 Deferred libvorbis.so.0
ELF 7b96f000-7b978000 Deferred libogg.so.0
ELF 7b978000-7b9ea000 Deferred libflac.so.8
ELF 7b9ea000-7b9fe000 Deferred libgdbm.so.6
ELF 7b9fe000-7ba48000 Deferred libdbus-1.so.3
ELF 7ba48000-7bada000 Deferred libsndfile.so.1
ELF 7bada000-7bae2000 Deferred libxtst.so.6
ELF 7bae2000-7bb00000 Deferred libice.so.6
ELF 7bc00000-7bd0f000 Deferred ntdll<elf>
\-PE 7bc10000-7bd0f000 \ ntdll
ELF 7bd10000-7bda2000 Deferred libpulsecommon-12.2.so
ELF 7bda2000-7be00000 Deferred libpulse.so.0
ELF 7c000000-7c004000 Deferred <wine-loader>
ELF 7c00b000-7c017000 Deferred libsm.so.6
ELF 7c017000-7c040000 Deferred winepulse<elf>
\-PE 7c020000-7c040000 \ winepulse
ELF 7c040000-7c063000 Deferred mmdevapi<elf>
\-PE 7c050000-7c063000 \ mmdevapi
ELF 7c063000-7c079000 Deferred winejoystick<elf>
\-PE 7c070000-7c079000 \ winejoystick
ELF 7c454000-7c461000 Deferred libpciaccess.so.0
ELF 7c461000-7c46d000 Deferred libdrm_nouveau.so.2
ELF 7c46d000-7c47d000 Deferred libdrm_radeon.so.1
ELF 7c47d000-7c4a6000 Deferred libdrm_intel.so.1
ELF 7c4a6000-7d070000 Deferred i965_dri.so
ELF 7d070000-7d075000 Deferred libxshmfence.so.1
ELF 7d075000-7d07e000 Deferred libxcb-sync.so.1
ELF 7d07e000-7d083000 Deferred libxcb-present.so.0
ELF 7d083000-7d08a000 Deferred libxcb-dri3.so.0
ELF 7d1ba000-7d1bf000 Deferred libxdamage.so.1
ELF 7d1bf000-7d1c6000 Deferred libxcb-dri2.so.0
ELF 7d1c6000-7d1cb000 Deferred libx11-xcb.so.1
ELF 7d1cb000-7d1eb000 Deferred libxcb-glx.so.0
ELF 7d1eb000-7d202000 Deferred libdrm.so.2
ELF 7d202000-7d222000 Deferred libglapi.so.0
ELF 7d222000-7d2a2000 Deferred libglx_mesa.so.0
ELF 7d328000-7d458000 Deferred oleaut32<elf>
\-PE 7d340000-7d458000 \ oleaut32
ELF 7d458000-7d668000 Deferred lsteamclient<elf>
\-PE 7d510000-7d668000 \ lsteamclient
ELF 7d668000-7d69f000 Deferred uxtheme<elf>
\-PE 7d670000-7d69f000 \ uxtheme
ELF 7d6a1000-7d6a9000 Deferred libxfixes.so.3
ELF 7d6a9000-7d6b6000 Deferred libxcursor.so.1
ELF 7d6b6000-7d6c4000 Deferred libxrender.so.1
ELF 7d6c4000-7d6d9000 Deferred libxi.so.6
ELF 7d6d9000-7d6de000 Deferred libxcomposite.so.1
ELF 7d6de000-7d6e6000 Deferred libxxf86vm.so.1
ELF 7d6e6000-7d6eb000 Deferred libxinerama.so.1
ELF 7d6eb000-7d77f000 Deferred winex11<elf>
\-PE 7d700000-7d77f000 \ winex11
ELF 7d8fb000-7d938000 Deferred libexpat.so.1
ELF 7d938000-7d984000 Deferred libfontconfig.so.1
ELF 7d984000-7dab9000 Deferred libglib-2.0.so.0
ELF 7dab9000-7db79000 Deferred libharfbuzz.so.0
ELF 7dbf1000-7dbfb000 Deferred libuuid.so.1
ELF 7dbfb000-7dc44000 Deferred libpcre.so.1
ELF 7dc44000-7dc76000 Deferred libgraphite2.so.3
ELF 7dc76000-7dc90000 Deferred libz.so.1
ELF 7dc90000-7dcce000 Deferred libpng16.so.16
ELF 7dcce000-7dce1000 Deferred libbz2.so.1.0
ELF 7dce1000-7dd94000 Deferred libfreetype.so.6
ELF 7dd94000-7dee7000 Deferred msvcp90<elf>
\-PE 7ddd0000-7dee7000 \ msvcp90
ELF 7dee7000-7e187000 Deferred shell32<elf>
\-PE 7df00000-7e187000 \ shell32
ELF 7e187000-7e24a000 Deferred msvcr90<elf>
\-PE 7e1a0000-7e24a000 \ msvcr90
ELF 7e24a000-7e283000 Deferred ws2_32<elf>
\-PE 7e250000-7e283000 \ ws2_32
ELF 7e283000-7e2f8000 Deferred shlwapi<elf>
\-PE 7e290000-7e2f8000 \ shlwapi
ELF 7e2f8000-7e30c000 Deferred psapi<elf>
\-PE 7e300000-7e30c000 \ psapi
ELF 7e30c000-7e3c4000 Deferred msvcrt<elf>
\-PE 7e320000-7e3c4000 \ msvcrt
ELF 7e3c4000-7e405000 Deferred d3d9<elf>
\-PE 7e3d0000-7e405000 \ d3d9
ELF 7e405000-7e54d000 Deferred wined3d<elf>
\-PE 7e420000-7e54d000 \ wined3d
ELF 7e54d000-7e5c2000 Deferred ddraw<elf>
\-PE 7e550000-7e5c2000 \ ddraw
ELF 7e5c2000-7e5e6000 Deferred imm32<elf>
\-PE 7e5d0000-7e5e6000 \ imm32
ELF 7e5e6000-7e62b000 Deferred usp10<elf>
\-PE 7e5f0000-7e62b000 \ usp10
ELF 7e62b000-7e761000 Deferred comctl32<elf>
\-PE 7e630000-7e761000 \ comctl32
ELF 7e761000-7e885000 Deferred libsdl2-2.0.so.0
ELF 7e885000-7e8d8000 Deferred dinput<elf>
\-PE 7e890000-7e8d8000 \ dinput
ELF 7e8d8000-7e923000 Deferred dsound<elf>
\-PE 7e8e0000-7e923000 \ dsound
ELF 7e923000-7e94e000 Deferred msacm32<elf>
\-PE 7e930000-7e94e000 \ msacm32
ELF 7e94e000-7e9ce000 Deferred rpcrt4<elf>
\-PE 7e960000-7e9ce000 \ rpcrt4
ELF 7e9ce000-7eb25000 Deferred ole32<elf>
\-PE 7e9f0000-7eb25000 \ ole32
ELF 7eb25000-7eb3f000 Deferred version<elf>
\-PE 7eb30000-7eb3f000 \ version
ELF 7eb3f000-7ebb7000 Deferred advapi32<elf>
\-PE 7eb50000-7ebb7000 \ advapi32
ELF 7ebb7000-7ece4000 Deferred gdi32<elf>
\-PE 7ebc0000-7ece4000 \ gdi32
ELF 7ece4000-7eee2000 Deferred user32<elf>
\-PE 7ed00000-7eee2000 \ user32
ELF 7eee2000-7ef9a000 Deferred winmm<elf>
\-PE 7eef0000-7ef9a000 \ winmm
ELF 7efeb000-7f000000 Deferred libnss_files.so.2
ELF f7655000-f765b000 Deferred libxau.so.6
ELF f765b000-f768b000 Deferred libxcb.so.1
ELF f768d000-f76ac000 Deferred libgcc_s.so.1
ELF f76ac000-f770e000 Deferred libgldispatch.so.0
ELF f770e000-f7726000 Deferred libxext.so.6
ELF f7726000-f787e000 Deferred libx11.so.6
ELF f787e000-f78a2000 Deferred libglx.so.0
ELF f78a2000-f79a0000 Deferred libm.so.6
ELF f7b2e000-f7b34000 Deferred libdl.so.2
ELF f7b34000-f7b3f000 Deferred librt.so.1
ELF f7b3f000-f7baa000 Deferred libgl.so.1
ELF f7bac000-f7d48000 Deferred libc.so.6
ELF f7d48000-f7d67000 Deferred libpthread.so.0
ELF f7d67000-f7f1e000 Export libwine.so.1
ELF f7f1e000-f7f5a000 Deferred gameoverlayrenderer.so
ELF f7f5c000-f7f85000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
00000008 FF7_Launcher.exe
00000035 0
00000034 0
00000033 0
00000031 0
00000030 0
0000002e 0
0000002c 0
0000002b 0
0000002a 0
00000009 0
0000000c services.exe
00000022 0
0000001f 0
0000001a 0
00000016 0
00000011 0
0000000e 0
0000000d 0
0000000f winedevice.exe
00000015 0
00000014 0
00000010 0
00000018 plugplay.exe
0000001c 0
0000001b 0
00000019 0
0000001d winedevice.exe
00000024 0
00000023 0
00000021 0
00000020 0
0000001e 0
00000025 explorer.exe
00000029 0
00000028 0
00000027 0
00000026 0
00000036 (D) Z:\home\game\.var\app\com.valvesoftware.Steam\.local\share\Steam\steamapps\common\FINAL FANTASY VII\ff7_en.exe
00000042 15
00000041 15
00000040 0
0000003f 15
0000003e 0
0000003d 0
0000003c 0
0000003b 0
0000003a 0
00000039 0
00000038 0
00000037 0 <==
System information:
Wine build: wine-3.7
Platform: i386 (WOW64)
Version: Windows 7
Host system: Linux
Host version: 4.18.13-200.fc28.x86_64
I've read that there was a known issue with crashing at the chocobo races with the game many years ago, but theoretically those were fixed with version 1.0.2 and Steam seems to have 1.0.9, so I'm not sure that is relevant.
Just to rule out things, have you tested again with Proton 3.16 beta?
@bowlofeggs what you are saying sounds like an issue with the game and not an issue with Proton...
On Wed, 2018-10-24 at 20:53 -0700, Christopher Snowhill wrote:
Just to rule out things, have you tested again with Proton 3.16 beta?
Hi Christopher!
I did try that, but the game didn't seem to launch with that version. I
didn't spend enough time to collect logs for that, but I'll do that
soon.
I'll probably open a separate ticket about that, but I'll link it here.
On Thu, 2018-10-25 at 01:11 -0700, Vincent Grande wrote:
Are you running the Steam release, or original PC release of the
game?
This is the Steam release. I was also surprised to hit the crash since
all the reports about it were from long ago.
On Thu, 2018-10-25 at 01:55 -0700, Adrian L. Shaw wrote:
@bowlofeggs what you are saying sounds like an issue with the game
and not an issue with Proton...
Very possible, especially since there were reports of such a crash from
long ago. I don't know enough about Wine or Windows to debug it further
myself. The game does seem to work great otherwise.
My theory could be it has something to do with the integrated Intel chipset. Maybe the game was only tested on Nvidia/AMD gpus.
Time for me to start a new game and get to Corel Prison...
Hey @adrianlshaw, here is my save file. The first slot is just before the freeze. It's annoying because you have to go through a lot of dialogue and a boss fight, but after that you will be at the scene where you are about to do the chocobo race. It's right when the race is about to start that it crashes on my system.
The second slot I made with Black Chocobo to try to get my game past the crash and who knows if the state of it is OK for the game, haha.
@bowlofeggs Thanks for that! I dropped your save in the right directory but the game keeps deleting it on startup. I tried making sure that cloud saves were disabled whilst also being offline. Bit strange.
Maybe I can do a speed run from the beginning...
On Fri, 2018-10-26 at 12:49 -0700, Adrian L. Shaw wrote:
Thanks for that! I dropped your save in the right directory but the
game keeps deleting it on startup.
Ah, bummer. I've not tried using savefiles from other systems before,
so I have no idea how to advise. Oh well, thanks for trying it out, and
enjoy that speed run!
Game fails on login. Loads the Square Enix login platform, outputting a Network Connection Error. Tested on 3.7-8, 3.7-8 beta, and 3.16-4 beta.
I see that there are people possessing a nvidia card, who manage to run the game without problem. Did you do a special manipulation?
@elgabo86 no
Game has issues when starting.
Arch Linux. No ESYNC. 2560x1440 resolution.
When the very first battle begins, it consistently crashes with "Unknown exception has occurred".
Hello @Cxpher, please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.
Just to verify, are you using Proton 3.16-5 beta and not Proton 3.16-4?
Yes with 3.16-5 beta. It actually makes some games work better. I'll try with 3.16-4 when i'm home later.
Happens with 3.16-4 as well.
@kisak-valve
I experience a reproducible crash just when the game is about to do the first Chocobo Race in Corel Prison. I am running Steam via Flathub on Fedora 28 with this graphics chip:
Hi @bowlofeggs . So my "speed run" was substantially slowed down by the desire to get Yuffie and complete Fort Condor. I've just finished the Chocobo Race at Coral Prison and didn't encounter and glitches or crashes. I was also playing on a machine with Intel HD graphics like yourself. Anyway, that's my 2 cents.
Hey @adrianlshaw whoah that's surprising! I did see that there was an update to the game that I think my computer downloaded yesterday or maybe the day before… maybe they fixed it? I'll retry from my save point and see if I can do it now.
BTW, I just completed the game last night, including Emerald Weapon and Ruby Weapon. I haven't played the game since the 90's so it was a lot of fun to play again. The game worked great under Proton outside of that one crash I mentioned earlier. Such fun.
Oh yeah, you're right, there was a game update. To be clear the update was installed before I got to Coral Prison. The specific graphics chip I have is the Intel® HD Graphics 530. Yes, checking for this bug was such a good excuse to play it again. I have yet to kill the Ruby Weapon.
Still crashes after battle sound effects on 3.16-6.
@adrianlshaw I finally got around to retrying it, and the crash I hit still happens. Pretty odd. The weird part is that it is a crash that used to happen on Windows a long time ago. Oh well, not sure whether I can say it's really a proton issue or not. The rest of the game worked great for me.
I see that there are people possessing a nvidia card, who manage to run the game without problem. Did you do a special manipulation?
I'm now on Arch 64bit, llvm 7, nvidia 410.57 and proton 3.7-7 and always have a black screen after the transition of a battle start.
It's not a black screen. Game has crashed. There's a window that says exception if you alt+tab out.
Basically the game crashes on any battle. I loaded another save file i had and the moment i get into a battle, you hear the sound and the game crashes.
The battle transition is a framebuffer effect, where it captures the buffer and blends it over itself repeatedly. This should not crash, though. Have you tried 3.16-6? What about Wine Staging?
Hi,
Tried with older Proton versions too.
Didn't try with regular wine. It's supposed to work out of the box with
Proton with the status it's in.
https://www.protondb.com/app/39140
See latest report on Protondb. I'm not the only one seeing this.
On Mon, 7 Jan 2019, 09:46 Christopher Snowhill <[email protected]
wrote:
The battle transition is a framebuffer effect, where it captures the
buffer and blends it over itself repeatedly. This should not crash, though.
Have you tried 3.16-6? What about Wine Staging?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/694#issuecomment-451798106,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Arbrzmk4sEChZkNo0vjsgY--lTY2lvQoks5vAqb4gaJpZM4WM5Jn
.
Issue still exists with 3.16-7.
@Cxpher You said that you tried this with older versions of Proton too? On your machine is this crash specific to the 3.16 branch or is it also present on 3.7-8 or 3.7-8 beta?
@Cxpher You said that you tried this with older versions of Proton too? On your machine is this crash specific to the 3.16 branch or is it also present on 3.7-8 or 3.7-8 beta?
It crashes with every version the same way. 3.7-8 included. Any resolution. Any combination of proton tweaks or lack thereof.
Game launches and runs fine but any battle effect crashes it.
Game has issues when starting.
Arch Linux. No ESYNC. 2560x1440 resolution.
Hi @Cxpher can you provide some more info? Like your GPU, window manager type and version, etc. This can be found in Steam Help -> System Information.
Hi Adrian,
I'm using Arch Linux with GNOME 3.30.
NVIDIA EVGA GTX 670 FTW GPU with latest NVIDIA Linux drivers available.
Tried with latest proton build too. Same thing.
Intel UHD 630.
Tested with 3.16-8beta and 4.2-1. Works fine
Still happening on the latest version of proton. 4.2-7.
I have to use Proton 3.7-8 for this game or else graphics would be corrupted in some areas (at least in the beginning of the game where you name Cloud and Barret).
Using Gallium Nine did not help this.
Your Steam controller configuration will conflict with Square's controller input baked into the game. This will lead to two different buttons being pressed when you press a button.
The only solution I have found is to disconnect your controller, start the game, and then reconnect your controller.
I am using the top voted Steam controller layout "Final Fantasy VII DS4 by Ottman", which was automatically selected. This has everything fully binded to keyboard keys, except the left analog stick, which I also bound to the arrow keys.
Works great out of the box. Be sure to enable PROTON_USE_D9VK=1 and REUNION patch, especially for the 60FPS BATTLES and BEACAUSE translation.
Wow, I didn't know there was a patch for 60FPS battles. Nice.
I had the crashes when starting battles and fixed it by moving the game to an ext4 drive (was on NTFS).
I actually have it on XFS.
On Tue, 14 Apr 2020, 06:22 Miguel Branco, [email protected] wrote:
I had the crashes when starting battles and fixed it by moving the game to
an ext4 drive (was on NTFS).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/694#issuecomment-613126099,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK3OXTQZLZ7HA2GU7PATIQ3RMOGA5ANCNFSM4FRTSJTQ
.
I managed to get the crashes when starting battles sorted by moving it to the default game folder on Steam (in your home partition) which happens to be on a SSD. Still XFS though.
Such a weird issue. Does not work on non-default XFS Steam partition (on a HDD) but works fine on a default XFS Steam partition (on a SSD).
I also had the black screen at battle problem with a shared BTRFS drive (accessible from Windows by WinBTRFS), and also fixed it by moving to my main BTRFS drive (albeit, on a separate subvolume).
The library I moved it to isn't the default either. Weird issue.
EDIT: I can't get Reunion working, for the record. It's as if the needed registry entries are never created by the installer. And I needed to force ddraw.dll to native/built-in to even get Reunion to produce logs.
Any update on how to get Reunion working?
EDIT: I was able to manually import registry files for FF7 to get it working
Having some annoying issues with inputs. When using a keyboard sometimes I get double presses from a single keypress. And when using a controller it feels like something is holding down the B button. I don't remember these issues from before. I'm using Ubuntu 20.04. If anyone else has had this issue then let me know.
Had some issues playing this game with the Steam Deck:
Not sure if this is the best place to drop this, let me know if Deck reports need to go somewhere else.
Much like FF8, Final Fantasy VII is a game that both uses DirectInput, and has an external launcher. The launcher window gets spawned when the game is launched through Steam, and it stays open in the background when the game is then, in turn, launched through it.
Steam Input has problems with DirectInput when a game spawns multiple windows: when configured as a proper joystick, Steam Input cannot control the game because the inputs only get passed to the launcher and not the game window. This means that under Linux, it's not possible to use a joystick configuration with this game (or other games with DirectInput + stay-in-the-background launcher window).
Final Fantasy VII (39140) Using 7th Heaven - Freezing/Stuttering/Long Loading Times Since Proton 8.0-4
Issue transferred from https://github.com/ValveSoftware/Proton/issues/7480.
@dotaxis posted on 2024-02-05T18:01:47:
I maintain a small project (7thDeck) to get mods running on FF7 using 7th Heaven.
Since the release of Proton 8.0-4, about 50% of my users were reporting freezing and stuttering going into battles and cutscenes that were not present before. We did try downgrading DXVK and other dependencies via protontricks but found the issue to be with Proton itself, as far as we could tell. Our solution at the time was to roll back to Proton 7 and hope the next major update would fix this. It was not fixed in 8.0-5.
Unfortunately, we can not find anything useful in the logs to pin down what may be causing this, so I did not decide to report an issue sooner. It seems this only happens for about 50% of end-users, and I'm not able to reproduce it on my own hardware, so my ability to troubleshoot is also quite limited.
I am waiting on a proton log from an affected user and will attach it as soon as I can.
Here is a proton log for the above report. I am able to reproduce it on my deck now.
steam-10094714141244653568.zip
@dotaxis you mention that not everyone has issues, is there something in common from people that do? Like everyone affected having a steam deck (as you mention you can see the issue with yours).
I looked at the install script briefly and found a few odd things. What's the purpose of writing into windows-label, and windows-serial? Is dinput being deleted because the mod has its own dinput and it's causing issues? If that's the case, what you should do is move the mod's dinput into the game's folder, and make wine load that one instead of the system one. This can be done with the following environment variable WINEDLLOVERRIDES="dinput=n,b"
Hello @simifor FFNx author here, helping @dotaxis in debugging this issue on the Deck. So we both did try the approach you mentioned. The good news is that we removed the way dinput.dll is overridden now, and still allows us to load mods through 7th Heaven.
The bad news although it that it still stutters in some points. Especially when we use blit commands. Another thing I noticed that is the swap chain starting Proton 8 is created using this mode:
info: Presenter: Actual swap chain properties:
info: Format: VK_FORMAT_B8G8R8A8_UNORM
info: Color space: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
info: Present mode: VK_PRESENT_MODE_IMMEDIATE_KHR (dynamic: no)
info: Buffer size: 1280x800
info: Image count: 4
info: Exclusive FS: 1
Although we tested this under 4 different backends on our own side ( all supported natively by FFNx ): D3D11, D3D12, OpenGL and Vulkan. All of them present the same identical behavior, so this excludes from the picture either vkd3d or dxvk. Even using Vulkan with STEAM_COMPAT_CONFIG="nativevulkanloader" presents the same behavior. Same goes for OpenGL where no lib is used, pure Wine and stutters the same.
The only lead we have is that this started to present itself starting Proton 8.0-4 release, but we're not really able to pinpoint exactly what could be. We did also try to downgrade dxvk to 1.10 ( same version used under Proton 7.0 ) in Proton 8.0 and stutters the same. Another lead I have is that this is related to Wine 8.x branch which introduces the new WOW64 mode, I wonder if the wine binary present in Proton is a 64bit one and 32bit binaries are emulated under this new WOW64 mode. Is that the case?
One final note, for some reason if we run the game using FFNx but not the dinput.dll override, then the game runs fine. This is how our dinput.dll looks like: https://github.com/tsunamods-codes/7th-Heaven/blob/master/7thWrapperLoader/dllmain.cpp#L10
Thank you in advance!
@dotaxis you mention that not everyone has issues, is there something in common from people that do? Like everyone affected having a steam deck (as you mention you can see the issue with yours).
I looked at the install script briefly and found a few odd things. What's the purpose of writing into windows-label, and windows-serial? Is dinput being deleted because the mod has its own dinput and it's causing issues? If that's the case, what you should do is move the mod's dinput into the game's folder, and make wine load that one instead of the system one. This can be done with the following environment variable
WINEDLLOVERRIDES="dinput=n,b"
Hey, thanks for your reply.
The purpose of writing the windows-label and windows-serial is as a No-CD patch since we are using a modified ff7.exe. This is an adaptation of a very old method of getting the software working, so the dinput.dll stuff was actually left over from that. Using winedlloverrides works exactly as expected and as such we no longer need to rely on protontricks.
However, this doesn't solve our problem of slow loading and stuttering. We have confirmed 100% the issue to NOT be DXVK, as upgrading DXVK to 2.3 in a Proton 7 prefix does not cause the same problem. The issue also happens using native Vulkan.
As for the bit about 50% of users being affected, I think it is actually 100%. When the issue reared its head it was right after the release of 8.0-4 and I think everyone unaffected was still on 8.0-3. Now that everyone is on either 8.0-4 or 8.0-5, everyone is affected by the bug.
I'm really scratching my head here. Back when this first happened, using Proton 7 was a good enough fix for me. But now that we have OLED decks it's a lot more important to have HDR support and whatever else ends up in future versions of proton.
Would appreciate any further insight anyone could offer us.
it could be useful to bisect for the commit where the stuttering starts but I couldn't help you with that at this time. Are there drawbacks to loading the mod through FFNx?
@dotaxis I'm not familiar with this game/mod, so I apologize in advance for the questions that are probably silly to you.
@dotaxis I'm not familiar with this game/mod, so I apologize in advance for the questions that are probably silly to you.
1. I was trying to follow your steps to repro but it looks like both branches that you linked are gone? Are you still seeing the regression with the proton-experimental branch? (which I'm assuming is the branch I should use?) 2. Could you give some details about what exactly I should do in-game to trigger the stutter?
Hi, thank you for the reply.
The dev branch was merged into master and deleted afterward, and the proton-experimental branch was created so we could continue testing with Bleeding Edge.
To trigger the long load times you can follow these steps:
save00.ff7 is inside a directory called saveYou will experience a several second black screen when loading into the game. If you run North into town and then back out of town into the world map, you will again experience a several second black screen before the world map loads.
If you follow steps 2-5 again with the master branch, you'll see that loading is instantaneous.
I tried building several different versions of Proton 8 from source and seemed to experience the delay on all of them, but this issue wasn't reported or seemingly noticed by anyone until Proton 8.0-4 went live on the deck, so I'm not sure if there's something wrong with my build process or what is really going on.
Like I mentioned above, the mod loaded does not need to be one that actually affects gameplay. A mod that I package with 7thDeck for the Steam Deck only changes FFNx configuration and makes no modifications to the game at runtime, but it still triggers the bug because the dinput.dll is loaded.
Any insight on this would be greatly appreciated.
The slow loading issue appears to be gone in proton 9
The slow loading issue appears to be gone in proton 9
Can confirm the same, me and @dotaxis have been trying this since it became available on Steam and both had exactly the same result. Looks like the rebase on top of Wine 9 upstream fixed the problem.
Now that Proton Experimental is based on Proton 9 I think we can consider this resolved.
Proton unable to run .NET 9 mod game (fails with CoreCLR error)
Issue transferred from https://github.com/ValveSoftware/Proton/issues/8960.
@joan31 posted on 2025-08-07T21:09:21:
.NET 9.0 application (FF7_SYW_Unified.exe) fails to launch using any official Proton version. The following error appears in the log:
Failed to create CoreCLR, HRESULT: 0x80070005
...
Message: Failed to load System.Private.CoreLib.dll (error code 0x80070005)
Path: Z:\opt\\games\\FF7SYW\\FF7_SYW_Unified\\System.Private.CoreLib.dll
The launcher used to work fine when targeting .NET Framework 4.5, but now that the developer migrated to .NET 9.0, it fails with this error. The same setup works without issues under Wine (tested with Wine 10.12 and winetricks install: dotnet40 dotnet48 dotnet9).
/opt/games/FF7SYW/FF7_SYW_Unified/FF7_SYW_Unified.exemkdir -p /opt/games/FF7SYW/FF7PRO
SteamGameId=ff7s PROTON_LOG=1 PROTON_LOG_DIR="$HOME/logs_ff7p" PROTON_ENABLE_WAYLAND=0 \
STEAM_COMPAT_DATA_PATH=/opt/games/FF7SYW/FF7PRO/ \
STEAM_COMPAT_CLIENT_INSTALL_PATH=/home/joan/.local/share/Steam \
/home/joan/.steam/steam/steamapps/common/Proton\ 10.0/proton run /opt/games/FF7SYW/FF7_SYW_Unified/FF7_SYW_Unified.exe
Result: crash with CoreCLR error HRESULT: 0x80070005 (Access Denied).
I tried to force and install winetricks dotnet40 dotnet48 dotnet9 on proton prefix, but I didn't change anything and the issue is still here.
If Wine handles this correctly, it's possible Proton could be improved to support .NET 9 applications better. Alternatively, if there's a known workaround, I would be very grateful to learn about it.
Thank you for your work on Proton and your support! 👍
@kisak-valve thanks to report here my issue
I hope you will found a solution 👍
proton 10.0x1 2025-08proton experimentalx3 2024-02proton 8.0-4x3 2024-02proton 7.0x1 2024-02proton 8.0x1 2024-02proton 3.7-8x1 2019-06proton 3.7-7x2 2019-01proton 3.16-4x1 2018-12proton 3.16-5x1 2018-12proton 3.16x2 2018-10proton 3.7-6x1 2018-09proton 3.7-3x2 2018-08PROTON_LOG=1x2 2025-08PROTON_ENABLE_WAYLAND=0x1 2025-08PROTON_LOG_DIR="$HOME/logs_ff7p"x1 2025-08STEAM_COMPAT_CLIENT_INSTALL_PATH=/home/joan/.local/share/Steamx1 2025-08STEAM_COMPAT_DATA_PATH=/opt/games/FF7SYW/FF7PRO/x1 2025-08WINEDLLOVERRIDES="dinput=n,b"x2 2024-02STEAM_COMPAT_CONFIG="nativevulkanloader"x1 2024-02PROTON_USE_D9VK=1x1 2019-11corelib.dllx1 2025-08dinput.dllx3 2024-02ddraw.dllx1 2020-050x80070005x1 2025-08
Works flawlessly.
Specs: Proton 3.7-3, Ubuntu 18.04, NVIDIA Corporation G94GL [Quadro FX 1800] (rev a1)