Alliance of Valiant Arms Global (1473480)

Compatibility Report

• Name of the game with compatibility issues: Alliance of Valiant Arms
• Steam AppID of the game: 1473480

System Information

• GPU: RTX3090Ti
• Driver/LLVM version: NVIDIA 515.49.14
• Kernel version: 5.18.19-269-tkg-pds TKG SMP PREEMPT_DYNAMIC
• Proton version: TKG patchset on proton experimental bleeding edge.

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

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.

Begin with the attached clipcursor.txt and hookfix.txt patches and the named paths through ClipCursor, NtUserGetKeyState, PeekMessage, and dinput GetDeviceData. Reproduce the online performance and input problems, then trace their Wine server calls and compare the performance graph. The issue does not identify source files or tests, and its proposed scope spans several generic input and performance subsystems.