I used the installer from the repository here, did not do anything after that.
The installer says if you plan to use DXVK to enable it and change a setting, and from what I can gather I want to do that? But I cant find any info on where I would actually issue the command to “set PBA_DISABLE=1”… also it references version 0.65 of DXVK but my options are only up to 0.52… and if I toggle that on the launcher doesnt open at all.
To get a later version of DXVK just type the version into the dialog as detailed here under the Manually Updating DXVK section.
Also does the same happen if you install it on a native partition? What are your system specs?
I just recently moved over to Linux as well, Ubuntu 18.04 (now XUbuntu, was MATE), running WoW under Lutris using Dox’ scripts. DXVK 0.70. Running on my gaming rig with an nVidia 1060 something-or-other. I get 35 running around the Trade District, 60-100 when out questing or in the island expedition. No idea what it was like under W10, didn’t care enough to check before I switched.
So I have reinsalled wow through the install script & now it has the DXVK hud, frame rates are over 100 at my gaming resolution so it matches almost exactly what my Windows boot does.
New issue though, any quick input causes the game to freeze up for a while, like the commands are put into a queue and its got a very shallow depth, it resumes normal play after a couple seconds.
This does not seem to be graphics setting related, as I can take part in world phased raids on rare mobs with 40 people and my frame rates keep up- its only lagging when I issue keystrokes of my own.
So far though I am super impressed and I cant wait to ditch windows, I just need to know where to look for input settings now I guess?
Never heard of this issue. I certainly don’t have it.
But it sounds similar to an issue in FFXIV, that is fixed by a special patch. Try using esync-ffxiv-3.15. Manage wine runners, install it, then set it for the game in configure for that game. See if it helps.
Oh and mark the thread as solved, since your original issue is solved. We can keep discussing your other issue here, but your fps is good now, so thats solved.
Zen kernel has MuQSS standard atm, but I just retested, Liq with MuQSS still works best for me. However, you have to check for yourself. Perhaps a kernel with PDS works better for you (SMT-Nice if you have HT / SMT).
I have a i5-4670k, no HT, and I have just retested 4 different kernels. Liq with MuQSS gave me the best fps.
Ok so I have narrowed it down further still. I have a razer naga mouse & its got a keypad on the thumb side. It seems that the combination of those keypresses & keyboard input cause my lag. spamming regular clicks and keystrokes on the main keyboard doesnt cause it.
ok logitech same thing… so i tried a nostromo and it does the same thing as well… then a 2nd full keyboard and BAM same thing… two keyboards = bad and the keypad on this mouse counts as one.
So I tracked this back to xorg, specifically xinput. The os spins up a ‘virtual core keyboard’ and a ‘virtual core pointer’ and assigns all pointers to the later and all keyboards to the former. This is the source of my woes, because it apparently does not like having both keyboard devices sending input in the same timeslices and it blows up when they do.
Creating a 2nd virtual keyboard device and assigning the mouse keypad to it makes the lag go away completely. Unfortunately, xinput also creates a 2nd virtual pointer device and that means a 2nd mouse pointer icon on screen… Which cannot be hidden.
Oddly enough, wow recognizes this 2nd pointer as a pointer and draws it with the hand. It does not render it correctly though, it has a glitchy square around the artwork where I assume it would be transparent. Also, having 2 hands on screen, one of them glitching out, is not a fun way to play.
If I connect a 2nd physical mouse and assign THAT mouse to the 2nd virtual, I can move the pointer off screen.
You people are probably very aware about this at this point, but someone in a discord server said Blizzard has some new Razer DLL that had these huge performance drops and that people had been distributing “dummy DLLs” to stop the hitches.
I’m sorry I can’t provide more information, because the problem didn’t affect me at the time, so I didn’t look into it. I’m almost certain Dox knows what I’m talking about.
