Open aufkrawall opened 3 years ago
Works fine on my end. The important bits are to use _protonify
for the syscalls emulation and to have amdags-proton.mypatch
to pass the driver check in your _community_patches
array. It might need a fresh prefix due to the DRM and recent wine upstream changes, though.
You may also need mesa-git for the latter.
The DRM works in an interesting way. For many people the game stopped working recently with the exact same log as you. They all had something in common. They did run the game with one of the proton builds that got initial RDR2 support on their prefix. What's interesting is that they then could, afterwards, run the game with a plain wine staging or lutris or proton GE without the syscall patches. It looks like the game stores an activation backup of some sort that isn't checked for a while, yet allowing the game to run if present. Then at a later date, it's checked (possibly against an online copy), and prevents the game from running if it fails. Thing is, it's using some syscalls to make that check, which the aforementioned builds don't/didn't support. In -tkg, for example, we're only supporting them since a few days. It"s supported on Proton 5.13 and the new 6.3 builds, but was broken for a while (and might still be on 5.13) due to a vulkan related regression.
Thank you!
Unfortunately I can't get it to work with _protonify
+ amdags.mypatch
either, also a clean prefix doesn't help. :(
I wonder if it makes a difference that I've switched from a Skylake to a Rocket Lake CPU?
Maybe. Hard to say without more feedback from others using rocket lake. iGPU disabled?
Yep (F model without a GPU). The game starts when I go back to staging-tkg version 5.20, 6.0 doesn't work either.
Huh, it works with your precompiled 6.5.r1.g2e42e7d9 build.
Hmm :frog:
I have another problem, the game does not start in any way except with proton-tkg. Tried proton 6.3, 6.5-GE-2, experimental. So I'm grateful for your work.
The game has a huge number of problems, for example, the game has a VRAM leak if you play with dxgi
from wine, at the same time if you run dxvk dxgi + RADV
there are no problems, but there is a problem with amdvlk
and amdvlk-pro
.
What's the main difference between a proton and a wine? When I run through dist proton-tkg everything starts up, at the same time wine-tkg doesn't even create the game window.
Got it working, I have to set vulkan-1.dll
to native. :tada:
Now I wonder why this is needed with self-compiled builds, but not with your precompiled one?
Do you have vulkan-1.dll into game folder?
No, I think it's put into system32 folder by VulkanRT-1.1.108.0-Installer.exe shipped with the game.
Of course, this explains why there are no such problems in the steam version, as far as I understand vulkan-rt is installed when the game is first configured, and vulkan-1.dll is native by default in the proton script. Thank you for sharing your discovery.
Now the game runs on proton 6.3, thanks again. Need to write a report on protondb, I hope this will help someone else solve the problem.
How did you find the solution?
Trial & error. :)
Though the weirdness hasn't ended for me yet: It somehow works only with wine-staging 6.6 (no custom commit as head). When I set _staging_version="v6.5"
, it once again doesn't start. And with 6.6, cursor input is ignored (due to raw input patch set currently not working?).
Got it working, I have to set
vulkan-1.dll
to native. tada Now I wonder why this is needed with self-compiled builds, but not with your precompiled one?
_protonify=true
does that by default, unless you had an override in place.
Trial & error. :) Though the weirdness hasn't ended for me yet: It somehow works only with wine-staging 6.6 (no custom commit as head). When I set
_staging_version="v6.5"
, it once again doesn't start. And with 6.6, cursor input is ignored (due to raw input patch set currently not working?).
6.5 release is a shitshow tbh. 6.6 has indeed an issue with staging's rawinput re-enablement that will hopefully be fixed shortly. Remi is aware and working on it afaik.
Actually I lied. Got confused after a chat with GE about it earlier. Proton (and as a result, _protonify=true
) enforces builtin, because many games break with native. I found out that builtin got broken along the way in winevulkan and allowed native to have priority for a little while, specifically for RDR2. Then the issue got fixed - or so it should have been. Upstream wine/staging are now preferring native over builtin for vulkan-1, which works for RDR2 (but breaks other games as explained above).
Unless there's been another regression, it should work on master without the native override.
That commit has landed and I now finally have a self-compiled build with fullscreen hack etc. that works with RDR2. :)
Different topic: Though EA Origin unfortunately is regressed after 6.2, it just freezes when trying to start Mirror's Edge Catalyst and it tries to sync save games with cloud. :(
With latest master & _protonify=true
, I still have to force native vulkan-1.dll
to make RDR2 start.
Different topic: Though EA Origin unfortunately is regressed after 6.2, it just freezes when trying to start Mirror's Edge Catalyst and it tries to sync save games with cloud. :(
Are you using futex2 by any chance? It's known to break Origin.
Different topic: Though EA Origin unfortunately is regressed after 6.2, it just freezes when trying to start Mirror's Edge Catalyst and it tries to sync save games with cloud. :(
Are you using futex2 by any chance? It's known to break Origin.
Just gave it a try: It now even crashes, also without futex2/fsync. When downgrading to 6.2 (recent build from yesterday), it once again works normally with futex2 and also the game starts just fine.
Weird. Possibly a regression then. 6.5 through 6.6 has been pretty terrible on that front so far.
Gave it a few more tries: It kind of works when forcing dxgi and d3d11 to builtin for Origin.exe and then disable cloud sync. The UI is really slow though, as it stalls the Xserver an awful lot. But at least it's possible to start ME Catalyst with great performance + futex2 and recent staging commits as head.
Hi,
I met two problems with RDR 2 on proton-tkg 6.8.r0.g0f00e37c-326
:
I was too tired yesterday to get a log, but when I today ran RDR with logging enabled, then I saw a beautiful screen suggesting buying RDR again in-game. rdr_log.zip I have compressed the log due to the big size of it.
Hi, I met two problems with RDR 2 on proton-tkg
6.8.r0.g0f00e37c-326
:1. Error with AMD driver initialization on start, but after accepting it starts(despite the fact that I have an nvidia card) 2. usually after an hour game likes to froze rather randomly. ~Despite bugs above game works rather well~
I was too tired yesterday to get a log, but when I today ran RDR with logging enabled, then I saw a beautiful screen suggesting buying RDR again in-game. rdr_log.zip I have compressed the log due to the big size of it.
First "issue" is expected. The game fails to run when not spoofing AMD on Nvidia hardware (nvapi shenanigans).
The second one, however, has also been reported on regular Proton when using Nvidia (it doesn't happen on AMD), which tends to point to a driver issue since the game uses native vulkan.
Regarding the last issue with license check failing, there seems to be a couple regressions with network connectivity on (at least) staging lately, which is a likely culprit. The game's DRM makes online checks and gives that screen when it fails. Usually, relaunching a couple times works.
RDR2 activation worked for on the second try with most recent wine-staging-tkg build. Finally, also Origin cloud sync works again, though I have to start it with --no-gpu
to prevent it from crashing.
It has once again stopped working for me with recent builds, RDR2 crashes with or without native vulkan-1.dll.
Just tested on my end with 6.8r15 and working just fine :shrug:
It starts for me if I build without fullscreen hack. However, also without it, wineserver maxes out one CPU thread while Rockstar Games Launcher is running, which is a very recent regression as well.
Wayland?
Still Xorg, I probably won't make the jump for at least another year or so. :)
So weird. It works fine with fs hack here.
I also had issues with FSH in other games like Heroes of the Storm, but at least that case is gone since the latest update for FSH.
Does winecfg.exe crash for you when changing DLL override statuses? It does that for me for quite some time already, and I wouldn't be surprised if that indicated that something's quite wrong/regressed (with upstream).
Edit: Seems to be unbroken in wine-staging 6.10 from Arch repo.
It's once again caused by FSH :frog: :
wine: configuration in L"/home/frog/.wine" has been updated. wine: Unhandled page fault on write access to 00007FA09CE29930 at address 000000007BC2A09B (thread 0138), starting debugger...
Positive news first: RDR2 generally works without Wine specific issues for me in recent wine-tkg-staging-fsync-git-6.18.r4.g7f9b324d-326-x86_64 build. :frog:
However, my general Proton fullscreen hack issue still persists, it still makes winecfg crash. However, it doesn't do so with lutris-fshack-6.14-3. I wonder what it does differently in terms of fullscreen hack?
@aufkrawall Do you have any problems with the game after the last update?
Hello, it crashes on launch with this probably not really helpful verbosity: out.log winedbg crashes when clicking the details button.
With regular wine or wine-staging 6.5 from Arch repo, it just starts and seems to run fine.
The weird thing is I had it running with wine-staging-tkg after a880eac9ea17897e8783ffcde5e40010ad2d3107 . But for whatever reason, it now doesn't work anymore with the same build I used before. It also doesn't work when compiling recent wine-staging-tkg without any changes to the config (or with
_staging_version="v6.5"
). Also_update_winevulkan="false"
doesn't help. It seems to crash right before the "Vulkan driver too old" prompt would appear, the game window is not yet visible.