Far Cry Primal invisible / flickering nature
This is a known problem with the game that randomly pops up whenever I change pretty much anything, and I believe is a game bug, since it seems to rely on uninitialized memory having certain contents. I don't plan to waste any more time on this game and don't consider it fixable.
So at the moment I can play with the older version of DXVK. This is not a problem for me, but I thought you might be interested. Technical game underdeveloped, but it looks nice and people will buy it;)
At first I thought it was a different issue because he was writing about a red problem.
Yeah that mostly happens in the benchmark in addition to flickering vegetation. They go hand in hand.
For what it's worth, on my system I can't reproduce the issue with latest master, but it is broken on 1.4.4. It's weird that it works for you with 1.4.4.
Maybe the location matters, or vram. In time, everyone will forget about this game, nothing to worry about.
Apparently Far Cry 4 & 5 have the same issue.
In Far Cry 4 the issue started with commit c7718e5952c06667a8e93fa2e71f4037a462802e. I don't have Far Cry Primal but since the problem occurred in 1.4.5 first it's probably the same commit.
I highly doubt the commit in question is actually the cause of the bug (IIRC Far Cry 4 even uses UAV counters so the code literally never gets called), but rather triggers some undefined behaviour elsewhere. I still do not understand what the problem is with the Dunia Engine games, and therefore cannot fix it.
Edit: Actually there might be a bug there, but again, it shouldn't affect the older Far Cry games.
Don't know about FC4 but I can confirm that this does not fix Far Cry Primal.
@K0bin what is "this"?
The transferCommands commit. Sorry, should've made that a bit more clear.
Doesn't fix FC4 either
This issue seems to be very weird indeed, when commenting out everything in InitUavCounter
https://github.com/doitsujin/dxvk/blob/c7718e5952c06667a8e93fa2e71f4037a462802e/src/d3d11/d3d11_initializer.cpp#L52-L64
the issue is still there, but when commenting out the line that calls the InitUavCounter function:
https://github.com/doitsujin/dxvk/blob/c7718e5952c06667a8e93fa2e71f4037a462802e/src/d3d11/d3d11_device.cpp#L431
the issue is gone.
When trying these DLLs neither the game nor Uplay launch for me and I get the following error messages:
002e:err:module:import_dll Loading library dxgi.dll (which is needed by L"C:\\Program Files (x86)\\Ubisoft\\Ubisoft Game Launcher\\libcef.dll") failed (error c000007b).
002e:err:module:import_dll Loading library d3d11.dll (which is needed by L"C:\\Program Files (x86)\\Ubisoft\\Ubisoft Game Launcher\\libcef.dll") failed (error c000007b).
Hope I did everything right, I created a new folder in .local/share/lutris/runtime/dxvk (also the x32 and x64 subfolders) and put the files in there(also changed the DXVK version in Lutris etc). I also tried replacing the DLLs from an already existing folder, but that didn't work either.
MSVC builds dont work either this time.
I only provided x64 there
@Joshua-Ashton are those debug builds? Those don't work on wine because they require debug versions of pretty much all Windows DLLs as well.
@Brn9hrd7 that sounds a lot like some registers that should be preserved aren't actually preserved. Can you test if changing the declaration to void STDMETHODCALLTYPE InitUavCounter( changes anything here:
https://github.com/doitsujin/dxvk/blob/c7718e5952c06667a8e93fa2e71f4037a462802e/src/d3d11/d3d11_initializer.h#L38
@Brn9hrd7 actually one more idea - can you get rid of the exception hadling, i.e. comment out try and the whole catch block in that function?
If any of that fixes it, we're bleeding state for some reason, but I don't really see how calling conventions used in private code, or even exception handling, would affect the caller unless either there's a compiler bug or the game makes some really weird assumptions.
Unfortunately neither adding STDMETHODCALLTYPE to the declaration nor commenting out the exception handling changes anything.
I've even tried removing the argument from InitUavCounter
m_initializer->InitUavCounter();
and the issue was still there.
FYI commenting out that method call didn't make a difference with MSVC builds with Primal.
@Joshua-Ashton are those debug builds? Those don't work on wine because they require debug versions of pretty much all Windows DLLs as well.
It was a release build.
The official 1.5.2 builds seem to work again. ¯\_(ツ)_/¯
The official 1.5.2 builds seem to work again. ¯_(ツ)_/¯
FC4 still has the flickering issue, unfortunately.
With Proton 5.6 GE it doesn't flicker for me but everything is tinted red... And there's no sound except during the intro video.
Related issue and no one knows why that happens either. It happens with some DXVK versions and compiler combinations and not with others.
I've never used the diffing tool in Ghidra before, but FWIW here's the different disassembly between the code built with and without the call. red outline where the code starts to diverge, before that everything is identical down to register usage (in that function, at least):
the different function names are because I didn't bother renaming in the fixed version in ghidra.
I thought I'll give this game another try: The red tint is gone now, and performance is much better now. It is even that good that I see 60 fps now instead of 25-ish. But now, vegetation is flickering. If I adjust the settings to stay below 60 fps, there's no flickering. As soon as the fps get above 60 fps (well, it gets to 61 fps), vegetation starts flickering wildly.
It appears that it doesn't matter if vsync is on or off, the frame rate is limited to 60 fps for me. Also, vsync settings don't seem to work at all for me: Either games don't sync at all, or if they sync, vsync lags behind because I see tearing either in the first third of the screen, in the middle, or last third of the screen, sometimes the tearing is moving up and down at little during playing. I'm not sure why that is but whatever it is, it is not syncing correctly for me.
Is it possible that rendering of the scene is not complete when the page flip occurs? And that's an issue once we are above the screen refresh rate? I've seen some other games with flickering lighting/shadows, too, once the fps are near or above the screen refresh rate so there might be some syncing missing in the code?
The brightness/red tint may be a similar issue: If I run in very high settings / high resolution and manage to get down to 10-15 fps, I see the red tinting and high brightness for a few seconds during the benchmark. But when the game sits locked at 60 fps, the red tint and brightness goes away during the first few frames rendered.
For FC Primal, I've only run the benchmark which MAY ignore vsync anyways - I'm not sure. I'm currently trying to figure out why it ignores my gamepad... But that's a different issue not belonging here.
Using: Proton Experimental (I think it ships latest DXVK)
This is fixed in Proton-6.0-GE-1, at least for far cry 4. I assume primal is also fixed, but don't own the game to test it.
Proton versions
proton 6.0-ge-1x1 2021-01proton experimentalx1 2020-12proton 5.6x1 2020-04
DLLs
d3d11.dllx1 2020-01dxgi.dllx1 2020-01libcef.dllx1 2020-01
When I start the game on the latest version of DXVK (1.4.5), trees and plants flicker and the sun is too bright. There is no flickering problem during recording apitrace, which is strange. Everything works well in older versions.
DXVK 1.4.4
DXVK 1.4.5
Software information
Far Cry Primal, V-sync off. All details are set to minimum. The issue also occurs in higher settings. Resolution: 1680x1050.
System information
Apitrace file(s)
https://drive.google.com/open?id=1vESVeEb7nx3Ri-mnLpQoL8e-kLbImaGe
Apitrace with DXVK 1.4.5
Log files
d3d11.log:
FCPrimal_d3d11.log
dxgi.log:
FCPrimal_dxgi.log