Open GoLD-ReaVeR opened 2 years ago
jinwk00
commented
1 year ago One more thing to add, I am having a message about "Runtime hack detected", despite nothing is hooking up into game process (other than Feral Gamemode in which it shouldn't do directly).
GoLD-ReaVeR
commented
1 year ago I'm having the same "Runtime hack detected" problem, with and without gamemoderun in the commandline. After enough times restarting the game and working through crashes and what not, the game will eventually succeed without kicking me from it. This problem started occurring about a week ago and this was without the game itself receiving an update. To my knowledge all environmental factors were constant, after this started happening I've updated the system as well as my proton build to no avail.
I have no indication as to what the anti cheat is flagging as a 'hack' so I also don't know what to do to workaround this issue.
Compatibility Report
System Information
I confirm:
Symptoms
Performance and input issues plague the game. The game does not consume the full power of my GPU, nor the full power of my CPU, yet it is rife with framerate drops, input lag or inputs just not being read.
Reproduction
Performance and input issues seem to occur when the game is played online.
Patchwork
Currently I made 2 patches to deal with performance issues that seem to be lingering issues with wine that for some reason never got addressed. Currently checking the performance graph for the game shows overloads on ClipCursor, NtUserGetKeyState and PeekMessage calls. The patches attached fix the ClipCursor performance (someone decided that opening a new window everytime the function is called is a good idea) and the event handler freeing currently active modules and being forced to reload them shortly after.
clipcursor.txt hookfix.txt
Todo
The NtUserGetKeyState issue is a lot harder to fix as is the mouse motions (and button presses) not registering properly. I was angry with how wine handles things before, now that I've read the code that handles the events I'm downright furious. I cannot comprehend why someone decides to store the keystate, which is directly available from the OS, on the singlethreaded wineserver and then to read it again from said wineserver.
This is an obvious recipe for problems and I see code that recognizes that these problems are there, but instead of fixing the problem the code works around it. What boggles my mind even more is that after the last incident where I threw a fit about the wineserver being a problem, the message was apparently not taken to heart and the issue of the wineserver being used in the way it is has been ignored. My trust in this proton project has been damaged and it will affect future decisions on whether I should purchase games or obtain them by other means.
What needs to be done is the input code needs to be stripped from the wineserver and needs to follow the Wine Is Not an Emulator maxim and tie directly to the Linux interfaces. There are no threadsafety requirements on hardware inputs since everything should be working in read only anyway. The following point of interest is the PeekMessage code which makes several calls to the wine server which hamper performance. They affect the game directly looking for messages as well as the dinput thread reading for inputs. The next one after that is the dinput GetDeviceData call which makes calls to the wineserver instead of just reading the device data.
These issues are generic issues, they trigger in other games but usually not as often because these games have other limits impacting their performance. So these are generic playability fixes that would improve QoL for every game.
The performance graph also shows a major disparity between the wine_syscall being made and the NtQueryPerformanceCounter that comes after it, I cannot detect why this code has these kinds of problems however.