World of Warcraft

Just one word, works. Chosen to alpha test and running windows 10 and wine staging pba, performance is a near match, with DX11. DX12 is broken in windows, and does not exist yet in wine, but decent fps in wine with pba. I build just a 64 bit wine, and symlinked the alpha, so that I would be testing same settings with both Windows and wine. First day, windows crashed with Error #132, the dreaded error that blizzard defines as "something broke the game". Updated the Windows Nvidia Drivers, still crashed, came to linux, runs fine. Rested a day, checked for updates to the alpha, none downloaded, ran windows first, no errors, decent fps, made a new toon, ran starting quests,Booted Linux, run alpha, works great. Release date of 8/14/18 for BFA, so looking forward to the changes between now and then. Will update this comment thread with relevant info.

Error #132 ->
If the *game* launch dies with this I've found that I have to kill off the running wine server. (I've found that even if I'm launching the game directly and I get this, wineserver can be left running for several minutes after the game dies)
I've not seen this for launching Battle Net Client unless you're missing the TLS libraries.

Do you have issues with the water? I've been playing the Alpha, now beta, and the water is always one solid color, different every time I log in. There are other items in the world that are the same color. It seems like the texture for the water is missing, and the color is what shows. Maybe the same for the other items. Everything else has been working great.

Is the PBA patch for D3D9 or D3D11?

its for both, since pba d3d11 works fine for me(UDH, Geforce 1080Ti).

Thanks!
I was reading the original blog post and it was talking a bit about d3d9 architecture, but didn't mention this improving performance for d3d11 :)

Following your exact steps on ubuntu. I get the following errors when I do $ git apply ../wine-pba/patches/*


../wine-pba/patches/0001-wined3d.patch:87: trailing whitespace.

../wine-pba/patches/0001-wined3d.patch:1241: trailing whitespace.

../wine-pba/patches/0001-wined3d.patch:1522: trailing whitespace.

error: patch failed: dlls/wined3d/buffer.c:28
error: dlls/wined3d/buffer.c: patch does not apply
error: dlls/wined3d/buffer_heap.c: already exists in working directory
error: patch failed: dlls/wined3d/context.c:4956
error: dlls/wined3d/context.c: patch does not apply
error: patch failed: dlls/wined3d/cs.c:73
error: dlls/wined3d/cs.c: patch does not apply
error: patch failed: dlls/wined3d/device.c:840
error: dlls/wined3d/device.c: patch does not apply
error: patch failed: dlls/wined3d/directx.c:111
error: dlls/wined3d/directx.c: patch does not apply
error: patch failed: dlls/wined3d/Makefile.in:6
error: dlls/wined3d/Makefile.in: patch does not apply
error: patch failed: dlls/wined3d/resource.c:340
error: dlls/wined3d/resource.c: patch does not apply
error: patch failed: dlls/wined3d/state.c:4797
error: dlls/wined3d/state.c: patch does not apply
error: patch failed: dlls/wined3d/texture.c:2096
error: dlls/wined3d/texture.c: patch does not apply
error: patch failed: dlls/wined3d/utils.c:6321
error: dlls/wined3d/utils.c: patch does not apply
error: patch failed: dlls/wined3d/wined3d_gl.h:44
error: dlls/wined3d/wined3d_gl.h: patch does not apply
error: patch failed: dlls/wined3d/wined3d_private.h:75
error: dlls/wined3d/wined3d_private.h: patch does not apply

Can someone help a noob?

it looks like staging was applied after pba, not before. if you ran the script in the order shown, it will apply staging patches first, but if the staging patches failed, then pba will also fail. Staging was rebased 1 day ago, so it the devel source from winehq was updated, staging may need to be rebased again. I will try this morning, and see what happens. The whitespace error warning can be safely ignored, as it builds and compiles on my system with no problem from whitespace.

ran the script and it applied everything, and built properly. Devel and Staging are not updated, so it built the same version i have installed which is Wine 3.5 (Staging). When the devel and staging repos get updated, the version numbers include the first few characters from the commit number. I am not sure why it works on fedora, but not on your dsitro, what are you using? Fedora 27, kernel 4.15.13-300.fc27.x86_64

good luck

I am on Ubuntu 16.04 4.14.06

I first built the wine source 3.5 from git repository, with ./configure , then make, then make install. Then I tried to to 'make uninstall', then 'make clean'. Something went wrong I don't remember what. Then I simply deleted folder, and cloned again, following your steps carefully.

You run, as listed, with nothing added. Do not configure 3.5 devel or do anything other than let it download all the git repos and apply the staging and pba patches. copy and paste those instructions into a script, start it, go have a coffee (or 3) and let it download and apply the patches. Once it is done, do the ../wine/configure --enable-win64, from the wine64-build directory (you need to mkdir wine64-build in the same directory as the repos are downloaded). after configure finishes, do make to compile and sudo make install to install it. If you have a wine from your distro repo on your system, uninstall it, before you do all of this, so you do not end up with cross versions of wine in place.if you also want a 32 bit version, for other windows programs, then by all means look to the wine wiki about building wow64 (which is windows on windows 64) and follow the instructions there. I can also make a script for you, to take it from start to finish, if you are uncomfortable doing it yourself.

I don't know what the problem was. I have just updated my kernel version to 4.16 now, deleted the git repos, and started all over again, and seems to be working now. Don't know what I did wrong :)

But I am curious about how you symlinked to your windows10 partition. I am also dual-booting with win10, and currently WoW is installed on both partitions.

I have two ssd disks. One running ext4 and the other ntfs for windows. I don't know where to start, can you throw a link or something where I can read up on how to do this kind of sorcery? :)

Nevermind. It works nok after I have disabled the "Fast boot option" in Windows.

Shown here, is the build script I put together, on Fedora 27. This assumes the dependencies for wine are installed, and that you have GCC 7.31 and all the other necessary development tools.

rm -fr wine
rm -fr wine-staging
rm -fr wine-pba
git clone source.winehq.org/git/wine.git
git clone github.com/wine-staging/wine-staging.git
git clone github.com/goldpaw/wine-pba.git
#git clone github.com/SveSop/wine-pba-rebased.git
#git clone github.com/GloriousEggroll/wine-pba.git
#git clone -b 'patchset_for_devel_and_staging' 'github.com/Firerat/wine-pba.git'
cd wine-staging
./patches/patchinstall.sh DESTDIR="../wine" --all
cd ../wine
git apply ../wine-pba/patches/*

if all goes well, i compile the 64 bit only, in a wine64-build directory, using the command shown here.

../wine/configure CFLAGS='-march=bdver2 -mtune=bdver2 -O3 -fPIC -fomit-frame-pointer -pipe -DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS' --enable-win64 && make -j24

Pay close attention to march and mtune as they are specific to my amd processor. You MUST change them so they match your processor. Using -j24 on my system lowers compile time to less than 6 minutes.

System:
Host: linuxbox-desktop Kernel: 4.15.13-300.fc27.x86_64 x86_64 bits: 64 gcc: 7.3.1
Desktop: Cinnamon 3.6.7 (Gtk 3.22.26) dm: lightdm
Distro: Fedora release 27 (Twenty Seven)
Machine: Device: desktop Mobo: ASUSTeK model: M5A97 LE R2.0 v: Rev 1.xx serial: N/A
BIOS: American Megatrends v: 2701 date: 03/24/2016
CPU: 6 core AMD FX-6300 Six-Core (-MCP-)
arch: Bulldozer rev.0 cache: 12288 KB

flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 43345
clock speeds: min/max: 1400/3600 MHz 1: 3808 MHz 2: 3806 MHz 3: 3808 MHz 4: 3812 MHz 5: 3804 MHz 6: 3776 MHz

Graphics: Card: NVIDIA GM204 [GeForce GTX 970]
bus-ID: 01:00.0 chip-ID: 10de:13c2
Display Server: x11 (X.org 119.6 ) driver: nvidia
Resolution: 1680x1050@59.88hz
OpenGL: renderer: GeForce GTX 970/PCIe/SSE2
version: 4.6.0 NVIDIA 390.48 Direct Render: Yes

WoW in wine 3.5 with PBA and staging, FPS in Vanilla on taxi test can hit over 300, with game settings at 7 and WoW is symlinked from my windows 10 partition, so I did not have to copy it over and use up more space.

Following your exact steps on ubuntu. I get the following errors when I do $ git apply ../wine-pba/patches/*


../wine-pba/patches/0001-wined3d.patch:87: trailing whitespace.

../wine-pba/patches/0001-wined3d.patch:1241: trailing whitespace.

../wine-pba/patches/0001-wined3d.patch:1522: trailing whitespace.

error: patch failed: dlls/wined3d/buffer.c:28
error: dlls/wined3d/buffer.c: patch does not apply
error: dlls/wined3d/buffer_heap.c: already exists in working directory
error: patch failed: dlls/wined3d/context.c:4956
error: dlls/wined3d/context.c: patch does not apply
error: patch failed: dlls/wined3d/cs.c:73
error: dlls/wined3d/cs.c: patch does not apply
error: patch failed: dlls/wined3d/device.c:840
error: dlls/wined3d/device.c: patch does not apply
error: patch failed: dlls/wined3d/directx.c:111
error: dlls/wined3d/directx.c: patch does not apply
error: patch failed: dlls/wined3d/Makefile.in:6
error: dlls/wined3d/Makefile.in: patch does not apply
error: patch failed: dlls/wined3d/resource.c:340
error: dlls/wined3d/resource.c: patch does not apply
error: patch failed: dlls/wined3d/state.c:4797
error: dlls/wined3d/state.c: patch does not apply
error: patch failed: dlls/wined3d/texture.c:2096
error: dlls/wined3d/texture.c: patch does not apply
error: patch failed: dlls/wined3d/utils.c:6321
error: dlls/wined3d/utils.c: patch does not apply
error: patch failed: dlls/wined3d/wined3d_gl.h:44
error: dlls/wined3d/wined3d_gl.h: patch does not apply
error: patch failed: dlls/wined3d/wined3d_private.h:75
error: dlls/wined3d/wined3d_private.h: patch does not apply

Can someone help a noob?

Steve,

Thanks for the info.

I'm using Fedora 27 and latest nvidia driver. Have followed your post and have Wow-64.exe symlinked from a W10 mounted drive. The game launches but when I try to log in I get the error message "You have been disconnected. (BLZ51900007).

Any tips would be greatly appreciated :).

Check your firewall, per the blizzard post, searching the tech support forum for that error code.

Hi Steve,

I've done some Blizz forum browsing but am none the wiser really. I've just spotted the following error when running Wow-64.exe

0009:err:secur32:SECUR32_initSchannelSP TLS library not found, SSL connections will fail

Not sure if it's related but I currently have gnutls-3.5.18-2.fc27.x86_64 installed?

TIA

After spending all day on this, I finally got it working. I was missing gnutls-devel, didn't realise I hadn't got sound either, alsa-lib-devel fixed that too.


Cheers!

I installed lutris and they have allready pba with the installer . Could not be any easier . But i agree. Wine-pba is the thing !

WOW!!! (no not the game, enthusiastic endorsement)

Fedora 26, AMD 8350 8 core, 16 Gig ram, Nvidia 970GTX 390.25 (4 Gig ddr5)


In wine staging 2.9x I was seeing (with all the tweaks and tuning) about 20 to 32 FPS on average throughout Broken Isles and Argus.
In wine staging 3.3 I was seeing (after removing a couple of tweaks and adding a couple of others) 12 to 18 FPS on average in Broken Isles and Argus.

(Pretty much anywhere else in Wow was only ever 2 or 5 FPS better)

With self built wine 3.3 + staging patches + pba patches...... Holy CRAP!!!
Ran a full run with my main in Argus doing *all* the dailies = 48 to 65 FPS on average, with post zoning taking about 35 to 50 seconds to clear (I've the long zoning fix in Config.wtf) - on entering a zone I'm seeing 8 to 25 FPS, but about one minute after the zone load is done and I'm back up to 35 in *really busy* areas and from 60 up in quiet areas.

pulled wine 3.3 stable
pulled staging patches
pulled pba
unpacked 3.3 stable, used the patch apply script in staging, manually patched the pba patches - all good.
built the patched wine following Shared WoW64 options and with bugger all compiler tweaks. - Installed (in /opt/wine-staging-pba using the prefix= configure option)

I'm stunned .... I've not seen framerates like this since Blizz killed off openGL support - YAY!!!!


-- So -- zoning into Dalaran (new) I'm getting 32 to 45 FPS after the zone load is completed, 8 to 15 when I land. I do get "hiccups" in response while on the landing spot - and for the first 30 to 50 seconds in any new zone. I' was in a cave in Argus (the one with all the imps and imp mothers) and while running back down the fel cascade had a couple of screen tearing events. Other than that I see no issues with this bundle - I did watch memory usage, and it rose continuously to 3.8Gb for the Wow process and 1.3Gb for the wineserver process (over almost 90 minutes), but that was the cap.

One point, if you build all this yourself, you need to get the wine-gecko msi packs and put them in /path/to/wine/share/wine/gecko in order for the battle net client to work.

I have just removed wine, updated Lutris with the 3.3-pba as default and clicked into battle.net (after winecfg setting CSMT on of course) which loaded fine, better than wine has for a while actually.

However, when I launch World of Warcraft I get the old game initialization failed error and the mouse cursor then defaults and sticks to the top left corner of my screen. I can zoom out and close down the world of warcraft window OK to put that right again though.

Any ideas? I thought that having CSMT enabled got rid of the initialization error.

CSMT is not the issue. you need the staging version 3.3 pba because the drm blizzard uses to protect against cheaters, is not implemented in 3.3 stable, only in 3.3 staging. WoW players have no choice but to use staging, since wine will not mainline the patches needed to get the drm content protection problem solved.

CSMT is simply to try to get more speed from the video driver, but with the pba patch, I personally do not see that much of a change in FPS. I am very pleased with pba and the FPS is almost triple what I had in 2.18 staging.

I'm not seeing a staging-3.3 with pba or is the staging version already containing pba as standard?

Just to add, I have just switched versions to staging 3.3 - removed the .wine directory and then tried again - same issue.

Clearly it's just me doing something wrong here but worth having a mention of in case anybody else is being hit by the same thing.

I have no dll overrides, using windows 7 as standard, set to DX11 windowed. battle.net opens, the wow launcher opens but the game just won't go past the play screen

Just a quick thought godson, I just create a shortcut to the wow-64.exe file and bypass battlenet completely, perhaps you could give that a go. Lutris allows for making shortcuts to exe files and can switch between different wine versions on demand.

3.3-pba patches apply fine on wine-staging patched wine-3.3.

So the correct order of things would be: download wine-3.3 -> download & patch wine-staging-3.3 -> patch wine-staging-3.3 with pba patches. -> compile.

Recommend running wow either from a script or from Lutris as a "standalone" .exe rather than try to run it from the battle.net launcher...

What's pba?

Warcraft works out of the box with 3.3 staging. No dll overrides, no additonal components. Have you tried launching WoW without the cursed launcher?

wine '/${YOUR FULL PATH}/Games/World of Warcraft/Wow-64.exe' -dx11

Performance as good as it's been since Blizzard's DRM updates to their client.

Oh yeah I forgot to link...repos.wine-staging.com/alesliehughes/

A quick update.

I got tied up in knots with this but thankfully got a result in the end.

Firstly I removed everything and started again, tried to install battle.net using the Lutris install link - it installed but errored - I believe this perhaps was an Nvidia driver issue though as going back to 3.84 again made it work.
I then installed WoW from the Lutris installer and again errored at couldn't install Battle.net, then wouldn't load because it couldn't find battle.net.
To get around this I copied the battle.net install directory across to the program files x86 directory in World of Warcraft.

Net result is MUCH smoother gameplay, occasional FPS drops randomly but where I would only get 15-30 FPS before I am seeing 60fps pretty stable now and drops to 20-22 for a second or so every now and again.

I'm guessing I need to start this again as my setup won't now launch using a standard staging-3.3 runner. It's starts but then quits somewhere before launching.

I did manage to load up the game yesterday for a short while but the fps for me was much lower than 2.21. Clearly something has gone amiss so I will try again on a fresh install of Lutris and see if that clears issues up.

For those that don't want compile Wine yourself, and just can't wait till there are WineHQ staging packages for 3.3+, let alone Wine-PBA. Just pointing out that there are precompiled builds available in Lutris for testing Wine-PBA with. There is staging-3.3, and pba-3.3, and a pba-2.21. I also updated the installer for World of Warcraft on Lutris.net, it uses pba-3.3, and enables staging CSMT so it can work. It disables errors, so the .exe errors that Blizzard App throws are a thing of the past. The installer script also disables "GL_ARB_vertex_buffer_object2", it seems to not change fps anymore, but turning the camera still feels slightly better like this.

Here is a direct link: lutris.net/games/world-of-warcraft/

Enjoy,

Dox

Mighty impressed with how the PBA-version is performing. Using it with Lutris.

Here's a screenshot from Stormwind with the settings I use. FPS counter at the bottom:
www.dropbox.com/s/0ujxvmuosjtrzpn/wowsettings.png?dl=0

Stormwind has of course been more crowded than this from time to time, but consider me impressed anyhow.
Outside the big cities, it's basically 60fps all the time, except the Legion areas, which drops to 30-40.

CSMT enabled
Nvidia 1070 with 390.25 driver.

Tested the PBA 3.3 build with my AMD 280x and mesa drivers on ARCH. Framerate is more than double that of standard staging. Very nice indeed. Having a strange issue though where FPS chokes by around 50% for several seconds every minute or so. Not sure whether it is an addon or something in the system that is causing this, will experiment more and post back.

Thanks for this build Dox.

What fixes are applied that the battlenet app works? I'm using wine staging 3.3
With the PBA patches and the client crashes. Have you an idea why exactly?

Also there are the shader cache patches that are sadly no longer compatible with wine 3.3

Blizzard App doesn't crash for me. The only thing that is crashing is SystemSurvey.exe / Battle.net Helper.exe. I snubbed those errors with nocrashdialogs, but that exposed another bug with Winedebug / Process monitor in linux that will be fixed in next release.

Also there seem to be some issues now with the Blizzard App in general that it crashes when you click anywhere in the "browser" window. No clue about that, happens from Staging 2.18 to 3.3.

I have no clue what shader cache patches, but if you talk about the one in Staging that wasn't accepted, it is inferior to the Nvidia / mesa solution, except for perhaps very specific cases.

Only "shader cache patch" i have read anything about would be this: dev.wine-staging.com/patches/submission/247/ (and i guess thats the one Dox is mentioning?)

Other than that, i can recommend using a own cache folder for wow... atleast if you play more than just 1 game, as the nVidia cache have somewhat of a limitation when it comes to size, and it will start to overwrite itself and cause stuttering the next time you start the game.

export __GL_SHADER_DISK_CACHE_PATH=/home/yourname/.nv/WoW

The default is just $HOME/.nv , and if you play different games or use different GL applications, nVidia driver will start overwriting when it gets "full". Having a separate folder for WoW alone, will lessen the chance of overwriting from running other games/graphical apps.

HOWEVER, if you change wine-versions, or upgrade drivers++ this will cause nVidia to generate the cache again most likely.

The WoW "Cache" folder in your install directory also has loads of textures and stuff cached.. if you upgrade wine, or drivers this will also most likely be overwritten. Sometimes this can create errors and problems along the way, so i tend to clear out both my $HOME/.nv/WoW folder + wow_installed_folder/Cache folder each time i do a wine upgrade (ie. switching from wine-staging-pba-3.2 -> wine-staging-pba-3.3). Bare in mind that it will take quite a while playing to get "everything" cached.. So the first time entering a zone/raid/instance after doing this, it will stutter...

You can use as many __GL_SHADER_DISK_CACHE_PATH's you like (and i guess place them wherever your user has write access).

The NVidia cache will make a different cache when you switch driver / wine version. The old cache will (eventually) be garbagecollected, so no need to clean them by hand. Setting a cache dir / game is still good, I set this in the Lutris installers. It only has 256mb max, and sharing it with multiple games is just bad.

The WoW cache folder I clear when there is a WoW patch (sometimes). This can fix some errors sometimes. But I definitely do not do this on a Wine version / Nvidia version switch.

As ppl have seen and tested themselves, there seem to be somewhat of a problem getting a replicable benchmark or test of fps in wow. Some stand with their nose in the corner and compare different stuff, but all it takes is some random spelleffect or whatever going off on someplace to make a impact on that. I have tried the /timetest 1 test of various places, but even tho i am able to produce a fairly similar result, it DO have a variance that makes changes hard to spot.

Having low fps to start with, 2-3-4 fps change from a average of 40, is up to 10%. That is actually a LOT. If a new driver comes along that gives ppl 10% increase in 3DMark, the "gamers" go wild... Having "bad luck" while doing a /timetest 1 run in wow can easily be up towards that.. so in reality, doing benchmarks in wow is not a reliable method... atleast not for comparing minor changes. Sure it is easy when you do a run and get 20-24 fps, and with another setting you get 40-45 fps.. cos thats a 100% increase... But doing a tweak that normally would just get you 1-2 fps, there is no way to measure this reliable in wow.

So why is this?

I have a theory about this tho.. but more than welcome other ideas or methods to tests. My theory is basically this:
We know wow (or any kind of mmo) rely on syncronizing data between client server.. and this seeing something move or a spell cast would mean You -> server -> other person -> server -> you. So how does this work? What if the "other person" is on a crappy dialup or whatever with 500ms? Well.. the server i guess does loads of things to compensate this, but this WILL sometimes mean the server stops stuff happening to catch up. Now in theory this should perhaps not have anything to say on how well your local machine renders its graphics.. you should still be able to have 200+fps, even if you wait on data from others.. right?

Well.. i dont think so. There are numerous examples of mmo's with sub-par graphics that are really laggy.. So there HAS to be something more to it than just "local client" and "random data", and i do believe that any mmo depends on traffic and server load more than just client. One such example i guess we have all experienced playing wow.. the "OMGZ LAGGZZZ" sometimes happening.. sometimes this wont hamper your fps, but other times everything just goes crashing down... aswell as horrible ping to the server makes for poor fps ingame. There is a correlation there :)

Now, thats well and fine, cos most of you guys already knew this... but what wow does that not many (or any?) other mmo's do, is that they do not have a "single zone server".. there are many, and you get bounced back and forth between them.. Dont remember when this happened exactly, but it was around the time where cross-realm stuff and zone scaling and all that stuff started happening. Where if you are at a different point in a quest chain or a different level, you cant even see ppl in your group until you are at the same spot in the chain. This means that when i log on, i can be online on server #124 of the zone Dalaran, while my pal "joe" can be online in Dalaran at the same time, but on server #89.. and basically we are NOT on the same server, and cant even see eachother... until we group, and we both get put on server #43...

In other words.. there are not two times you log on, where you are on the same server. If one server is having more load/latency/ping = less fps, thus rendering our last benchmark run invalid. I use "server" here as the actual hardware running the zone, and not your "realm".. just to be clear. Think of it like when you log on to facebook.com. Its not 1 server feeding the "world", although from the users perspective you are on 1 server :) Blizzard HQ has several serverparks, all interconnected.

Loads of text.. probably mostly jibberish.. but atleast a theory of why you can log on, test something, log off, change NOTHING, and come back to a slightly different testresult.

Only way imo to test graphics performance in wow would either a: get a offline benchmark client with the graphics engine, or b: set up your own private server.

Thoughts?

My first thought is that a public, dedicated winehq benchmarking server for WoW is a great idea, if you could find a way to pull it off without the inevitable law suit.

There is some private servers around, but not really sure how "safe" they are to join regarding blizzard being swift in dropping the ban-hammer on stuff like that.

I would prefer to run something like that purely "in-house", so not to risk any troubles that way.

Why not use the builtin /timetest command? It locks your view angle, and disables all other players. It runs almost completly client side.

I would propose: Disable vsync, disable frame limiters, select 10 as detail level, rendering 100%, no antialias.

Stand at the flight master in Dalaran (Legion), enter /timetest 1 in the chat, choose Meredil as flight destination.

If you had read all i wrote (who can blame you if you didn't), i DO run /timetest 1... and the variance with /timetest 1 is sometimes up towards 2-3 fps (out of 40), so not 10%, but more than enough to kinda render the comparison somewhat invalid.

It does not matter what flight path you take, cos the comparison in itself is not to benchmark my system against yours really.. its to test variances when changing wine versions and/or ingame settings and stuff like SET M2Faster "3" and minor tweaks, that could gain you 0.5, perhaps 1 fps. Minor.. but every fps counts, especially when you do not have too many :)

/timetest is the only way to compare builds. The longer the route the better. It should be in Legion. And I suggest it is a path that goes past / over Suramar City.

Any testing in raids will be purely subjective, but "gamer feeling" should be enough for that. It isn't perfect, but it is good enough.

We all know benchmarking WoW can be fraught with chaos. One of the biggest problems contributing to this is there's no agreed-upon methodology. Some people benchmark WoW by purposefully trying to find the location and camera orientation with the highest framerate, while some aim for the lowest. Others just guesstimate a range based on visual spot-checks of the FPS meter during regular play. Game content from different eras even performs wildly differently despite lack of significant differences in visual complexity.

It occurs to me that this is actually technically a very simple problem to solve. The hard part is just getting everyone to agree on the solution. So, I'd like to propose a simple WoW benchmark method that gives more predictable results, is easy to replicate, and focuses on performance bottlenecks rather than absurdly useless peak framerate scores generated with your nose stuck in the corner of a small room in an unpopulated zone.

The most important thing about this benchmark methodology is that we give it a name so that everyone who knows about it can agree on what it is and therefore how to do it. In order to distinguish this benchmarking method from other future benchmarks, we need to use a name with sufficient verbosity.

I propose we name this benchmark "The Horde Bank New Dalaran Benchmark" and it works as follows:

1) Go to to "new" Dalaran (no spoilers for those who don't know where that is!)
2) Go to the "Horde Bank" (the one nearest to Windrunner's Sanctuary)
3) Position your character at the middle of the lowest step of the bank's stairs, at the point in the very center
4) Zoom the camera in as far as you can while still keeping your whole character visible above your primary ActionBars
5) Aim the camera towards The Violet Citadel so that, on screen, your character's head is positioned between the pillars at the foot of it's main staircase.
6) Mouse over the red "?" on the ActionBar to see the current framerate (brace yourself for disappointment if you had previously been under the illusion you get decent performance from WoW in wine)

Now, I know this is still not perfect, and the framerate can be affected by how crowded the street is, but it only seems to actually move it by a couple FPS.

(I'm getting 11 FPS right now using this method on Ultra settings with wine-staging 2.21.)

I like the idea, however a few things.

1. As you pointed out.. it CAN depend on how crowded the street is
2. Camera zoom "keep above primary actionbar" and stuff like that, works if you use the standard blizzard ui. I have a custom one, and im sure many have. Thus MY primary action bars MAY be in a totally different spot than yours. Zooming camera IN all the way will ofc negate that difference, cos you can only get IN max and look from a 1st person perspective.
3. Get the angle wrong = may change your fps by a lot.
4. Is there a "ultra" setting? There are many.. but the slider has numbers. It seems as the default usable setting in dx11 is "7", and some say this was what was max quality last expansion. Better to use that number.

Static fps viewing is imo not too useful for a "benchmark". The "timedemo 1" option in wow is created for a reason. I would rather propose a standarized benchmark consist of a set flight-path using timedemo 1. You will get listed min/max/avg fps that way. I did a whole lot of them a while back, and doing 3 of them, adding the numbers and dividing by 3, thus creating a "average" for those 3 runs.
Be aware that also there camera viewpoint would play a role, aswell as "looking around while flying", so the rules would be something like : Zoom IN to 1st person, do NOT move mouse/camera while flying.

There is a reason why benchmarks such as the Unigine ones, or 3dmark ones follow a set script each time they are run :)

Battle.net works fine now with version > XP, for example, I use it in my default WIndows 10 prefix.

Pet Battles also work I can confirm, I will let you know if they stop. ;D

MSAA produces a black screen regardless of setting - replicated (antiX-17 Linux Core)
CMAA produces edges on geometry that are visible through some 2D UI objects - I experienced this effect with Xfce 4 so it's apparently not DE related.

Keep us posted on how to with 3.x...staging is discontinued and frankly, World of Warcraft and Heroes of the Storm have appalling performance. Battle.net is so flaky, breathe and it crashes.

3.2 staging is crap. dark gamma, can't see character, and gamma adjustment in game has no effect. fps is lower than my 2.18 staging that I compiled with no debug symbols. I run 2.18 because it has higher fps than 2.21 even after I compile 2.21 with no debug symbols. Will he holding out for a few months, maybe 3.3 devel when it comes will address some of the issues, and move drm into mainline so we can run wow with wine stable, and not have to mess with staging.

Been hitting the git for wine devel and the forked wine staging. have a shell script that pulls fresh each time for wine devel and wine-staging. Todays pulls yielded a good patch, and complete compile. So far, fps is a little higher, than 2.18 and the only issue is the gamma seems darker, than the settings for the game when i run it in windows. My wow program is symlinked from the windows install, so I am not maintaining two copies. I boot windows to run twitch, tukui client update, and battle.net for patch updates. I still do mythic and heroic raids in windows, but that may change soon. if anyone is interested in the git script i use to clone and patch, I will be happy to post it here. I run fedora 27, gcc 7.3.1 to compile, and cflags set for my processor. I only build the wine64, then symlink to wine, so that winecfg runs. I used a library override to completely disable wined3d-csmt and that seemed to help performance. I will update this comment, as I tinker with the staging and devel code over the next few days.

Sounds got, however I hope that your copy isn't on a NTFS partition.
I do raids with wine but heroic and mythic.
Except the ground texture issue it works fine.
You may look at github.com/acomminos/wine-pba.

PS: I hope you package wine proper, If you do this you dont need symlinks.

"Except the ground texture issue it works fine."
Seems like you run with DX9 then? No problem, until they (blizzard) kill that option completely tho :)

Yes I know its a ticking time bomb.

wine is not on ntfs, but windows is, so the symlink to wow is hosted on ntfs. I do not plan to package, since I compile for my specific processor, but if someone wants the patched code, to use to compile, I will archive it, and share it. The gamma is broken in this version, everything is very dark, and the adjustment in game is not honored. No matter how far I move the slider, the game is not changed. tried setting gamma on my desktop to a higher value, and wine reset it to the darker setting. so, long story short, wine 3.2 staging is not honoring gamma settings, and is overriding apparently. I will post an issue on the staging git repo, so they know, if they don't already.

Nice!
Havent payed much attention to the staging git of late (been busy fiddling with dxvk hehe). Patched and compiling as we speak :)

does dxvk works now?

Not for World Of Warcraft.
WoW requires DX 10.1 in DX11 mode, so DXVK has nothing to offer.

Yeah:
err: DxgiAdapter::CheckInterfaceSupport: No D3D10 support

Might change with wow 8.0 (or whatever Battle of Azeroth will be versioned) when they get rid of d3d9 completely, and possibly rewrite something tho...

BFA Alpha is 8.0.1. Every Expansion increases the major version by 1

comminos.com/posts/2018-02-21-wined3d-profiling.html

I'm using the patches now, DX11 doesn't work yet, but DX9 does. You have to start WoW directly and bypassing Blizzard App because of this. Using "-d3d9" as command line argument.

DX9 on Staging 2.21 runs faster then DX9 on my WoW2.0 branch:

Staging 2.21 DX11: 42 fps (CSMT disabled since it lowers fps)
Staging 3.2 DX11: 18 fps (CSMT disabled since it lowered fps)

Staging 2.21 DX9: 48 fps (CSMT disabled since it lowers fps)
Staging 2.0 DX9: 82 fps (CSMT enabled)

Staging 2.21 PBA / DX9: 90 fps (CSMT enabled)

DX11 support is incoming in the coming days.

Thanks for the link
I really need something like this because that bottleneck hits me really hard compared to the power of my GPU (1080ti).
Maybe this makes 4k better playable.

I'll keep a lookout for this when DX11 support is added. I'm not sure why but my fps has taken a step backward recently and I couldn't realistically raid as it was before so now is very laggy. 24fps in Dalaran bank area with 30-50fps in other places is terrible.

Did some benchmarks with Unigine Valley and csmt/nvidia threaded optimizations.

Used wine-git with wine-staging-git
Wine-Staging thread compare - Valley:
csmt=1, threaded=1 - 77.2 fps
csmt=0, threaded=1 - 63.4 fps
csmt=1, threaded=0 - 70.7 fps
csmt=0, threaded=0 - 54.7 fps

wine-vulkan-3.2 w/dxvk
dxvk does not use csmt from wined3d, nor do "GL" conversion, so GL_THREADED_OPTIMIZATION had no impact (i did test, but same fps +/- 0.1 fps within margin of error)
csmt=N, threaded=N - 82.5 fps

dxvk do have some issues with reflection/lighting with my GTX970 tho, so not "perfect" atm.

Did some testing today with wine-staging-3.3 and comparing it to wine-staging-2.18.
Test was to fly from Felblaze Ingress Crimson Thicket, so that you fly by the edge of Suramar city. I zoomed the camera full in (1st person), and did not move anything while doing /timetest 1. To make sure textures and shaders were loaded and cached, i flew back and forth before doing the timetest.

Results are: min/max/average

Felblaze Ingress -> Crimson Thicket

wine-staging-2.18
csmt=1, gl_thread=1 - 24.5/68.5/44.4
csmt=1, gl_thread=0 - 20.6/58.9/36.8
csmt=0, gl_thread=1 - 26.6/66.7/43.1
csmt=0, gl_thread=0 - 15.8/49.0/29.5

wine-staging-3.3
csmt=1, gl_thread=1 - 14.8/35.9/22.0
csmt=1, gl_thread=0 - 19.8/51.3/31.8
csmt=0, gl_thread=1 - 14.6/35.1/21.8
csmt=0, gl_thread=0 - 16.2/50.4/30.7

Crimson Thicket -> Felblaze Ingress

wine-staging-2.18
csmt=1, gl_thread=1 - 21.7/56.9/42.6
csmt=1, gl_thread=0 - 19.6/45.6/34.1
csmt=0, gl_thread=1 - 24.3/54.9/40.7
csmt=0, gl_thread=0 - 15.7/36.4/27.0

wine-staging-3.3
csmt=1, gl_thread=1 - 13.9/27.7/20.5
csmt=1, gl_thread=0 - 17.0/40.0/27.2
csmt=0, gl_thread=1 - 14.3/27.5/20.4
csmt=0, gl_thread=0 - 8.2/38.3/26.4

It seems as __GL_THREADED_OPTIMIZATIONS= has a negative impact on the wine-3.3 source for some reason and csmt having less impact on 3.3 than 2.18. If this has to do with me using a custom kernel with PDS cpu scheduler or not, i dont know.

What seems clear is that there is a rather big degradation in performance using 3.3 at this time. It will be fun to see what can come of this PBA patching tho, as i think DXVK is further from working with wow than PBA mostly due to wow depending on non-supported DX10. DX10 also being a thing not really well supported with wine in general i guess...

I'll pop up a new thread regarding my theories around wow benchmarking and timetest.

If you say 3.3 vs 2.21 is a big loss of performance, you shouldn't go to pba or dxvk or whatever else there is on modifications.
Instead, figure out the patch that introduced the regression in vanilla wine.

Well.. tbh that statement does not really make any sense, cos regression testing in World of Warcraft requires staging... thus only recently it has been possible to test staging (still not "done").

So.. you want to dig through several hundreds of patches to figure out which one created slower D3D11 performance from 2.21 -> 3.2? I would not think it is a "1 patch deal" either :)

Saw the same when "correctness" was done for 2.x with csmt. 2.0 DX9 performed massively better than 2.1 with its new csmt. 3.x i guess introduces several more changes, even tho it halves performance. WineHQ devs i guess do not optimize code for performance, atleast not at this stage.

I forgot about the hidden Import patches of staging. That doesn't mean that the process changes though. Regression testing usually means bisecting. You apply half the patches amd see if the problem persists. Depending on the result you either test the other half or you continue with the ones you tried before and half again.
Takes time but you don't have to try all permutations for a few hundred patches

Sure. I know how to do that... its just sifting through all the patches that depend on eachother... For all i know it could be 5 rebases ago on 1 patch that made some problems... and that patch depends on the 12 or so other patches in the patchset (when it comes to staging patches atleast).

You are more than welcome to do that, and just tell me and others what patch makes this slowdown, but I wont spend countless hours trying to reverse-patch wine-staging-3.3 back to wine-staging-2.21 to figure that out :)

Oh my! Just done compiling the todays update of 3.3 patches.

Ran Unigine Valley benchmark DX11:

wine-staging-2.18:
78.6 fps (3290)

wine-staging-3.3:
77.0 fps (3222)

wine-pba-3.3:
92.5 fps (3872)

Native OpenGL:
85.1 fps (3558)

wine-pba-3.3 BEATS native Linux OpenGL performance! Wow... (not as in World of Warcraft... but WOW! ) Now we are cooking! :)

Where is Wine-pba and how can I get it, to test on Fedora 27?

github.com/acomminos/wine-pba

Downloads 4 patches. Patch with : patch -p1 < 0001...... and so on for the 4 patches. Works with wine-staging-3.3 : github.com/wine-staging/wine-staging/releases

ok, let me see if I understand.
git clone wine 3.3 from winehq devel source
git clone wine 3.3 staging
apply staging patches to wine
git clone wine pba
apply pba patches to wine
configure --enable-win64
make
install

is that the correct order?

Not atm, cos winehq git is further along than 3.3 in terms of commits, and even tho the "new" staging team is pretty fast at updating staging to new wine-git commits, its not always 100% i guess.

So to make sure its working, you should download the 3.3 RELEASE source from: www.winehq.org/announce/3.3
Then download the wine-staging-release from: github.com/wine-staging/wine-staging/releases
Then follow what you write from pba clone :)

Tbh, i would not configure wine as a systemwide option, but rather (especially when using experimental code) use a installprefix and then use that to run wine. Easiest option to switch wine versions would be something like Lutris or Playonlinux.... but can do that via a script aswell. I posted a usable script you can adapt to your needs here: forum.winehq.org/viewtopic.php?f=8&t=30176 (Adapt this ofc to wow)

wine should then be configured with:
./configure --enable-win64 --prefix=/home/steve/wine-staging-pba-3.3

Replace ofc "steve" with whatever username your user have.. and by all means, call "wine-staging-pba-3.3" what you want.. The point being that your install would then be in that folder... and you can reference that as you see fit, instead of doing a system wide install incase things break and you need wine for some other program :)

You can use tags.
From my history:

git clone source.winehq.org/git/wine.git
cd wine
git checkout tags/wine-3.3
cd ..
git clone github.com/wine-staging/wine-staging.git
cd wine-staging
git checkout tags/v3.3
cd patches
./patchinstall.sh DESTDIR=../../wine --all
patch -p1 < ../wine-pba/patches/0001-wined3d-Initial-implementation-of-a-persistent-mappe.patch
patch -p1 < ../wine-pba/patches/0002-wined3d-Add-support-for-backing-dynamic-wined3d_buff.patch
patch -p1 < ../wine-pba/patches/0003-wined3d-Use-ARB_multi_bind-to-speed-up-UBO-updates.patch
cd ..
cd ..
mkdir wine32-build
mkdir wine64-build
export CFLAGS="-O3 march=native"
cd wine64-build
../wine/configure --enable-win64 && make -j16
cd ../wine32-build
../wine/configure --with-wine64=../wine64-build/ && make -j16

I have only looked at it for a short time and it seems fast, but I haven't done any measurements.

It is a lot faster in wow.. thats for sure.. not only by quick numbers, but general feel aswell. Not tested it in raids and stuff other than weekly portal boss crap, but not dipping down in around 20'ish was just awesome :)

Compared from my earlier bencies, i did timetest 1 from Felblaze Ingress Crimson Thicket.
wine-staging-2.18
Felblaze -> Crimson: 44.4 avg fps
Crimson -> Felblaze: 42.6 avg fps

wine-staging-pba-3.3
Felblaze -> Crimson: 73 avg fps
Crimson -> Felblaze: 68.3 avg fps

Huge increase.

Btw. Any reason you don't patch:
0004-wined3d-Use-GL_CLIENT_STORAGE_BIT-for-persistent-map.patch
0005-wined3d-Experimental-support-for-persistent-buffer-t.patch

0005 i guess is mostly trying to fix overwatch.. so i guess its not needed for wow... Question should perhaps be: Does it hurt? :)

No, only the two last patches didn't exist when I cloned wine-pba a week ago.

Suddenly I can only start Wow with -d3d9. When I get in game and try to change to DirectX11 from ingame options, the graphics API dropdown only has DirectX9 as an option.

When I try to start with -d3d11 - the game wont start. It crashes instantly with the error message: World of Warcraft was unable to start up 3D acceleration

I have tried repairing game files. Deleting cache WTF and interface folders. Reinstalled wine. Tried different wine versions., 2.18 staging and 2.21 staging.

-d3d9 works fine, but no go with -d3d11

double check, see if glsl got disabled.

It is enabled. Still stuck with the same problem

got the same problem. GLSL is enabled for me in the registry, but when I start the game I get
wined3d_dll_init The GLSL shader backend has been disabled
so I take enabling it that way is not the full deal..

I might have figured out what was wrong on my side. Apparently, my wine prefix was either too old or there was some broken config around there somewhere. A new prefix allowed me to switch to d3d11 (but I had to do that ingame and then restart, due to my config). Did you try that already?

I just launched WoW back up for the first time in about a year. I used to get much better FPS than I do now on worse hardware.

I've been trying various things and made some interesting discoveries:

1. Going from "Windows 7" to "Windows 10" in winecfg nearly doubles the framerate

2. Surprisingly, setting __GL_THREADED_OPTIMIZATIONS=0 instead of =1 gives a 50% performance increase (and I'm not a 32 thread CPU so I'd expect it to have helped!)

3. Setting __GL_YIELD=NOTHING grants about ~5% fps improvement over __GL_YIELD= and about 10% over __GL_YIELD=USLEEP

4. Couldn't test FBO vs Backbuffer, Backbuffer causes odd graphics on the character select screen and I couldn't get past the loading screen

5. mesa_glthread=true had no effect (didn't expect it to on the nvidia driver but was worth a try)

6. Most in-game settings made little to no difference. The only one that had any noticeable effect on performance was view distance.

YMMV and obviously GPU vendor/driver will have an effect. But doing those two things took me from 15fps to 43 on a Threadripper 1950x/980ti with nvidia 390.25 driver at 3840x2160. These drivers alone gave me worse performance than earlier ones, there's a detailed thread over at nvidia devtalk.

Are these settings in your Config.wtf as they seem to be missing from mine? Are you running in -DX11 mode?

Yes, I'm using DX11. Setting "Windows 10" is obviously done via winecfg. The others are OpenGL settings you can set on the command line before running wine. e.g.


__GL_THREADED_OPTIMIZATIONS=0 __GL_YIELD=NOTHING wine Wow-64.exe

The results will probably be completely different if you're not using nvidia but I was surprised that __GL_THREADED_OPTIMIZATIONS=1 gave a performance hit.

I have experimented a lot with different settings, and have not noticed ANY change between Windows 7 and Windows 10 setting in winecfg. (GTX 970 w/390.25 - wine-staging-2.18)

Not really tested that much with __GL_YIELD, but some performance may be gained perhaps. I use a 4.15 kernel with PDS cpu scheduler, and i have a wild immagination that the "yield" part does not have that much to say.. Dunno.
I get better performance with __GL_THREADED_OPTIMIZATIONS=1, but i do not use a Threadripper, so could be something there too. :)

FPS in WoW is kinda impossible to meassure tho, but i guess if you were able to stand at a totally deserted place, or to a "taxi" benchmark from a non-populated place it can be used. I have several spots in dalaran i have 80+ fps, but in the middle of the landingspot on a busy saturday evening, its down to 25'ish... :) (WoW graphics settings to "7")

Still worth a test for those who want tho :)

I did find some performance increase with the config.wtf settings:
SET timingMethod "2"
SET worldPreloadNonCritical "0"
SET M2Faster "3"
SET timingModeOverride "2"

But as "per normal" in wow.. a "performance increase" is hovering around +/- 1'ish % for a setting. Unless you do something terribly wrong.. like setting WINEDEBUG=+all or something :P

Thanks, I'll try those. Definitely, changing winecfg doubled my FPS. No idea why but I was getting < 20, and after changing to windows 8.1 (or 10) got < 40. I can replicate this consistently, turning on `__GL_THREADED_OPTIMIZATIONS` lowers my FPS from ~45 - ~30. I tried it 4 times just to make sure. It's definitely slower with it turned on!

I've been having a lot of issues with the 390.25 driver as detailed here: devtalk.nvidia.com/default/topic/1029484/linux/-linux-mint-18-3-numerous-performance-amp-rendering-issues-on-390-25/2 so that might have something to do with it. I haven't tried WoW with an earlier driver, other games definitely worked better with the earlier driver, though.

I should have mentioned my methodology. I'm running at 4k, DX11 with mostly high settings. (View distance 7, seems to be the happy medium). I have an alt in Netherstorm which is practically devoid of other players, so I was just walking around one of the towns there.

Annoyingly, -opengl, which I was using a few years ago to play flawlessly, runs at a constant 60fps but has all sorts of texture corruption which makes it unplayable.

I'm very keen to see what happens when DXVK supports DX10 and we can use it with WoW. Might be the answer we're looking for.

Not sure why ppl are experiencing so different fps with/without __GL_THREADED_OPTIMIZATION, but might be a specific World of Warcraft problem with threads or something? Dont know. All types of benchmarks i have done in other apps show lower fps with CSMT disabled, and/or __GL_THREADED_OPTIMIZATION. One could/would think those two options together would work against eachother, but i cant really replicate that.

Could be graphics engine dependant perhaps. Not too many benchmarks that work too well on wine, so kinda hard to check. No benchmark using Warcraft engine either.

Benchmarking in WoW is kinda "impossible", cos a small variable makes a huge impact. I have tried to do "average" tests with looooooong flights and timedemo 1, and found very little difference.. when i tested. Ofc could be worth doing another round of tests tho. Changing settings like CSMT or other, and logging in to measure fps just by a "quick look" is kinda hard, cos if you are unlucky some random entity walks nearby and wham, those 2-3 fps you thought you gained... had nothing to do with it.

I have not really seen a 100% change (from 20 -> 40 fps) by ANY change in wine. Changing to windows 7, xp, 10.. no real change for me... but have not tried this with a clean prefix each time tho... so might be something there. I do have a old crappy cpu with DDR3 ram, so having GTX970 i guess i'm so cpu limited that nothing makes changes? Dunno... Get 25-30'ish fps in front of the "portal spot" in dalaran (where you land when you HS), but gets really close to 20 in a busy saturday. Several spots in Dala hits 70+ fps, and usually 40-60+ fps doing world quests... However if there are loads of ppl around, like when doing the portal weekly's i have dips in the low 20'ies when things are going on. DX11 wow gfx settings to "7" @1080p

Oh, and when it comes to wow in particular, even tho it theoretically supports multi-threading, it is more or less just two threads. Wine occupy more threads with CSMT, but even tho you see load on other threads it is not doing other than moving between threads so that looks like it is "real" multithreading. This means, especially for wow - core clock > threads. Ie. it is better with a 4.5GHz 4 core cpu, than a 3.5GHz 16 core. Wine does ofc not "help" this situation either... its kinda making the problem a tad worse.

The works pretty well on my LM 18.3 KDE, after 4-5 Weeks of playing i can say its all working fine, but i dont have tried any Battleground or Archaeology. The unreadable Problem with the Launcher i´ve solved with installing over the Synaptic Package Installer from my System, ttf-mscorefonts, after that this runs well, too.

BUT, one tiny but unbelieable annoying thing is the follow... sometimes i run my Game-Character with A-W-S-D, sometimes just with the Mouse, Left and Right Click, And the Movement Method with the Mouse stops running the Character often, i still have hold my Mouse Keys but the Chararcter stops running. I´ve already changed my Mouse with a other, a New one.
By solving this last Problem for me, i would give WOW on LM 18.3 Platinum State but this apparent tiny Problem is so annoying that i thing about a System Change back to Windows, but i dont want it, i hate the Stone-Age Systems from Microsoft.

Windows is a perfectly functional OS and for the beginner to intermediate user the right choice if your majority of usage is gaming.

(rant) Adding windows to a computer, adds between 90 to 150 dollars to the cost, so if a person wants to game, and has to spend money for an os to do that on, the cost of the os could hamper the budget that they set aside for gaming. I prefer to use a free os, that allows me complete privacy and better performance, than to fatten the wallet of bill gates any further than it already is. (rant over)

I dont agree with that, W2k was nice, XP different but good too, Win7 was ok, but the Support ends Early 2020. What you wanna use after Win7. Windows 10? Thats alot but not Perfect for the most Users. Thats no comparison to many Linux Distros. But this Thread isnt a Match between Windows and Linux. Just wanna comment what you´ve written.

Has anyone a Idea how i can solve my Mouse Problem as i´ve written?

lately i get a error , when i install in wine or even play on linux. I am on peppermint 8 and it did the same thing on ubuntu 17.04 as well. Anyone have a solution to help me out here. I would rather run linux than windows. Thank you in advance. I have set wine to XP for the launcher as well.

help us, help you, by telling us what the error is, and what you are doing when the error comes up. What kind of computer, video, and other information would help also. what version of wine, since wine 3.0 will not run wow at all right now, you need to be using wine staging.

i just changed it to wine staging and it is now installing, But it used to show the bottle when it started installing, but it is just sitting there spinning with the pinwheel on playonlinux? I am just going to let the whole game install and go from there. I can run wow on it with my windows side as well and it runs like a champ. i am trying to find where it shows my computer info on here but i switched from ubuntu to peppermint so just a few if i can find it so i can post. It still at this moment with the pinwheel on playonlinux but the game is installing.

glad it is installing. You have to run staging, as blizzard has drm protection, and wine stable 3.0 or wine development 3.1 will not work with that. I hope that wine staging gets caught up soon, I would love to see how Directx 11 does in wine, since blizzard is dropping directx 9 support.

You can run DX11 with 2.18+ wine-staging.

Oh, and the official "wine-staging" is dead.
www.wine-staging.com/news/2018-02-17-future-wine-staging.html

Now.. hopefully that does not mean wine will never have DRM support, or what is needed for games like World of Warcraft, but for now, there will not be a "quick fix" other than run existing wine-staging.

And as i said in my last post, DX11 works oki on wine-staging-2.18 in wow... and since i dont remember names or threads i answer here and there, DX9 in wow is bugged, and will NOT be fixed (missing ground effects) as DX9 will be gone come next expansion. My fear ofc would be that next expac - ie. World of Warcraft 8.0 - Battle for Azeroth some time in september, with changed graphics engine will be broken for wine-staging, and if wine-dev has not caught up, that sound you just heard was the fat lady singing...

Hmmm...that's our goose cooked.

I have now tried to use radeon kernel driver instead of amdgpu, and then I was able to run Unigine Valley with no problems. So I just tried starting wow with radeon, but I got the same problem with both d3d9 and d3d11. So yeah, this is getting more and more myesterious :D

Two days later the Error 132 vanished. Without changing anything.

On Ubuntu 16.04, Wine staging 2.20 with Oibaf gallium nine enabled. My game has been running wow smoothly for about a week. And now suddenly without making any changes to my computer, the computer freezes
1-5 seconds after I login to a character. I am running -d3d9 but I really don't know if I'm running 32 or 64bit, as the checkbox option simply disappeared from Battle.net app.

The whole computer freezes, I can move my mouse cursor, but I can't do any inputs and I'll have to hold my power button.

If I try d3d11, the computer freezes already at opening WoW. Same happens when I run "wine Wow.exe or Wow-64.exe".

I can create a new character and run around for about 5min, then computer freeze again.

The wine-staging for "gallium nine" is a special version if you are actually using that.

So, just to get the facts:
1. You are using a AMD card with Oibaf gallium nine (MESA) driver?
2. You are using wine-staging-nine 2.20?
3. You have not gotten a new kernel or gfx drivers of late?

There was a patch to the wow client when bringing the 7.3.5 version, where you would get a message about DX9 soon to be dropped. I have not tried with the dx9 option in quite a long while as it is bugged in missing some ground textures/effects that really fu**s you up in raids (standing in flames you cant see). So as of 7.3.5 i would say DX11 is the "only" way to play wow.
That and that they are dropping DX9 altogether the next patch + no longer supporting XP (This happened a while back tho).

Not the greatest of news tho, but wine-staging-2.20 (regular one) + "normal" AMD drivers should work. gallium-nine + wow at this point COULD be sketchy tbh.

But it worked smoothly yesterday. I have gotten the far best performance with Oibaf and gallium nine d3d9

Well.. rarely that a wine bug will hard-lock linux tho. It may seem like that, since it wont accept keystrokes i guess, but you say you can move the mousecursor?

What if you press CTRL-ALT-F1, will you get to terminal then? There you could do a "killall wineserver" and see if CTRL-ALT-F7 wakes up the desktop again.

Other tests might be if you run a openssh server or something, if you can connect in to the machine remotely and there do a "killall wineserver". If that does not work, nor CTRL-ALT-F1 or anything of that matter it might be some instability somewhere else.

Have you tested any native Linux gfx benchmarks to see if that is stable? Unigine Heaven/Valley/Superposition? Those tax the GPU rather well, and if you get a crash there aswell it could be a troublesome powersupply/hardware fault of some sort (if you are 100% sure no drivers/kernel/whatever has been updated).

Sometimes I can do CTRL ALT F1, sometimes not. When able to I will see black screen with two following lines:

[31.404401] [drm:dce_V8_0_afmt_setmode[amdgpu]] *ERROR* Couldn't read SADS: 0
[372.980820] [drm:dce_V8_0_afmt_setmode[amdgpu]] *ERROR* Couldn't read SADS: 0

But I am not able to type anything or go back to CTRL ALT F7 . Here the computer just freeze for good!

I have not tested any benchmarks, but I am able to play Heroes of The Storm on High graphics settings. And wow also runs perfectly on Windows 10, so no powersupply/hardware fault I think.

And I repeat I have played WoW on ubuntu for a whole week with no troubles at all. It just stopped working from one hour to another. I remember installing some Ethereum (crypto valuta) mining software, which I quickly uninstalled again, to make sure that didn't cause the problem for some reason.

Seems to indicate some sort of AMDGPU firmware problem perhaps. This would happen if :

A: You changed the kernel
B: You changed the drivers

Very strange that it would "suddenly happen" tho, unless some sort of update has happened.

As i said previously, it is very strange that wine would hard-lock your machine like that in itself. That you cannot switch to terminal and type commands indicates something has gone horribly wrong (as indicated by those drm: [amdgpu] lines. Without being any sort of expert, my honest oppinion is that your computer is crashing because of some underlying problem with the AMD drivers.

What Ubuntu version and kernel are you running? 4.15 kernel is brand spanking new with quite a lot of amdgpu fixes from what i gather (and possible bugs ofc). Seeing as you dont have those issues in windows, i agree that it would probably not indicate a hardware fault, but more likely a driver malfunction of sorts.

So now I have upgrade to kernel 4.15.1 and I really thought it fixed my issue. I was able to play for about 1 minute, until my computer decided to do a really mean freeze. This time I can not even move the mouse cursor. And also my wifi doesn't work with the new kernel, but I guess that's a story for another time.

After a reboot and another try, it froze just as I entered the world on my character, like before the kernel upgrade.

Think I will try out the 4.15.0 kernel later today. Btw thank you for all your help :)

You could also download one of the "Unigine" benchmarks. Both Unigine valley and heaven have dx9/dx11/opengl for the windows client, and opengl for the linux client.

When you start it, it just runs in a loop even if you dont do the "benchmark" thing, so the GPU is tested. Do that with the Linux version first.. if you hard crash there you know for sure its not wine related :)

If it runs for 10+ minutes without problems with the Linux native client, you install it under wine and do the same.. if that hard-crashes after 2 minutes like things do in wow.. i would try the non-nine version of wine to see if it is some bug there perhaps?
benchmark.unigine.com/valley

"Superposition" is the newest and are OpenGL/DX11, so it would probably not work at all with wine-staging-nine version in "directX mode" + that the gui is rather bugged under wine.

Alright, so the valley for linux just froze my computer during the load screen

I have now tried to use radeon kernel driver instead of amdgpu, and then I was able to run Unigine Valley with no problems. So I just tried starting wow with radeon, but I got the same problem with both d3d9 and d3d11. So yeah, this is getting more and more myesterious :D

Alright, wow is running now - after I uninstalled oibaf's gallium nine repository. But I'm really sad that gallium-nine was the problem, because it is the best soultion I have had for wow on linux. I was running with high graphics and a pretty good framerate. Now I am on 20-40 fps during raid encounters with lowest graphics, and that is just a little too low..

Welcome to the world of the rest of us :P

Atleast under DirectX11 you get to see ground flames/patches/whatever that is missing in DX9... safer for your fellow raiders to not have to battlerez you 3 times every bossfight :)

I'm using wine-staging-git (2.21.r0.g53290d2ec4-2) with an nvidia gpu and everything works ok.
The missing ground textures are workaroundable by moving with the grp or with the boss that you attacking.
Even Argus HC works without issues.

I find DX9 performance with newer wine than wine-staging-2.0.x to be horrible... atleast compared to wine-staging-2.0.x w/overwatch patches.

Its not WORSE than dx11, but its not really better either tbh. So, id rather run DX11 w/wine-staging-2.18, than DX9 with wine-staging-2.18 (or 2.20/21 for that matter). If it is very little to be gained by using dx9, id rather see the ground textures, even tho i probably should move around with the group anyway. Usually have 30-40'ish frames in raids, but with mass fights like the big weekly portal bosses where you have 40 ppl bombing the boss with spelleffects and whatnot, i do not have 40 fps. Seeing how ppl complain about the lag in the raidchat more or less leads me to believe that not EVERYONE of them are running wine either :D

wine-staging-git vs. wine-staging-2.21 "release" is the same. I (and others) have found wine-staging-2.18 to perform just a smidge better for wow 7.3.x in DX11 mode.

Yesterday 2/2-18 it seemed as Battle.net had a update... not sure if it came before, but i launch wow directly instead of through the battle.net client usually, so might be a couple of days old.

Anyway, a box now pops up with "survey.exe has crashed". Is this some sort of data collection thing from blizzard in the gearing up towards switching to DX12 and the new Battle for Azeroth expac?

Also a couple of weeks now my battle.net client window is more or less bonkers when it comes to wow.. cant do the "repair" function or stuff like that. (Screenshot: ibb.co/eizkOm )

So everyones battle.net app works without a hitch? No apparent bug with the menues or anything?

Tried to install in a fresh prefix with both staging and 3.0 and 3.1 wine.. same buggy window for me... hmm..

I think SystemSurvey.exe is a battle.net component. I don't see it with WoW (Wow-64.exe launched).

Battle.net is not a great place wine-wise at the moment.

Yeah, i figure it is some sort of data-collecting thing blizzard has going for planning the new DX12 client.. just to get a feel of where ppl are graphics/os-wise perhaps :)

That + battle.net generating loads of logs under your user profile regarding.. well.. loads of stuff.

1) Since wednesday patch, on Jan 30 2018, I regularly get Error 132 in battlegrounds. Found no solution yet.
Deleting WTF, Cache and Interface did not help. Repair option at launcher did not help. Using no addons anymore.

Because of that I tried DirectX 11. Error still is there.
2) DirectX 11 brings another problem: The whole 3D world is very dark including player names and their health bars. The game interface itself has normal brightness.
Perhaps the fglrx driver of ubuntu 14.04 is too old?

So I switched back to DirectX 9.

wine-staging 2.21
ubuntu 14.04 32bit
using fglrx-updates graphics driver
Radeon HD 6670

I'm using Arch and the same wine version, but with an NVIDIA GPU:
Name : wine-staging-git
Version : 2.21.r0.g53290d2ec4-2

maybe its an issue not specific too wine or to your GPU driver.

The Battle.net process stays in Background, even if I leave the Launcher by clicking [X] of the Launcher's window.
The Launcher's preferences have no effect on this.

So, after closing WoW, I always have to terminate the "Blizzard Battle.net" process in Task Manager.

wine-staging 2.20
ubuntu 14.04 32bit

You can also try to kill "Agent.exe".

Unlike later Blizzard games, like, for example, Heroes of the Storm, you can still launch WoW by pointing directly to the shortcut.

I would actually recommend this, if only for the agent.exe, Battle.net Helper.exe processes.

Frightfully so, you wont avoid agent.exe even by launching the wow-64.exe directly.

However, if you use a "pure" 64 bit wine (self compile with the --enable-win64 configure flag) it will just pop a couple of errors in your log about agent.exe being a "Bad EXE format".

I tested this and agent.exe did indeed kick in during authentication...and unloaded itself correctly after I had logged in.

Working 32 bit on 2.21-staging

Error on 64 bit 3.0rc6:
"game failed to initialize" when i try to start wow

the release candidate does not have the drm patch, that staging has, to make wow load.

I switched to wine 3.0 staging from the repo located at winehq, everything seems to work fine.

What repo? wine staging is still 2.21, do wine --version and post the results.

What happened to wine-staging? The latest version is 2.21 and the site hasn't been updated since 2.19.

I'm wrong , I have 2.21

Using wine 2.21, I can load the game using DX9 but with the warnings that the game will not run in future and to use DX11. If I change the DX version in config.wtf to DXD11 the game will no longer load and flags up a 3d graphics error instead.

This is on a 64bit version of wine.

you must enable glsl as dx11 requires it. then it will load.

Thanks, that's fixed it. I can't remember disabling glsl at any point but enabling it worked at least.

how do u enable it?

start terminal

$ winetricks

click on select default prefix, click ok
click on Change Setting, click ok
click the box for glsl=enabled, click ok

back out of winetricks by hitting cancel until you are back in terminal
if you compiled just the 64bit wine, you need to change to the /usr/local/bin and do ln -s wine64 wine so you can run winetricks

you can set WINE= and run winetricks than.

I've got a script too that handles this automatic
see here:
github.com/Thaodan/usenew/blob/master/doc/usenew.org#options-1

I did that still says gamewont initialize

it's works

I was actually playing just fine this morning. When the servers went down for maintenance and the patch, I went out for a couple of hours. Upon returning, I found that I receive the above message when I attempt to launch the game from the Battle.net launcher. When I attempted to run the game directly from a terminal, I get the same message window, with the terminal only outputting "Segmentation fault (core dumped)" upon closing the window.

Wine Staging 2.21
Ubuntu 16.04

I later ran the 64 bit exe from terminal, and it works just fine.

Good.

Did they change so that DX9 does not work at all, or just a "warning" that the support is ending some time in the future? Guess its just the warning...

Well, as i have posted before, atleast the reason why the did not bother with fixing ground effects with DX9 is there, and the reason they did not bother with OpenGL is cos of Apple Metal.

The only real alternative for wow is then DX11.. so lets hope some time in the future we can get DX11 performance for wine 3.x to the level DX9 was with Wine 2.0 :)

Warning: Your current graphics API will not be supported in future versions of World of Warcraft, which will require DirectX 11 or Metal.
Warning: Your current system will not be supported in future versions of World of Warcraft which will require a 64-bit operating system.
Warning: Your graphics card will not be supported in future versions of World of Warcraft, which will require a Shader Model 5 capable graphics card or better.

www.wowhead.com/news=280322/7-3-5-ptr-build-25826-updates-racial-tweaks-for-allied-races-increased-minimum-r

So, i guess i was somewhat correct in my theory that the reason they dont bother fixing the DX9 ground effects bug is cos dx9 is getting phased out.

WoW works "ok" with DX11 as it is now tho, but the performance is so-so if you compare it to 2.0 and dx9 (pre CSMT "fix" that came with 2.1). If wine-devs would be interested in performance tuning, it could be nice tho.. so we shall see.

Hopefully wine-staging will be updated to work with 3.0 when that is ready, cos as it is now release wine does not work. And unless something has changed with rc-6, the vsync bug is still there for dx11.

>Hopefully wine-staging will be updated to work with 3.0 when that is ready, cos as it is now release wine does not work. And unless something has changed with rc-6, the vsync bug is still there for dx11.
Is this reported?

>WoW works "ok" with DX11 as it is now tho, but the performance is so-so if you compare it to 2.0 and dx9 (pre CSMT "fix" that came with 2.1). If wine-devs would be interested in performance tuning, it could be nice >tho.. so we shall see.
Is that tracked too? this will be critical for the next addon as Dx3d 9 is likely removed than.
I wish we collect money for or bug bounty or something.

Vsync-bug: Was fixed in wine-staging-2.18. If the wine-devs cba to keep track of what wine-staging fixes, then sure as hell i won't bother reporting yet another bug. There are bugs that are 10+ years old on bugzilla that is still not out of "unconfirmed" status...

DX11 performance: Its nothing to "track". CSMT was reworked to a less "hacky" version when 2.1 was launched, and it was stated:
Since most of our users enable the CSMT because of the performance improvements (although it can also be used to fix drawing issues for specific games), here is one additional note. The main focus during our work was on correctness and not directly on performance. We included some new ideas to speed up the rendering but also left out some more experimental ones which were included in the old versions. The performance might therefore differ compared to Wine Staging 2.0

Now, DX11 did not work with wine-2.0, so it cant be compared in itself. DX9 w/wine-staging-2.0 is faster than DX11 w/wine-staging-2.1x simple as that. If the performance will ever be on par, i cant say. In windows DX11 in wow is usually faster than DX9 (atleast with up-to-date-drivers and capable hardware). Iv'e done many benchmarks with things like Unigine Valley and Unigine Heaven in wine, and from what i can say from that is that the DX11 performance in those benchmarks are ALMOST the same as native OpenGL performance when running the native Linux client... And that is awesome. Why World of Warcraft suffers that much i dont know, or for all i know Linux OpenGL performance just is that much worse performancewise than Windows and DX11. It is not unheard of to have fps problems in raids and the likes even under windows.

I know a DX11 -> Vulkan wrapper is being worked on, that hopefully and possibly will have a lot less overhead than the current DX11 -> OpenGL wrapper wine uses. Until then, i guess we will have to make do with what we got.

Afaik the reason wine-dev does not work with World of Warcraft has to do with some ntdll authentication libraries or something that wine-staging fixes. I must admit i have not tested wine-3.0-rc5/6 with battle.net, so this info might be totally off.. I have not seen anything specifically regarding battle.net in the patchnotes, but that does not mean it doesnt work... Cos with most things wine, fixing an obscure 2D game from 1996 might be the thing that fixes the latest battle.net client :) The performance of wine-3.0-rcx is sadly not on the same level as wine-staging. Unigine Valley DX11 is a slide-show with wine-3.0-rcx, so cant compare performance there tho.

Thanks for the detailed answer.

The fix was for the game (s) itself as they used the back to enable the anti cheat engine.
The patch required for this, is this:
github.com/wine-compholio/wine-staging/commit/f1b1baf057bd8bf7f22bfdf3f6d982effaeab42a

One thing I noticed while using dx3d11 on wow with wine that my gpu is basically idle.
I had never more than 40% load.
Is this intended or this the exact issue Here?
My GPU is an Nvidia GeForce GTX 1080ti.

Depending on settings. You can get higher gpu usage if you enable FSAA 8x or something like that i guess, but still would loose some fps (but not so much with powerful hardware tho).

The game in itself is like that in windows too tho, so its a game issue that is possibly exaggerated by wine. The game engine is a rather old engine with patch-upon-patch but no complete rewrite, thus limited multi-thread capabilities ++. Even tho WoW should be capable of using 8+ cores, it really does not utilize fully more than 2 i guess. With CSMT and nVidia threading optimization (dont remember atm as im at work), the game will offload on different cores, but well....

As it is a mmorpg, lots of calculations, entity placements++ is done in CPU + rely on the server calculations and your bandwidth. This means that even tho you have powerful hardware, it really does not matter that much unless the servers push enough info for your computer to have something to do. Even spell effects and the likes i think is somewhat calculated using cpu and heavily rely upon server info. When a boss places a pool of fire on the floor, the servers have to calculate where that pool is, and keep updating whoever stands in the pool.. things like that. With 25 ppl, this info is sent to everyone, and the server have to keep tabs on where everyone is at all times. I suspect (as this seem to be the problem with many mmorpg's) that some sort of syncronization is made between clients to try to make stuff as even as possible for "everyone". Take Everquest (have not played in years tho) which is a super-old graphics engine, still wont push out 500fps on a new computer. Its a combination of different stuff... latency, cpu, server-calculations.

Yeah, i agree that regardless of this, you should have atleast 100+ fps at all times, but SOMETHING is preventing this even in windows. Wine does not help on the situation, as the fps is higher in general in windows :)

C

That sounds reasonable.
I saw the same things as you said, althrough with metal at least on OS X they must had fixed at least something.

I really want to know what "SOMETHING" fixes this on Windows.
If we can help in anway than I would gladly help.
Maybe there's a way to debug this better, if possible to debug this on windows and give some vs. data.

Tried to take a stab at getting 3.0-rc6 up and running with WoW, and found out i needed "ntdll-x86_64_ExceptionInformation" patch to get past the first error message. However, it now just hangs in the background, and i have a sneaky suspicion that the bcrypt-Improvements patch-set from staging is needed.

Loads of changes there tho, so i kinda gave it up as it is a HUGE patchset to implement.

Meh.. I hope 3.0 gets finished soon, so some proper coders can get to work on staging again :P

One should think that Wine would have a small interest in getting their software up and running on one of the worlds largest playerbases tho (WoW and Overwatch being hugely popular), but i guess its not important enough :)

>Loads of changes there tho, so i kinda gave it up as it is a HUGE patchset to implement.
Look at the patch definition it depends on some patches.
>One should think that Wine would have a small interest in getting their software up and running on one of the worlds largest playerbases tho (WoW and Overwatch being hugely popular), but i guess its not important >enough :)
Maybe we could gather money on this or help in a way that this feasible.

There are patches that depend on that patchset from what i gather. I could patchinstall.sh that by itself, but the patchset is like 20 patches.

Got an idea to try rather than implementing patches on 3.0, i think ill try to patch 2.21 with the patches i believe get wow running 1 by 1, so i will know for sure what is needed before trying to implement those on the 3.0 source perhaps.

Well.. after quite a few hours of trial and errors, its "more to it than ntdll patches".

What i did was to compare the wine-staging-2.15 source that have the same error as the 3.0-rcX source. I compared that with the wine-overwatch-2.15 source that works with wow, and found the following:

1. wine-staging-2.15 got the same error as 3.0-rcX
2. wine-overwatch-2.15 works
3. Difference between staging and overwatch is the aforementioned ntdll-x86_64_ExceptionInformation changes and quite a bit of wined3d changes and some minor stuff.
4. I applied ONLY the ntdll-x86_64_ExceptionInformation changes to wine-staging-2.15 and it worked.
5. Applying ntdll-x86_64_ExceptionInformation to wine-3.0-rc6 makes the error message go away, but crashes.
6. Difference between wine-2.15 and wine-staging-2.15 when it comes to wined3d, and d3d11++ is huge, and cant really pick what patch you need.

Conclusion: Most likely wine needs quite a few of the wined3d, and possibly d3d11 changes from staging. Since wined3d consists of like 20 or so patchSETS (with multiple patches in many of them), the task for ME as a non-coder is rather futile. A lot of the d3d functions are implemented, but i dont really "read code" that well, so...

Was worth a shot. Probably got to learn something, and got to test a new tool i liked for comparing changes.. "Meld" :)

Hi all.

I have installed wine 2.4 (staging) (as stated in the about tab of winecfg) on ubunty 16.04 on a laptop with a dual gfx card (Intel + nvidia 820m)

Sorry if this sounds completely noobish but whatever combinations of options, when I run either Wow.exe of Wow-64.exe or from the launcher, all fail with "ERROR Game Initialization failed!". I just downloaded wow so I guess that makes it the latest version.
The bare minimum steps described here didn't work out but I'm using wine 2.4 instead of 2.21
Can someone be so kind to make a list of steps to follow that would be comprehensive for an "outsider"? I don't mind compiling things from scratch.

Latest stable is 2.04. Latest staging from winehq is 2.21. If you are using stable 2.04 then you can not run wow, period. It needs the staging patches, and the wine staging site does not have 2.04 staging on the site. Here is the link to the wine staging released source code, with patches applied.

github.com/wine-compholio/wine-patched/releases

As that page shows, 2.21 is the last release that is patched, and ready to be compiled on your machine. I am running Wine Staging 2.18 as that seems to give the best performance in directx 11, since blizzard has dropped DX9, and if you run DX9, the texures for certain ground effects are not visible.

Thanks for the quick reply. That's a bit weird. wine --version gives "wine-2.4 (Staging)". I guess I'm not familiar with the different versions of wine.
Anyway building 2.21 from the link you provided. Guess I should remove any existing versions before installing the 2.21

You will need to uninstall, and if you plan to just launch wow from a desktop shortcut, you can get by just building wine64. I do not run any other windows programs, just world of warcraft, and it runs fine as pure 64 bit. I am using fedora 27, with nvidia proprietary 390.12 drivers. if you need to run winecfg, just run wine64 winecfg to force it to use the wine64. You might also want to search the messages here, for suggested compiler optimizations as well.

Ok I'm getting close. Now wow runs. I get to main screen. When I try to log in I get the error:
You have been disconnected (BLZ51900007)

When I run the launcher I get the login screen appears but when I login I get error:
Could not log to Battle.net
More help: us.battle.net/support/en/article/24014
And there is an option to continue offline When I press continue offline I get the error:
Failed to create a graphic context.
If you receive this error again, check that your graphics drivers are up-to-date and that your system meets the minimum requirements.
More help: BLZBNTBNA0000000A

This happens with both wine and wine64. Tried it with both Intel gfx and nvidia (proprietary 340.102)

Also keep getting this in command line
err:secur32:SECUR32_initSchannelSP TLS library not found, SSL connections will fail
Although I have installed libgnutls30, libgnutls-dev and libgnutls28-dev (i386 too)

It seems that a fresh compilation of wine after installing libgnutls was necessary. Wow now works as expected. Launcher still not working though with the same errors.
I get this log on the command line pastebin.com/kLqZ2NXY

I guess you are following wiki.winehq.org/Building_Wine when you build wine?

There is a LOT of libraries++ to install to compile it tho, and you can see that when you run the .configure script. If you get things "missing" you can still compile wine, but may be missing important stuff.

Parhaps run the ./configure script and post the output here? Last 15-20 lines or so :)

Getting around the regular config stuff for wine like winecfg with a pure 64 bit compile is easy enough, as you can just do a : ln -s wine64 wine in the /bin folder of your wineinstall. That way you dont have to think much about it.

I use PlayOnLinux that got those nifty icons and easy shortcuts to bring up winecfg, regedit++ and i guess they are running "wine" as default to launch those, so making a symlink is required with a wine64 only install.

When it comes to wow, it seems as even tho you launch the wow-64.exe file directly, it will launch agent.exe in the background. This sometimes hamper performance. Agent.exe looks to be a 32-bit program, so by using a pure wine64 install, agent.exe is prevented from running in the background. (debug log indicates wrong binary format for agent.exe in a wine64 install).

Steve,

Have you ever tried Wowmatrix? I run it with Wine 2.21-Staging to get all of my addons. It runs just fine minus an error message I've seen pop up upon closure, however, this doesn't affect my addons or the use of the application. DBM and Healium are on there among junk sellers and repair.

www.wowmatrix.com/faq/alternate-download

Try to use reply rather comment.
First Wowmatrix has a native version, which is the only good thing about.
I dont trust it, it redownloads addons done by curse and just steals traffic from devs.
If you want a native app try lcurse.

Wowmatrix is sadly missing a lot of the mainstream add ons, I wish it was a viable alternative but it just isn't.

I have 2 cards . Tried AMD rx550 4gb (cheap card ) against my Nvidia 970 4gb . The amd card won ! Played wow with dx9 and dx11 . I had 45 fps in dungs with amd dx 11 and 25 fps with Nvidia . Use the latest nvidia drivers 387.39 and with the amd card i used open source drivers .
wine-gaming-nine from aur 2.21 staging .
With nine patchet and dx9 was really a winner. 60+ fps in dungeons .
Noticed that Nvidia card is better on native apps - My chromebrowser are loading pages faster etc etc
So if you are on linux and want a good cheap gaming card i must recommend the rx550 4gb or better . My cpu is an amd-8350 8 cores 4 ghz and i have 16 gb ram . Sorry for my bad English .

Hi,

Lately, since with Wine 2.20 and so, I've had an issue where top right quarter of my screen has been completely void of certain spell effects that go on the ground. They just disappear if you turn your camera, and show normally in the other 3/4 of the screen (well, normally, with DX9 they're kinda single-colour pools, but they can be seen). So, depending on where you're facing, you might be standing in shit without noticing.

Anyone else seen this?

Wine 2.15 with overwatch patch doesn't have this issue for me. Is it possible one of the patches was missed or something?

Also, I've had pretty stellar FPS with Gallium Nine. 8) I highly recommend trying it, if performance is an issue for you. It's no DX11 though, but that doesn't really work for me that well anyway atm so it's by far the best way to run the game under Linux from what I've seen.

DirectX9 for World of Warcraft is somewhat bugged with missing ground effects. There has been several posts about this on the forums, and the "fix" from Blizzard is to upgrade graphics drivers to a DX11 compatible one and use that.

Ground effects works in DX11, although sadly with horrible performance compared to Wine 2.0 and the old CSMT staging patches.

The ground effects is possibly due to some changes in the 7.3 client, but since DX9 is relatively underused for Windows pc's, i guess its not that much of an issue. They did a fix for the mac client regarding this and the OpenGL backend:
us.battle.net/forums/en/wow/topic/20758847141?page=4#post-80
us.battle.net/forums/en/wow/topic/20758687941?page=2#post-32

What you can test is to go to that spider spot in Antoran Wastes (www.wowhead.com/npc=126115/venorn) When i use DX9 i cannot see the green "fel pools" on the ground from the dripping green stuff, but when i use DX11 they show up fine. There are loads of similar effects that miss in raids and other places, but this is easily reproducable. Try with 2.15 DX9 vs. 2.20+ DX9 and see if there is a difference? If there is, its definately a Wine bug.. and for all i know, the "windows people" complaining about this might just be wine users not admitting they use wine/linux cos they know they won't get any help that way? :) That would be awesome if it was the case, cos then the 2.0 client could be fixed for DX9 and we all could play with double the fps on nVidia cards :) (Staging-nine ofc benefit too).

Oh, and the 2.15 overwatch source is no longer available as Gamax has cleaned out the repository, so i cant test it myself.

Be happy to give it a go if someone can post 2.15-staging source w/overwatch patches tho :)

I have Windoze 10 and I do still play wow on 10 until wine 3.0 gets put to staging, so I can compile and test it with the patches needed to get around blizzard drm. Having said that, I tested dx9 on windoze 10 and found it lacking the ground effects, as described. big repair bill for my tank, cause i could not avoid the effects. went to dx11 and got about the same fps but the ground effects all showed up. in windoze i do get around 130fps in dalaran, and populated and drop to 75-85fps in 25 man. in wine 2.18 i can run dx11 and get around 25fps in dalaran, and drop to 14 in 25 man, so i hope wine 3.0 has better dx11 support. too avoid eating up tons of space on my linux drive, i symlinked the windoze 10 copy of wow to my wine prefix, and I log to windoze to use twitch to keep my addons current. for almost all of my gaming, minus raids, i do use wine because I prefer the inherent benefits of linux over windoze.

Sounds about right.

I dont have windoze installed, and it has more or less just become a stupid hardheaded thing for me not to do so.. But yeah, i have before, and if things get too bad, i probably will again - dualboot.

One other option i might consider is to get a newer motherboard and cpu that support VT-d with pci-passthrough so i can run QEMU with native drivers. Its somewhat of a hassle, but probably doable :) Running a VM of Windoze is aaaaalmost as bad as dual-boot tho, cos there is some stuff with gpu being bound to some driver or whatnot so you have to load some kernel modules and stuff.. well.. havent studied too much.

Lets hope 3.0-staging will be near what 2.0-staging was for DX9.. although i dont think we will ever get there again with DX11, as the GLSL translation needed for DX11 is too slow.

A visual example of this in a dungeon can be found here; youtu.be/LXo47RGmFkk?t=12m10s. Later cited to be also an issue with a spell in Antorus. He cites DX9 as an issue. The FPS issue is also affecting Windows 10 users and etc. Whatever the Overwatch infrastructure that Lutris was utilising to fix Overwatch, that we used for WoW when that patch went live. That infrastructure imagine is what his affecting the FPS in both Windows and Linux.

Yep.

Perfect viewable result of this DX9 texture bug. Now to convince blizzard to fix it :)

Hi!

I just thought I would share some of my experience of getting Warcraft to run after my wine installation set to WinXP was blocked. I had to upgrade where the Wine 2.21 allows one to set Win10 as the Windows version.

# Overwatch patch notes for new DRM in Google search. My searches on how to upgrade form a WinXP wine return a bunch of Overwatch patch pages at the top of Google search for new DRM coee. Overwatch patch has been incorporated into Wine since 2.1 so is on longer needed. Just use wine 2.1 or higher.
# Battle.net Launcher.exe: I've been stuck for weeks on not being able to log in because either the 'Login" button would not display or after log in the application crashed. Turns out I needed to download the very latest installation client from Warcraft. Something in the latest Battle.net.exe works but previous versions did not.
# No install. I did not install Warcraft as part of the WinXP - Win10 upgrade of wine. Warcraft is a huge download. I backed up my 'Program Files (X86)" folder and retained all the Warcraft folders.
# Battle.net installer will find an existing version when hitting the "Install" button after downloading the latest Battle.net.
# Warcraft window did not display and eventually kept crashing with "Bad Window ID". I guess the last time a played months ago must have been with a different X config. In the Cinnamon Window manager I set the Warcraft window to "Visible in All workspaces" and this fixed my problem.
# I had to use "winetricks" and install Directx 9 because my Warcraft of WinXP was still configured to Directx9.

Just a positive note about 2.21 staging

DX11 runs fairly ok. Not huge fps, and some dips in huge aoe fights (world bosses and such), but overall worth it with functioning ground effects. Have not found any evidence Blizzard plan on fixing ground effect bug in DX9, atleast not yet.. and seeing as they have said XP is no longer supported i guess most system able to run WoW have some sort of DX11 functionality, as they will atleast use Windows 7 or newer. No problems averaging 35-40 fps running around Argus doing dailies. Sure, having 150+ would be ideal, and you can almost do that in DX9 mode, especially if you use the 2.02 patched branch.. but at the cost of missing loads of ground effects vital for raiding :)

So.. as a summary what i have as settings picked up from posts in these threads, and some experimenting on my own.
I compile wine-staging from source with GCC 7.2.0. I use the following configure string before compiling:
./configure CFLAGS='-march=native -O3 -fomit-frame-pointer -pipe -DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS' --enable-win64 --prefix=/where-you-want-binaries-installed-if-you-dont-want-syswide

This will produce a 64 bit binary ONLY, so you have to make a symlink in the /bin folder of your installed folder:
ln -s wine64 wine
to be able to run winecfg and such. AND it will not run battle.net app (or any other 32 bit binary). This means if you do what i have done, you need to swap between pre-compiled wine-staging-2.21 for your distro whenever you need to patch or similar. (I use PoL to easily switch versions tho.. other solutions is also available). I have found that if you run a multilib 32/64bit, wow MAY launch some "agent.exe" in the bacground for some reason, and that does sometimes suck resources.

Winecfg i have set up with:
Windows version: Windows 10
No library overrides
Enable CSMT
Enable VAAPI

Wine settings in PlayOnLinux gui:

GLSL Support: Enabled
Direct Draw Renderer: OpenGL
Video memory size: 4096
Offscreen rendering mode: Default
Render target mode lock: Disabled
Multisampling: default
Strict Draw Ordering: Disabled

Debug flags: -all

I have the following tweaks:
export __GL_THREADED_OPTIMIZATIONS=1
export __GL_SYNC_TO_VBLANK=0
export STAGING_SHARED_MEMORY=1
export STAGING_WRITECOPY=1
export STAGING_RT_PRIORITY_SERVER=90

I run the 64 bit wow client from a 64 bit wineprefix.

The following settings in WoW configfile /WTF/Config.wtf

SET worldPreloadNonCritical "0"
SET processAffinityMask "255"
SET gxTextureCacheSize "3070" (Depends on your gfx card.. other tips may be 2047)
SET gxApi "D3D11"

Ingame graphics settings is set to "7". VSYNC off, tripplebuffer off. I run "Windowed mode" (Because i have dual screens)

I have a nVidia 970 card with 4GB vram. Did some testing with xorg.conf, and actually found that for ME the best setup was with ForceFullCompositionPipeline=Off (metamodes), although it MAY at times be some tearing when browsing with Firefox, although the new Firefox seems better at that. Using nVidia binary driver: 387.12

This depends on your distro i guess, and drivers and whatnot. Maybe wow runs utter crap for someone using these settings, maybe not. If you get a better result, feel free to post your findings :)

Whenever you change wine version, or nVidia driver you should clear out the following folders:

$home/.nv/GLCache (nvidia shader cache folder)
/wowfolder/Cache (World of warcraft texture cache - seemingly rebuilt if you change gfx driver or wine version)

When you clear this, you WILL have stutters a bit.. but after zoning around and playing a while the textures/shaders will be compiled and saved to disc for smoother gameplay later.

In case anyone want to try out Wine-2.22 patched with wine-staging-2.21 i have made a github for that.

Project is pre-patched with what i have tried my best to fix the wine-staging-2.21 patches. Slackner will no doubt do a WAY better job + add something more when the real 2.22 wine-staging is commited, but for now it seems to run :) PS. Use at your own peril!

github.com/SveSop/cyberwine.git

Once downloaded, configure with:

./configure CFLAGS='-march=native -O3 -fomit-frame-pointer -pipe -DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS' --enable-win64 --prefix=/where-you-want-binaries-installed

PS. the above will only produce a 64-bit binary, so dont forget to do the ln -s wine64 wine in the /bin folder before running anything like winecfg or the likes :)

Wanted to make sure you know your efforts are appreciated. Your posts are very informative. I have downloaded and compiled the staging and also your cyberwine. I built a wow64 build per the wine site, so I could run other 32 bit apps if needed. Agent is part of the battle.net desktop app, and I have the options set to exit the app, when it launches the game. I do not use the app in Linux as my game is symbolic linked from the windows drive. I have to keep windows 10, to support the customers I have that still run windows. I am happy to say, those numbers are getting smaller, as people see what Linux can do. I am running Fedora 27, Geforce GTX 970, and 387.22 proprietary. I can report that the game has decent performance on Linux, on my system, but I still go to windows to do large raids, and to update addons. If someone has the skill to make a good port of the curse client, I would be grateful. That seems to be above my skill set as yet, but I am trying to figure one out.

Thank you :)

Havent they more or less stopped the curse client? And now use the Twitch app? More or less the same i guess :) I havent tested it, as i only run 6-7 addons and manage them manually.

Wow is not a amazing performer in windows either, as its very cpu bound when there are many enteties around, and the graphics engine is rather old and outdated. Now that they officially are ditching XP, one may hope they perhaps develop a updated engine for the next xpac, with support for Vulkan :)

WoW is a poor performer in Windows, unless you have a massive cpu and video card combination. As to curse, the older curse client is still active, as well as the twitch app. My wife is able to use the older curse client to maintain her addons, and I have upgraded to the twitch client.

I would love to see vulkan or even native opengl support in WoW, and would love a true linux client also. Not sure if any of that will ever happen. I plan to examine wine source code, to learn what I can about directx. specifically as it pertains to 3D rendering, in hopes that I can come up with a decent implementation to improve the performance on Linux.

They have more or less said there will not be any OpenGL changes to the client, as that was a "pet project" by one of their employees that no longer work on that project. The macOS version of OpenGL is supported, but not working for Wine afaik.

DirectX9 is rather bugged atm with missing ground textures, and chances are that they will more or less ditch DX9 support altogether is imo rather high, as nothing older than Windows 7 is supported "officially". Win7 and newer all have DX11 support, and i suppose if you have an old/non dx11 graphics card, you have troubles playing wow anyways.

Vulkan MAY be an option.. perhaps the most im willing to go in terms of wishful thinking tho :) Atleast with Vulkan support, it could be a lot more performance to gain from Wine as Vulkan Vulkan would be a lot less work than DirectX11 OpenGL as it is now. Wine 3.0 supposed to be right around the corner with possible DX12 Vulkan, so interesting times. The marketshare for ppl using Linux exclusively to play WoW is so little, that even considering developing that as a TRUE working project will 99.9% never happen.

My projections: Blizzard will ditch DX9, tune the graphics engine for next xpac to support DX11 and DX12. We will have the same situation we had with limited DX11 support a year back with Wine, and had to fall back to DX9. Now DX11 works, and with a new client the new "fallback" for us Wine users will be DX11, with improved DX12 support during 2018 :)

Not really sure how many that use Wine to play WoW tho.. but from posts on this forum i guess its below 10 :P And using Linux exclusively without dualboot at all? Hah.. like 2? :)

I'm still running Linux only. The new raid can be played in DX9 in full heroic, except for last boss (Argus the Unmaker), so I'm using Staging 2.0 for that still with good fps. Argus requires DX11 to show ground spell effect for Death Fog. However the fight isn't that graphically challenging so I'm still getting around 30 fps most of the fight. This is on the range of doable.

Just for the record, I'm still using Wine 2.18 for DX11, compiled with -march=native -O2, since it seems to work better then later versions fps wise. Also there is some bug with mouse from 2.19 that make it harder to turn camera for mouse turning.

I asked in the forum if there is more speed increase incoming, but except for a weird reply from someone that didn't read my question it seems, still no reply. Need to find out if we should bug report the fact that WoW with DX11 simply doesn't CPU for more fps. If it is a bug, perhaps it can be fixed and we actually end up with workable fps.

Yeah, i saw your question about that... and agree that the person answering you probably did not read what you wrote at all.

Im currently fishing for a official reply from Blizzard regarding DX9 support, but probably wont get an answer.

When it comes to cpu load vs gpu load, its not ONLY a wine issue. This problem is somewhat the same in Windows aswell, but i havent run wow with windows in quite a while, but this WAS a problem, and from searching different forums this is still a problem. Ppl with 1080 cards getting 20-40% gpu load, and 30 ish % cpu load.

The wow gfx engine is a WC3 engine thats been patched and tweaked each expansion, but have limited multithreading capabilities. Give that + that a LOT of the "world" things is all done in CPU, it does not help if you have a overpowered graphics adapter.
Wine ofc makes this "problem" worse tho.

And yeah, i DO agree with you that they could/should bring some of the tweaks from 2.0 CSMT back, but i have a sneaky suspicion that its not as easy as a couple of lines of "tweaks" as 2.0 does not work at all with DX11. DX11 have some other ways to do stuff, and ive tried to post regarding the different way that DX11 detects vram vs DX9.

There is little activity on the wine-staging these days, as its still not officially updated for 2.22. Perhaps this is because Wine 3.0 is around the corner? I think i read some comments about "late november" as a estimate some time ago, but dunno.

Gonna give 2.18 a test, if you feel fps is a bit better there Dox.

I wonder if this has anything to do with SM4 pixel shaders for GLSL 4.4 that came in 2.20 (i think)? Did you compare between 2.18 and 2.19?

Interesting anyway :)

Did some testing.

2.18 does indeed give better fps in WoW.. no doubt.

I also benched Unigine Heaven benchmark under wine with all the staging from 2.18 -> 2.21 and it was a decline in score each release for some reason. However it does not really give so large a difference than it does in WoW, so there is something going in there i guess. It COULD have to do with more cpu usage? WoW is a lot more cpu dependant than Unigine Heaven tho, and rely upon a lot more stuff being calculated.. Heaven benchmark are able to load my 970 to 100% when running tho, even without AA.

From what i tested yesterday, i have no real idea.. I have tried to make some sense to the patch differences between 2.18 and 2.19/2.20 and maybe think of something that would mess up wow.. but cant really come up with a better idea than the SM4 patches from 2.19 -> 2.20.

2.18 fixed the vsync issue (able to disable it), and thats imo a must.. so anything older is not good.. And anything newer seem to perform worse for WoW.

Status as of now:
2.0.2-staging w/DX9 and overwatch patches ref. Dox = Best performance by far.. but wow is plagued by the missing ground effects bug, so kinda suck to have to switch wine versions depending on encounter..
2.18-staging w/DX11 = Better performance than 2.19+ for some reason.

Can't submit a bug to the Wine dev's cos a general "Performance sucks" im pretty sure will be ignored :)

S

Yeah, and you will want DX11 if you do raiding. 2nd boss Mythic in Antorus (perhaps also heroic and I missed it), has ground effects that don't show with DX9.

I'm staying on 2.18 for now. I really hope we get some more performance soon, I doubt it will happen. You should try the bug report thingie!

I figure I see you posting in Xanmod forum. Personally I stay away from PDS-mq kernels since they don't play nice with OW (complete freeze). So I was on an old 4.13 that still had CFQ. However, since I saw that post about PDS-mq vs MuQSS, I'm now using 4.14.4-xanmod7 with MuQSS now, while setting it to throughput. I think it has gotten me some more fps, and it works nicely with OW aswell.

I have not had any freezed when playing wow, as thats the only thing i play theese days tho.. but i did have a crash after running Virtualbox for some complilation stuff.. Now, if that was due to PDS-mq, i dunno, as Virtualbox has a tendency to not be 110% stable anyway :)

I have quite a bit better performance with 4.14.2-xanmod4 and PDS-mq than with 4.14.4-xanmod7 and MuQSS in wow tho, and have tested a few tweaks from Alexandre without any real change. Will see if i can convince him to maybe put up a dual repository for custom choice perhaps :)

There should be a test-site like Phoronix for wine that would show some differences between the wine versions.. Or something like that. Benchmarking in WoW is not that easy as it is not replicable due to so many external factors.. let alone hoping that any of the wine developers play wow :) Will look into it..

I did my own quick testing. But I still prefer CFQ for gaming it seems. WoW with DX11 gets more fps with my Ubuntu linux-4.10.0-40. And Overwatch is better with linux-4.13.5-xanmod10 (1 of the few kernels still have CFQ). So it isn't 1 size fits all. And OW needs it the most, so I'm mostly on that now.

I take that back. 4.14.4-xanmod7 set to througput is very solid in teamfights. Going to test it tomorrow in raids in WoW, where I drop in FPS. My earlier testing was outside.

I haven't tested the latest rev. of 4.14.4-xanmod7 that much in WoW, so it might just be some tuning have been performed. On my previous tests with Unigine Heaven it performed somewhat worse than the PDS kernel, but that does not automatically mean WoW performs worse.. Loosing 4-5 fps sux tho.. especially when i only hover around 40'ish in Dalaran :P (Not counting raids, cos thats a even bigger problem.. i just dont have the time to pay that much attention to it hehe)

Worth testing indeed :)

CFQ kernel will perform better i guess, but afaik the MuQSS or PDS is not really about performance but more for interactivity. Like if you compile wine in the background while surfing/watching youtube videos or things like that. I also use simulationcraft to score gear i get, and have set it to 6 cores when i calculate... the difference between PDS, MuQSS and CFQ is noticable if you run it while playing :)

You mention you load all 4 cores and no HT.. does that mean you have disabled HT? PDS seem to not put that much strain on HT cores, where MuQSS seem to put equal amount of load on HT/Real cores.. So if you have disabled HT, it might be worth testing?

Dalaran FPS doens't matter to me. 20 Man Mythic raiding, 3v3 Arena however does. That is where fps matters. As I just posted in Xanmod forum, I like MuQSS set to throughput. It is is the difference between sub 20 fps, and staying 25+ fps. Sad it isn't more, but I'll take it.

I don't have HT, I bought my i5-4670k especially because of that. I was going to overclock it (and I have a 24/7 OC on air of 4ghz on all cores for the past 4 years now). And HT aware schedulers are (were) rare, so it can lead to slowdowns.

Anyways, lets talk game here, and kernels at Xanmod forums. (Linux_Gamers_Group on Discord will also work).

Yep.

Tested by turning off my HT cores for WoW, but seems a bit worse for performance for me.. but then again, i have a much older CPU than you, although it runs @ 4.2GHz overclocked (And has done for many years).

When it comes to Wine versions, i agree that 2.18 seems the smoothest for WoW as it is now, and that 2.21 actually is noticably slower. 2.22 that i patched with staging myself after some fiddling, i guess is in the state of "cant really be trusted" perhaps.. Dunno.

Started to TRY to patch 3.0-rc1 with the staging patchset, but waaaay too much work for me atm, especially since im rather clueless to what all the code does. Sometimes the implemented patches to main looks a bit different than the patch from staging too, so its more or less (for me as a non-coder) just guesswork if its implemented or not.. extremely so now with 3.0-rc1 and all the work that has been done.

And.. 3.0-rc1, does NOT work with Battle.net/wow without the staging patches. Perhaps some day staging will catch up and it will be worthwhile to test 3.0, but as of now, ill stick to 2.18 for DX11.. unless ofc Blizzard decides to fix the ground effects in DX9 (would be preferred and get back to 2.0.2)

There's a good curse client that supports everything except separate library install and it's called lcurse.

i have tried to get lcurse to operate, on fedora, since version 25, with no luck. Also it appears to be based on the older curse api, rather than the one in use now by the twitch client that runs in windows. I have several addons that are maintained on github repository sites, that are not able to be updated using lcurse. I would also mention that I have tried jcurse, the java client, as well as minion. Neither of those can install the addons that are maintained on github sites.

The URL is changed and there's a patch for it.
Lcurse can update add-ons from git repository's.

Would you please post a link to the new lcurse so I can test it?

There's an issue about it, try looking there.
I for myself use a VM with windows.

I am confused. I do not know where to find lcurse. That is what I am asking for, the link to get lcurse.

About the performance regressions: when you try to make a bug tracker entry try to to be detailed as possible I think then it's ok
But maybe ask at #wine-staging

github.com/ephraim/lcurse
I have been using lcurse for over a year, not always perfect (it did break for a while when curse changed their website, but fixed now) but gets the job done without dual boot or VM usage. I don't think it detects your currently installed addons though if i remember correctly, you have to manually enter them into lcurse to get started. (this doesn't break your existing addons, its just more of a first time use annoyance)

Have to correct my post: the exact error is Failed to create a graphics context. Error Code: BLZBNTBNA0000000A.
And the link to the solution in english is eu.battle.net/support/en/article/12706.

My game always gets to "Retrieving realm list" then disconnects me. It has been happening for the last 2 or so months. I use Linux Mint

I have tried reinstalling wow, using almost all the guides i can find, and even a few different wine versions, but can't seem to get past it. I dunno, if it something i am doing wrong, not installing something, not configuring wine properly or what it is, it is really frustrating as i have friends who play, and i can't join them.

Please help me if you can :(

Check your firewall settings. i use port range triggering in my router, so that all the machines on my home network can get in. my wife, son, and I all play. the port ranges to forward are:
6881 to 6999
3724 to 3724
1119 to 1119
6012 to 6012
4000 to 4000
6112 to 6114

i did not have to open the firewall in my fedora, but you might need to open it in your linux distro. hope this helps.

TY Steve for answering.

I tried that on my router, and still stuck on Retrieving realm list.

I had a similar problem with Battle.net and WoW recently after buying a new router.
I solved it by adjusting the MTU on my PC network interface to 1460 (was 1500). Also adjusted the MSS to 1420. No problems with connectivity since then.

I solved in the same way. Only adjusting the MTU to 1460.
In a terminal:
ifconfig eth0 mtu 1460

I

Everything went perfectly with the instructions above:)
Debian stretch here with 2.20 staging.
Only had a little problem during installation with Battle.net-Setup.exe, don't think I saw it here. If I'm not alone on this, this worked : eu.battle.net/support/fr/article/12706
P.S : I'm new here, but thank you for all the work done to be able not to have double boot :)

Todays patch - 7.3.2(25383) seems to fubar my 2.0.2 wine-staging.

I get a crash and no image when starting now... Starts in both DX9 and DX11 mode with 2.19-staging tho, so i guess some sort of tweak was done? Anyone else having troubles launching with Dox's patched 2.0.2?

C

After the last patch I also have errors, after the characters screens the loading stops and I got a WOW51900319 Error.
I tried 64/32bit and dx9/dx11, also in combination with different windows version, no change.

any help?

Seems to work with Wine-staging-2.19, both in DX11 and DX9 mode, so i guess for now that's the route to go :)

C

I was already using wine 2.19-staging, sorry to not mentioned it.
My problem still persists, after character selection the loading screen stay stuck at 70% and then I got disconnected with that error code :(

btw, no matter if I use 32bit or 64 bit or dx9/dx11

I'm using 2.19.r0.gcf5616ffbb-1 (wine-git + wine-staging-git with that commit in version) and it works.

Im using wine-staging-2.19 release, and it works with both dx11 and dx9. Have only tested 64-bit tho, so cant really tell other than the battle.net app works (as that is 32-bit).

Guess its the same for me vs. the 2.0.2-staging from Dox that he can use, and i cant. Perhaps some settings that comes to play? Or some random library?

Btw. do you launch it from the battle.net client, or from the Wow-64.exe command line? I launch mine directly by running the Wow-64.exe file with -d3d9 commandline option. I use PlayOnLinux to manage the shortcuts and launcher options described in earlier threads here tho. GLSL=Disabled when i run dx9, but have to enable it to run dx11.

C

Btw. Have you tried to disable the "Optimize Network for Speed" option under "Network" in the settings? And possibly disable IPV6 the same place (as i dont think the wine client support that)

C

For me it was the cache size thing that fixed the lag.
What I wanted to say is don't over optimize and enable everything.

Hi,
Thank you for your help, but unfortunately, so far, it is still not working.

Actually I didn't changed anything apart directx, architecture and win version combinations. Just after the patch of last wednesday it doesn't finish the loading to enter the world. That's quite frustrating :S

I also tried to switch the optimize network stuff, but didn't changed anything. How can I try to modify the cache size?

thanks!
Nicola

The "cache size" ppl talk about is gxTextureCacheSize.

This you modify in the "Config.wtf" file (Found in your /WTF/Config.wtf) Numerous other threads for windows how to find that file tho... So you should be able to find the same structure under your wineprefix folder.

Add this line at the top:

SET gxTextureCacheSize "2047"

Depending on the vram you have ofc.. Dox found this to work the best for him on his 4GB 970 card... I personally actually find 3070 to work the best for me, but it kinda depends on vram/ram and overall graphics setting (I use "7" on the graphics slider ingame). What this does is tell WoW how much ram it can use.. Wow for my settings tend to use 1400-1800'ish vram, but depends on where you are++. Tuning this will help improve general "stutter" when turning around and such. Do a google search for gxTextureCacheSize and read what ppl write there is a good start.

Another tweak i use is to add:

SET worldPreloadNonCritical "0"

in the same file. This allows for a LOT faster zoning. This helps for random DC's when zoning.. like HS to Dalaran on a populated night had a tendency to DC me or just take a lot of time.. Same for a friend of mine using Windows.. Worth a shot :)

The usual suspects when troubleshooting wow is the same as for windows, as i think it MAY be something else than wine that is causing problems... as i take it "finish loading to enter the world" means you have already passed the character select screen.. ie. graphics are already loaded and operational. Usual suspects: addons. Also you can try to delete the Config.wtf file altogether and just add the two lines i typed above.. This way you have reset your config.. You have to set up graphics++ again, but worth to check if you can zone in then perhaps.

Sveinar

Hi,
I tried to install windows 10 and the game loads perfectly. I thus suppose the problem is something related to the linux/wine environment.

I use Debian stable 64bit, just reinstalled.

I also reinstalled WOW64 bit in a fresh playonlinux container using the following steps:
- create a 64bit container with wine-2.19-stagin
- winetricks corefonts directx9 vcrun2015
- set windows version 8.1
- launch battle-net setup
- launch Wow install
- disable streaming from battle.net control panel

The loading screen now gets stuck at 90% instead of 70%, it's an improvement but not enough.
Maybe I miss some libraries, but I don't see any relevant error from the playonlinux 'debug' mode. How can I investigate this?
Am I the only one experiencing such problem?

thanks for the help!
Nicola

Nah, you are not alone as its LOADS of ppl having this problem with Windows too...

eu.battle.net/forums/en/wow/topic/17613764712?page=58

58 pages long.. SSD helps a lot, but as you say, you installed windows 10 (assumably on the SAME hdd as your Debian install?) without problems..

Things to try xept actually buying a SSD if you dont have it (i have a SSD with wow installed tho..)
1. The aforementioned "tweak" in the Config.wtf file:
SET worldPreloadNonCritical "0"
This will let you enter the zone, and load things "on-the-fly", although maybe causing stuttering after zoning in...
2. You COULD try a different kernel I/O scheduler.. WineHQ recommends (someplace that i have read it.. ) the deadline scheduler
Do

cat /sys/block/sda/queue/scheduler

to check what you are running now (assuming sda is the disc where wow is installed.. change for sdb-sdc++ depending on your setup)

sudo echo deadline > /sys/block/sda/queue/scheduler

to change the active scheduler "live". Not sure how you change it permanently for Debian, but for Ubuntu you can do it by udev rules, or just create a script that do it when you want to play, as deadline is possibly not the very best for regular desktop usage.

Sveinar

A brief update,

so far the only solution was to copy the windows installation (win10), it works under wine 2.19-staging both on the SSD and on the HDD (I've 2 hard drives). I tried to install in wine setting win10 from the beginning, but apparently I cannot install vcrun2015 this way. I will make some more test changing the wine configuration during the installation, or maybe comparing the two folders.

You mean copy your WoW installation that is installed on your Win10 partition to Linux, and then it runs with wine-2.19? But if you install it through wine, it will hang when loading?

exactly!

Then i would start by comparing the /Interface/AddOns folder, and the /WTF folder. Especially the Config.wtf file....

Theoretically unless something is damaging the binary .WDB files when downloading from the client, the install should be 100% identical, but sometimes shit happens and that is why Blizzard made the repair tool in the first place :) The AddOns folder containing your addons is one of the first troubleshooting things blizzard would ask you to clear out, the other is the WTF folder, as sometimes the settings may crash the client. Now on a fresh and new install, the Config.wtf is empty, so why it would cause an error is beyond me, but if you copy the WoW folder over, and it works without a hitch, it may be some obscure thing you forgot you disabled or something? Like previously suggested IPV6 disabled or something like that.

You could try to just copy the Config.wtf file over from the working install -> the non working one and see if thats enough?

This is ofc assuming you are using the same wine-prefix for both your tests, or atleast have identical settings in both winecfg and whatnot..

Similar problem... any help?
Ubuntu Mate 17.10, wine 2.19-devel

Havent tried the "devel" version, so cant say.. But if the problems are "similar", does that mean you get past the character select screen? If so, wine is most likely doing its job and there is something else..
See my answer above..

SET worldPreloadNonCritical "0"

Is worth a shot.

If it is just a wine error/no graphics or similar, then it is perhaps worth it to twiddle around with different OS versions in wine aswell as dx9/dx11 and GLSL settings++ in wine.

Sveinar

I see character select screen. I can choose any character. But when I try to go into the game world, the download freezes by 70%.
As for the hang of the game, the click on "creating a new character"...

So, I reinstalled the OS, installed 2.19 (staging) and it all worked ... Thanks!

I had the 70% loading problem, thought I had tried everything. I finally tried it's own Scan and Repair, loads fine now.

Hey since that version and a few commits before I sometimes get lags for about 1-2s.
I'm not sure if this is a wine bug.
Has someone else the issue?

I saw Wine 2.0.3 was released a couple of days back...

Any chance or even a point getting this to work with the pre 2.1 CSMT hack-patching that makes DX9 run almost as it should do?

C

It will not give you more speed. However, it could be possible to rebase it onto Wine 2.0.3. And it might be useful, since the freetype bug effects everyone with newer freetype versions. Though since they don't fix DX9 it seems, I'm hoping on DX11 performance increases myself.

My repo is a fork of Gamax, which ultimately is based on wine-patched. I don't have time this week, but if I have time this weekend, I'll see if I can rebase my commits onto Wine 2.0.3.

Sounds good Dox :)

In Windows, DX11 performance in WoW is a tad better than DX9 from what i remember, so one can only hope Wine some day gets there :) I guess Wine 2.1x is more for functionality rather than optimizing for performance when it comes to DX11..

C

Patch 7.3.2 didn't fix DX9. However it did break wow-2.0 build.

Getting this error: Required library "USER32.dll' is missing export 'SetPhysicalCursorPos'

This isn't implemented till commit "2e9ca4626e2bedb5b8a0123a1c70d591f5e9d57c" on may 15th of this year. So newer wine versions will work. I'm going to fork wine-staging, make a new branch based on tag 2.0.3, rebase the commits in wow-2.0 repo on top of them, and cherry-pick this commit as well, to see if I can get it running again.

Actually, scratch that. If I start from Wine 2.0.3 I will have to apply Staging 2.0 to it first. I'm not even sure that will go cleanly. It will also cost me more time then I have right now, especially for a DX9 client that is missing graphics. I'll just try to apply the commit to my WoW 2.0 branch and see if I can get the game running again, or if it is still missing more.

Turns out that it needed 2 commits total to make it work again. I can now move around again without crashing, but I only had 2 minutes to test. Anyways, I cherry-picked them on top of the wow-2.0 branch, and pushed to the repo.

github.com/IngeniousDox/wine-wow-2.0

Just to be clear: I'm not going to work on rebasing it onto wine-2.0.3 + 2.0 staging. I'll leave that for someone else, if they really need it. Though IMO it shouldn't be. If we need any of the bug fixes, you can just directly apply them to the wow-2.0 branch.

Awesome! :)

Gonna give it a whirl and see if its stable.

So, you picked patches from the 2.0.3 source commits and applied those BEFORE 2.0 staging? Found that spot you linked a while back to be a page filled with 100'eds of patches, and rather clueless where to begin :) So.. yeah, unless im taught step-by-step what to do, all i can say is that i appreciate your work :)

C

fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x1.
fixme:dxgi:dxgi_check_feature_level_support Ignoring adapter type.
fixme:winediag:dxgi_check_feature_level_support None of the requested D3D feature levels is supported on this GPU with the current shader backend.
fixme:d3d9:D3DPERF_SetOptions (0x1) : stub
fixme:nvapi:unimplemented_stub function 0xbe7692ec is unimplemented!
fixme:msctf:ThreadMgr_ActivateEx Unimplemented flags 0x4
fixme:msctf:ThreadMgrSource_AdviseSink (0xf7cd980) Unhandled Sink: {ea1ea136-19df-11d7-a6d2-00065b84435c}
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0x1200e4b8): stub
err:seh:setup_exception stack overflow 1744 bytes in thread 0009 eip 000000007bc60cb4 esp 0000000000160f40 stack 0x160000-0x161000-0x260000

Crashes before login screen (same as it did with last source). Anything else you need from me?

Did a fresh git clone from your source and compiled that.

C

I just apply patches to code. I have no clue about the actual wine code, so I cannot really help you diagnose problems. I know that I got it working again with those 2 commits. However, I simply don't have the time or interest to play WoW in the current state; Missing ground textures with DX9 is annoying, low fps with DX11 is slideshow playing. I just wanted to see if I could get it running again.

Ok. I understand your lack of interest in playing WoW under Linux :)

Thx for the effort tho. We will possibly all end up at DX11 some point in the not-so-far future anyway i guess, so lets hope some performance will come with the release version of wine :)

C

Got it started when setting OS to WinXP.. Had it set to Win10 when testing some DX11 stuff, and did not really pay it much attention..

Yeah, the missing ground textures is damn annoying indeed...

C

Most times there a still some textures visible for example small bubble's on mistress.
I did MoS 2nd boss on mythic plus 12+ and it was a nightmare when the textures of shit were not visible.
What made things worse is that I was melee.

Yep, did some benchies today.
System:
Elementary OS based on Ubuntu 14.04
I7 2600K@4.2GHz - 16GB ram - Driver nVidia binary - 387.12
nVidia 970 4GB
IO scheduler - Deadline (For xanmod i used mq-deadline)

Wine settings:
export __GL_THREADED_OPTIMIZATIONS=1
export __GL_SYNC_TO_VBLANK=0
export STAGING_SHARED_MEMORY=1
export STAGING_WRITECOPY=1
export STAGING_RT_PRIORITY_SERVER=90

Registry settings:
HCU/Software/Wine/OpenGL/DisabledExtensions=GL_ARB_vertex_buffer_object2
HCU/Software/Wine/Direct3D/csmt=0x1
HCU/Software/Wine/Direct3D/VideoMemorySize=4096

WoW settings (Config.wtf)
SET worldPreloadNonCritical "0"
SET processAffinityMask "255"
SET gxTextureCacheSize "3072"

I did not disable addons, and ran with whatever i use - Bartender4, ClassTimer, DBM, Mapster, OmniCC, Pawn, ShadowedUnitFrames, Skada, TellMeWhen

Tested with different kernels and different Wine versions. Tests in DX9 was done at graphics level 7 - SSAO disabled (not supported) and Liquid detail=Low. GLSL=Disabled.
I did /timetest 1 from Shackle's Den -> Prepfoot (Listed as test #1), then back from Prepfoot -> Shackle's Den (Listed as test #2)
As last time, i scroll the camera into first person, so not to make the character viewdistance a factor.

2.0-Overwatch - Kernel 4.13.6 (From mainline)
#1
Min: 28.431
Max: 229.695
Avg: 111.071
#2
Min: 23.177
Max: 223.604
Avg: 97.770
--------------------------------------------------------
2.0-Overwatch - Kernel Liquorix-4.12.0-14.2
#1
Min: 28.263
Max: 248.077
Avg: 120.614
#2
Min: 17.596
Max: 235.627
Avg: 105.850
-------------------------------------------------------
2.0-Overwatch - Kernel 4.4.0-97 Release from Ubuntu
#1
Min: 16.980
Max: 242.248
Avg: 107.090
#2
Min: 19.588
Max: 231.498
Avg: 94.149
--------------------------------------------------------
2.0-Overwatch - Kernel 4.13.6-xanmod11
#1
Min: 36.719
Max: 244.810
Avg: 124.226
#2
Min: 26.038
Max: 226.244
Avg: 109.111
--------------------------------------------------------
2.18 - DX9 - Kernel 4.13.6 (Mainline)
#1
Min: 28.875
Max: 140.252
Avg: 75.125
#2
Min: 20.910
Max: 130.955
Avg: 67.726
-------------------------------------------------------
"Winner" - Xanmod.

Then i tested with 2.18-staging branch and DX11 - first one i compiled myself gcc-7.2. DX11 tests were done at graphics level 7 SSAO Enabled, and GLSL=Enabled in wine config.

2.18 - Kernel 4.13.6 Mainline
#1
Min: 10.360
Max: 112.736
Avg: 60.472
#2
Min: 15.651
Max: 107.234
Avg: 54.019
-------------------------------------------------------
2.18 - Kernel 4.13.6-xanmod11
#1
Min: 27.349
Max: 109.729
Avg: 63.763
#2
Min: 24.743
Max: 105.337
Avg: 57.376
------------------------------------------------------
2.18-staging (WineHQ official version) - Kernel 4.13.6-xanmod11
#1
Min: 10.110
Max: 108.053
Avg: 63.271
#2
Min: 19.752
Max: 102.439
Avg: 57.170
------------------------------------------------------

Not that huge a difference between my "self-compiled" version of 2.18-staging and the WineHQ one, but a frame is a frame. "Winner" was the xanmod kernel (both kernels was 4.13.6). Did not bother to test the 4.4 or Liquorix against 2.18-staging tho.

Any comparisons or comments?

C

Wow that's for the effort this must have taken!

I'm on Arch and will do a similar self-compile test and possibly a kernel test with xanmod. Out of interest, why did you disable GLSL for DX9 but enable it for DX11?

What did you use to track min/max/average fps in game?

GLSL is needed for DX11 afaik. Atleast i am not able to start WoW in DX11 mode with GLSL disabled. GLSL disabled yield a bit more performance, so ideally i'd like it disabled, but i guess some DX11 functions depend on it... atleast for World of Warcraft.

When you stand at the flightmaster, just type /timetest 1 , and you "enable" benchmark mode the next time you use a flightmaster. When you land at your destination, the min/max/avg is printed on screen :)

Remember to type /timetest 1 again before next benchmark, as landing auto-disables it.

C

Wine 2.18 staging - compiled with cflags -march=native -O2. FPS in ironforge on flying mount if 78-91, all settings match what I use in windows, including SSAO. Proprietary 387.12 nvidia, 16gig ram. amd FX 6300 Six core. Zotac Gefore GTX 970 4Gig.

Wine 2.0.2 OW patch, from Dox, source compiled, same Cflags. FPS in ironforge, 139-155.

Both tests run after clean installs of wine, to ensure no leftover code from one version messing with the other. Both test run using DX9. DX11 on 2.18 staging crashed to desktop, randomly. When I could get in, FPS in iron forge never topped 40. In the DX9 testing useGLSL is set to disabled. When set to enabled, both versions of wine lose around 25% in FPS and the character turning and moving is jumpy.

in summary, 2.0.2 OW Staging, compiled on my hardware, gives the best performance, almost on par with Windows 10, and well enough, that except to check addon updates from curse, I am staying on Linux to play WoW.

How about the missing textures from 7.3, do they still occur?

Yes, they do still occur. We need people in the US to post about it in their forum. "DX9 missing graphics, please fix".

I'm not sure it's a dx9 issue though. There are people I play with who use dx9 on windows and they can see these missing textures just fine. If it's an issue purely with wine, that makes it infinitely more fixable right?

I do not have windows myself, so I can't test it. I read on forums that people with windows on DX9 had the same missing textures. If someone reading this has both linux and windows can recheck missing textures with DX9, that would give us confirmation that it is only in Wine, then a winebug should be filed.

Good spot for checking is going Antoran Wastes, just to the left of Hope's Landing teleporter on the map, where there are spiders. Green goo drops from the sky and leaves a pool that gives a debuff of "Corrosive Acid" when you stand in it. With DX11 I can see it, with DX9 I cannot see it, but you can see that you are standing in it because you get the debuff.

Tested on Windows 10 Creator Edition, DX9 shows nothing, and DX11 shows the green goo, so it can be avoided. It means the problem is DX9 in WoW and has nothing to do with wine, any version, as far as I can tell.

IF Blizzard decides to move away from WinXP support, it will most likely mean DX9 is EOL, just as OpenGL is in the client. Textures with the OpenGL client is broken, and it COULD mean this is one of the first pointers towards broken textures for DX9.

If that happens, we are as it stands now up "that creek" when it comes to performance, as DX11 is a rather crappy experience atleast for me.

However, i was away a couple of weeks ago, and decided to install wow on my old 2012 model Macbook air... And i must say that even tho the settings was way lower (3 set as default), and fps around 30-35'ish, the experience was slightly smoother than 60-80 fps and wine. Its kinda sad that Apple did not go for Vulkan, as that would possibly kickstart a transition towards a Vulkan client which we all could really benefit from when it comes to Wine.

I dread the day i "have" to dualboot to windows-oh-my-god-10 :( Maybe ill just quit wow again over doing that... ugh :(

C

Interesting. Unfortunately I can't build wine-wow-2.0.2 on Arch due to Freetype issues (Error: Cannot open face courier.ttf). Do you know what causes the difference in the versions?

In DX11 at 4k on my Threadripper 1950X and 980Ti I get 40-60fps in even non graphical areas (was questing an alt in outlands and seeing drops down to 35!). Most of my settings are on high except for view distances which are 7. Prior to the patch I was on a slower Xeon X5670 and was getting better FPS. For me DX9 and DX11 give almost identical FPS. Can't imagine a CPU upgrade would cause a drop in FPS.

Has anyone had any luck getting OpenGL to work? My game launches but all the textures and lighting effects are messed up.

Afaik Blizzard has dropped support for OpenGL, and moved towards "Metal" for the MacOS client.

Even recent upgrade to OpenGL 4.6 for the nVidia driver and Wine 2.18 has shown no change in setting -opengl on the wow client when regards to trashed textures. I do not think they are going to do any work on OpenGL at all, as it was somewhat of a "pet project" for one of their devs that no longer work there, and is not officially supported (and has not been for some time).

C

youtu.be/syO5c-BhtrM

teste bug in mouse point
sorry my bad english

i need play wow 7.3 legion
need tutorial for install for play on linux
battle net no log...

Does anyone know if 2.18-staging has this bug? bugs.winehq.org/show_bug.cgi?id=43641 I had issues with wine-overwatch crashing on games that run fine with wine staging 2.17. (Endless Legend, Secret World Legends, and NWN2)

No it has not.

Awesome, thanks!

Just to let everyone know, the DRM has not been fixed for WoW if you try to use 2.17 wine. I have to use 2.02 compiled from the link Dox provided, and it seems to do well. DX9 should be chosen, and csmt should be enabled.

I use wine-staging 2.17 and it runs fine.
As long these arent in mainline wine wow wont work:
github.com/wine-compholio/wine-staging/commit/f1b1baf057bd8bf7f22bfdf3f6d982effaeab42a
github.com/wine-compholio/wine-staging/commit/467fed65016e85920a3a9906c443ef0de364983b

One issue we got is that to many spread false information.

Is there a way to get someone to delete my comment below, so as not to muddy things? For some reason the wine-staging repo was distributing 2.15 pre-patched as the most recent version. (2.17 you have to patch yourself, or did as of a few days ago.)

64-bit or 32-bit? I have installed wine 2.17 devel, and stafing, and when I launch 64 bit from my desktop shortcut, get Game Initialization Failed. I revert to 2.02 Staging, all is good.

Yeah, you need to use staging, since they're merging the overwatch patches into it.

Found and ran wine 2.17 staging, worked, but fps was lower than what I am getting in the 2.0.2. Both versions of wine are using DX9 as the setting in game. 2.0.2 with OW patch to bypass drm seems to be best choice for me, at this time. I will try to find 2.17 staging source, and compile it, to make a fair comparison. 2.0.2 was compiled from the source DOX linked in a previous post on here.

Dunno if it is related to Wine, or if its for "everyone" running dx9? Did not try it with DX11, but have experienced the graphics weirdness with both wow-2.0 and 2.0-overwatch sources.

Cant remember it was supposed to be like that tho, but my memory of Panda exp is rather old, so for all i know its supposed to look this weird...

pasteboard.co/GLIwR10.jpg

Bug or oki? :)

S

This happens for me as well and I think it's a d3d9 problem. Blizz is after all moving away from that so introducing updated effects may brake old ones...

I was hoping that when they fixed the Mac clients that used OpenGL, it would be fixed for us aswell. But today I'm still missing certain grounds effects, so I have this feeling they fixed it only in their OpenGL backend for Mac.

Question is now, does it happen in DX9 under Windows aswell? I don't have Windows, so I cannot check it at all.

If it is just for Linux+Wine, it could be a bug on Wine end aswell.

which ground effects are missing for you?
Maybe create a bug.

The OS X client uses another OpenGL backend that is only in this client.
See here:
us.battle.net/forums/en/wow/topic/20418713498#post-9
Originally the OpenGL backend was shared between Windows and Mac. The Mac OGL backend (GLL) was eventually forked during WotLK as it became hard for the mac team not break windows OpenGL and didn't want to maintain the largely unused windows OGL backend. The windows OGL backend remained largely untouched all they way though WoD in an OpenGL 2 state. The mac GLL backend meanwhile saw continuous development and WoD added experimental OpenGL 3.2 (which you had to enable from the console).
For legion, it was decided to drop DirectX shader model 2 support (almost impossible to maintain an extreme legacy path on a modern game). From DX's perspective, this only drops some very very old and long unsupported cards, but both OpenGL backends relied on the shader model 2 style path in the engine (ARB assembly shaders) and had to be updated. For the mac side, the OGL 2.1 path was removed and the 3.2 was enabled for the GLL backend and runs through the shader model 4 style path. Meanwhile, the windows OpenGL backend was completely rewritten, targeting OpenGL 4.2 (though I don't think it uses any major OGL 4.2 features, it's likely close to a OGL 3.3 backend). That being said, the windows OGL backend has had exactly 0 testing from quality assurance since it was rewritten and is very likely to have bugs. It is basically an unmaintained, modern backend.
While we're talking history of backends, I'll throw in metal. Metal was added as an experimental backend (not available to the public) in 6.2. Metal will be the default mac backend in legion for cards able to support it. It currently runs a shader model 4/5 hybrid path with development efforts to get more shader model 5 features working (esp with new features added in 10.12).

However i'm not shure about the metal backend.

I'm not talking about testing with OpenGL on Windows, but with DX9 on windows.

As for the ground effects missing? For example missing ground effects in ToS: Fel Fire at Gorgoth, no crashing wave at Mistress, weird ground effects at Harjatan, to name a few. There are multiple through the game.

Could be that a lot of stuff missing, but i cant tell cos i just came back, and its my first time in ToS... and never used Linux.

S

What i meant to say was that i just came back from a 6 month break, and last week was my first in ToS... so i am not that familiar with how the ground effects SHOULD be..

Also, that i havent run WoW in Windows for years now, so i cant really tell how stuff is supposed to be there either :P

S

ah than we mean the same things, before 7.3 the ground a affect for example at mistress had worked.
Also some ground effets look rather limited like this at harjatan:
www.dropbox.com/s/v761x9cnmsv3ky9/WoWScrnShot_090717_220546.jpg?dl=0

Yes, that weird shit! This was fixed for Mac users yesterday. But since we had exactly identical graphics as Mac users, I had hoped they would fix DX9 at the same time. Unfortunately no.

But I was assured it was going to get fixed. It is already pushed up the the developers.

at for me was an update like now: build number 24976 and now build number 25021

That was the fix for the Mac users.

I found this in forums, someone talking about it happening under Windows aswell:

eu.battle.net/forums/en/wow/topic/17616812948?page=3#post-58

I figure this is why they are stopping support for XP / Vista, so they can tell people to use DX11.

Good news! Talked to GM using Live Chat. A fix for DX9 is still incoming, developers are looking into it. He just couldn't give me a timeframe.

So we wait, again.

Nice!

Lets not hope it turns out to be one of those Blizzard oh' so often used "Soon" terms then :P

S

Sadly, the update's not live, yet. Hope it will come soon, running around like a headless chicken when bad invisible stuff is on the ground is not exactly fun..

I had another talk with a GM yesterday. It is a known issue, but not enough people are complaining about it in the forum. So the issue has "no traction", as he put it. Developers only have so much time, and prioritize issues that they think are important enough. So, tt will require some other people then me making a fuzz about it.

If you want to help get this fixed, open a thread on forum (US preferably, since that forum actually gets read by the devs.) Ask for: "Fix DX9, and if they are not going to do that, give us the ability to use pre 7.3 graphic with some Environment variable we can set in Config.wtf."

I had call with a german GM and he had no really idea about it, but in the end of the only someone that is from the US master race chosen by blizzard (ironic) wont reach the devs with something.
the EU forums wont read by someone near that stuff.
If you look at the recent problem with the Shadowcaster Voruun you see how far this gets, eg. in this case:
first both get working as intended and weeks later the US guys get an acknowledgement that there's a bug help and infos about an hotfix.

I'm currently workaround this by locking where the ground efffects are and avoiding them like hell and dont fail mechanics.

At the end of the I only want the that stuff works.
A fixed OGL render would be very cool.

Patched Staging 2.0 with only the "ntdll" patches from Awesie. This allows you to log in with 64bit using DX9 with CSMT, this time without crashing when liquid detail is set to Fair/Good/Ultra. Use "-d3d9" as additional command line argument, because DX11 doesn't work yet on 2.0.

github.com/IngeniousDox/wine-wow-2.0

NOTE: This is the same repo as I linked before. I renamed it and set a different master branch to signal that there is a new build out.

It would be lovely if some people can build and test it, since this is the first time I patched and released a version of Wine. I built it myself with "-march=native -O2", and I went to Ironforge next to a fountain to test water settings. I don't crash there, so I figure it works, but you never know.

Cheers,

Dox

Did a "git pull", and saw something update, but was not the usual ++++ ---- lines i tend to see when i do a pull..

Does it mean it actually updated? Or was it just a change of branch with nothing happening, and i need to do a new clone from the link above?

S

I started fresh. It is a new branch, I also set that branch as main branch. Just get a new copy. (Easiest)

(If you don't want to download again, just fetch the repo changes, and create a new tracking branch for wow-2.0 locally.)

The difference to the compiled binaries in /bin/ between the yesterdays just "git pull" compile vs. the "git clone" compile from the link you posted is none.

There IS however a binary difference between compiling the "old" source and the new one, so i guess it IS updated.

I tried setting water to "Good" (Think thats my recommended), and had a random crash after about an hour or so... (Think it was some memory cant be read or something in wow-64.exe) Cant guarantee it was that, but maybe its not fixed? All other settings that i use is the same tho.

S

I have a slight feeling that the previous "overwatch" source gives a bit better FPS overall than your patched version, so im currently back to using that. Especially it feels smoother when on Argus. Maybe some function with effects there?

One thing i noticed yesterday was that WoW now crashes when i exit - atleast after playing a while. Have not had a crash while playing (water on "low").

S

On the page here on WineHQ it sais:

"I recommend using the Gallium Nine Version of Wine along with the Gallium Nine Version of Mesa (Nouveau), this makes the Game run a lot faster."

Have you tried using Gallium Nine and Nouveau driver with recent WoW? Is it more stable and/or faster than using 2.0-CSMT patched version?

S

I cannot. I have a 970GTX with 4GB, and if I understand correctly, support for that has only just been added to Kernel 4.12. On top of that, it won't have power management, so it will run at lowest possible speed.

Gallium Nine is a perfect option if you have AMD. I would like to hear good stories about Nouveau before I even bother trying it myself with my nvidia card.

sorry, but good stories and nouveau, not two things that ever happen. fedora in release 27 will be using Nvidia proprietary, with nouveau as fallback. Most of the decent performance, including my own system is nvidia proprietary. I run 384.69 64 bit only, no 32 bit moudles, dkms installed for kernel updates, and currently running 4.12.11-300 on Fedora 26. I have 24 addons installed, used the self compiled patch from the 2.0 staging with liquid detail fixed overwatch patch, linked by Dox in a previous comment here. Dalaran sees me around 30 fps, Argus sees 45-65 even in combat, with several demons at once. DX9 Setting in game at 7, SSAO disabled is the only adjustment, since opengl does not seem to like SSAO. running 64 bit client, and command line launcher. Battle.net also installed, and works, but i prefer the command line launcher, for better control. I have created a desktop shortcut, and I run the GTX 970 4gb OC. I used sudo nvidia-xconfig --cool-bits=12 in terminal to enable power and fan speed control in nvidia settings. my command line for my desktop shortcut is:

env WINEDEBUG=-all STAGING_SHARED_MEMORY=1 STAGING_WRITECOPY=1 STAGING_RT_PRIORITY_SERVER=90 nice -15 wine64 "C:\\Program Files (x86)\\World of Warcraft\\Wow-64.exe" >$/dev/null

word wrapped here, but a single line in the command line box, for the desktop shortcut. The only issue i have, is the window launches minimized and I just alt-tab to it, and it goes full screen. I run Fullscreen at 1680x1050 in game. winetrick settings, glsl disabled, csmt enabled (just in case) render set to opengl. hope this helps you enjoy the game. I do still boot to windows, to update addons, but 90 percent of my game time is in Linux now, with decent fps and all the nice perks linux affords.

I basically run it the same, but through Blizzard App for easy login. I have the same 970GTX with 4gb as you, with the same 384.69 nvidia prop driver. However I use DX9, since CSMT only has use with DX9. 2560x1440 with basically 7 aswell, capped at 66 fps seconds most of the time, running OpenGL triplebuffer from Xorg.conf. Scaling down doesn't seems to have an effect at all on fps. I do have a raid setting to lower shadows and particle density during raids.

I'm just going to repeat, the Overwatch branch is the old branch. The WoW-2.0 branch fixes the liquid detail crash.

I'll try the "export STAGING_WRITECOPY=1" to see if it has any improvements..

I have GTX970 4GB and a old I7 2600K, 16GB ram, so by no means a "super computer".. Put the slider on 10, but set water to LOW, and viewdistance to 3, makes me have great FPS most of the time.. Dips to 40'ish during raids tho, but not too shabby. That is with the "old" overwatch 2.0 branch from before. The "new" branch gives slightly less fps, and somehow introduces some random stuttering even tho i have 80-100 fps... DX9 and CSMT ofc, and 64 bit wow.

Oh, and i run Elementary 0.3 (Ubuntu 14.04), with kernel 4.12(Xanmod), and nVidia 384.69 proprietary drivers.

The 2.16-staging does work with DX11, but the 2.0 branch does not. Horrible fps tho.. 20-25fps in dala vs. 40-45 with the "old" branch.

I did test with WoW-2.0 branch and liquid to "Good", but had a couple of random crashes. Switched back to the overwatch branch, and "Low", and not had any troubles.

S

As to the liquid "fix", i dunno, but i have never instantly crashed either with 2.16-staging or the Overwatch branch, or the new wow-2.0 branch when setting liquid to higher than "Low". When i started playing again couple of weeks ago i started with 2.15-staging and had to use 32-bit, and tested both DX11, and DX9. Not that huge a difference, but set the liquid to recommended "Good". Had some random crashes and memory errors after playing a while... usually like 2-3 hours or so.

After starting using the overwatch branch and 64-bit client and dx9 with liquid set to "Low", i have not had any crashes, and have decent enough fps to not feel hindered when playing. I have better fps with that than what i had with 2.0-rc6 back in february or so, even after 2.1 release i kept using the 2.0-rc6 as it had the "old" CSMT patches, and a lot better fps.. the overwatch branch seems to have some additional patches, cos i have better fps than i remember having back in february, but then again, it could just be fewer ppl around playing WoW theese days than it was in february :P

I can agree that perceived fps vs. actual fps MAY be just a placebo effect when comparing your wow-2.0 branch vs. the 2.0-overwatch branch, and ofc setting water to "Good" WILL most likely be what tips the fps meter a bit down again (after all, its more effects = more strain). But, as i said before, i have crashed a couple of random times with liquid to "Good" even with this branch. Is it just totally bad luck on my part, and that could just aswell have happened with liquid to Low? I usually play for 2-3 hours when i do a session...

Will be interesting to see if ground effects that i cant really tell if im missing or not (cos i probably never have seen how it is supposed to look) will be fixed in some upcoming minor patch, and if this breaks anything tho :)

And from what was posted earlier here, gallium-nine and nVidia is really not recommended even tho i have a GTX970 and kernel 4.12?

S

Trying to shortly cover all your points:

- You can simply test if you crashing has to do with Liquid bug due to OW branch, in a spot I use in IF: Just keep it to low, port to IF, walk out of that room, there is a fountain there. Set it to Fair / Good / Ultra, and crash.
- 2.16 staging doesn't crash since it doesn't have the OW patches, so you won't notice it there. (Unless you used 32 bit, see next point)
- 32 bit you can run out of Memory indeed, you get it faster if you increase view distance. This is I believe about the ~4gb limit max 1 program can use in 32 bit.
- You have a Nvidia like me, even setting Liquid detail from Low to Fair will dip fps, especially in places with liquid details (this includes lava, fel lava, and other things that are called Liquids - so not just water). Good even more. Etc
- If you compiled yourself this time, compared to downloading Wine as a binary before, you will have faster code. Esp if you use "-march=native -02", and use GCC7.1.
- If did some of the tweaks I said, they really help, could have given you more fps compared to when you played before.

About Nouveau: It lacks fancontrol and power management, so you could fry your card, or it will just run at low Mhz. (See, nouveau.freedesktop.org/wiki/FeatureMatrix/)

1. I do not crash instantly when setting liquid to Fair/Good/Ultra. The water effects do indeed change as it should. Tested multiple times at several places in StormWind (Assuming you mean the fountain in the dwarven district?), and by the canals in SW. No problem switching back and forth. This is with the "Overwatch" branch, BUT this is compiled from YOUR previous github BEFORE you changed the "master branch" thingy to the "wow" version.

2. Have not tested 2.16 and this water thing, but when i started playing with 2.15-staging (couple of weeks back), i had to run 32-bit and did indeed get the "out of memory" error.

3. Se #2

4. Yeah, agree. So may aswell be what is fooling me when i tested... and eventually get a crash 2-3 hours playtime. Have not happened when setting "Low" on liquid tho.

5. Hmm.. i seem to be using gcc 6.3.0 (atleast if i type gcc --version), but i have gcc 7.2.0 installed and is what i had to use to get 4.12 kernel up and running with nVidia binary blob (DKMS auto compile module uses that afaik). Cant say im that familiar with compiling, other than following instructions and howto's, so any way i can check what compiler i have used when compiling the source?

6. Yep, i have added a couple of more tweaks that i did not use back in february - STAGING_SHARED_MEMORY, STAGING_WRITECOPY and STAGING_RT_PRIORITY_SERVER options is new this time around, so that might just aswell be what is contributing to a wee bit more fps than when i used 2.0-rc6 back in february :)

Will wait a bit with Nouveau until i am sure 4.12 kernel fully support clocking and fan control. (I read something on Phoronix in may about 4.12 having clock control tho, so kiiinda thought it was working as intended theese days with 4.12 kernel).

S

Ooo...

Guess i needed to do some fancy config with update-alternatives on my ubuntu distro to make gcc-7 the default compiler :) Gonna do a recompile from your wow-2.0 branch, and keep liquid on low to see if its possible to get a twitch of a fps more from that :)

S

IF = Ironforge, fountain just outside after you leave the portal room.

Hehe.. yeah... Doh, sorry :P

In other words, liquid is not liquid, as it depends on where the liquid is i guess :P

Yeah, confirmed.. 2.0-Overwatch crashed hard at the fountain in IF, but not the wow-2.0 branch :)

Thx!

S

PS. Gonna give it another go at liquid set to "Good" then. Oh, and now with wow-2.0 compiled using gcc-7.2.0 :)

I think you are experiencing a placebo effect. They are both the same source:

overwatch-2.0 branch: Staging 2.0 with all Awesies patches on top (which changes some stuff for DX11 in d3d that breaks liquid detail.)

wow-2.0 branch: Staging 2.0 with only the ntdll patches from Awesie. (which leaves those changes to DX11 out.)

In other words: The FPS should be exactly the same with either, only the difference is that by 1 you are forced to set liquid detail to low. Liquid detail takes a lot from your GPU, so you might notice fps gains from just doing that.

Dox

PS: I haven't crashed at all, so I'm wondering if you are actually building the wow-2.0 branch in the first place. Perhaps start fresh in a new directory, clone fresh, and try again?

I least for instances like Firelands wow crashed for ever when entering it when using the overwatch branch.

Just going to repeat, the Overwatch branch is old. Just rebuild, with a new build, the wow-2.0 branch from the repo:

github.com/IngeniousDox/wine-wow-2.0

It is a different branch, and will fix your crash with liquid settings. (Molten lava is a liquid you know).

"PS: I haven't crashed at all, so I'm wondering if you are actually building the wow-2.0 branch in the first place. Perhaps start fresh in a new directory, clone fresh, and try again?"

As i wrote before, i did a new clone from the link you posted :)

S

Do you have a complete overview over what is the total difference between "your" wow-2.0 patched version vs. the previous 2.0-overwatch version that used to be available?

I know you want to pin the "you are full of B*S" thing on me when i say that i FEEL there is more fps/less stuttering using the "old" source vs. this new patched one. But i still claim it hehe. I have set the liquid detail to "Low" on both, and i have both sourced compiled for use.

1. I have had random crashes and even had a disconnect using wow-2.0 - Could ofc be just random bad luck, but i tend to play 2-4 hours at a time when first playing.
2. wow-2.0 seem to have more stutter/less fps on Argus than the other 2.0-overwatch patch. There should be no reason for that, but still i "feel" it is so. Cant really meassure for sure.

The source tree from the Gamax92 git repo with the 2.0-overwatch patches i cant figure out how to download. When i choose -b overwatch-2.0 when i do a clone, its the same as your wow-2.0. Dunno if it is cos i cant figure out how to use git, or if the patches are just replaced. One thing is that when i compile the source the binaries is the same as wow-2.0, but my 2.0-overwarch binaries are different.

S

This is the repo I got the patches from Awesies repo, it is based on Wine 2.0 (so not on staging): bitbucket.org/awesie/wine-overwatch/commits/all

Basically Gamax used all of them (clumped in 1 big patch) to create Overwatch-2.0. This contains the code that results in the liquid crash. I was more restricted, and just took the patches that had to do with "ntdll" so we can log in, you can see which by checking out the WoW2.0 branch, since I commited the individual commits. Both me and Gamax applied them on top of Staging 2.0.

Now, there are some commits that change some stuff in d3d9, that I didn't apply, so it could be possible that those have an effect for you. You could try applying them and see if you get more fps. According to the bug report about the liquid details, this is the commit that *probably* causes the crash:

bitbucket.org/awesie/wine-overwatch/commits/c218450374b8fd4926ae0403d7fa56ef79b7ddac

Which in fact is 1 of the last d3d patches in the line. (So you just don't apply that or fix it). There are only 3 more afterwards, don't know if they need the code, or if you can just use them.

Let me know if you get more fps without liquid details crashing. And I'll add them on top of the wow branch.

Seems indeed like a daunting task, to commit all those patches, so id rather not figure out how to do that exactly...

In other words: Im waaay too much of a noob to get a non-patched staging-2.0, and apply what to me seems like a endless list of patches i really cant figure out is for 2.0 or not..

How many ppl is running the 2.0 branch vs. 2.16 "official" one with wine you think? Would be nice to hear from someone else using this with WoW aswell, just so its not only one sided claims from me :)

S

I am running from the link Dox shared, with 2.0 staging, and liquid detail fixed. Downloaded and compiled the using the wow64 build setup linked in the winehq.com website, on my AMD FX 6300 6 core. I have a GTX970 4G DDR5. I compiled the system, after using export CFLAGS="-march=native -O2" so that the compiler built the binaries for my cpu. I run 24 addons in game, same as my windows 10 setup, and I manage 35 FPS in Dalaran, 50+ on argus, even in combat, and no drops in dungeons or raids. Settings are at 7 and I even left ssao enabled. I see slightly lower FPS than my windows 10 WoW experience, but not enough to bother me. I have csmt on, glsl disabled, and other env var on my command line. see one of my previous comment in this thread for the desktop shortcut command line that I use. Hope this clears up some confusion. I ran against 2.16 and the fps in DX9 was worse on 2.16. Even compiled the source, and it still was not as good. See that 2.17 is out, may try it this weekend.

I have set my viewdistance down to 3 to not get those dips when i fly over large zones.

The day 2.x release has the same DX11 performance as 2.0 has in DX9, id be really happy :) I see there is improvements in the staging sources each release, but i kinda think they will never implement CSMT stuff in that sourcetree ever, so not sure how its gonna turn out.

If i try to start with 2.16-staging, and GLSL disabled, i get a error message about not being able to create 3D something, so i have to have it enabled with 2.16-staging. Disabled in 2.0 gives best performance.

S

Viewdistance issues, try fiddling setting:

SET worldPreloadNonCritical "0"

And fiddling with:

SET gxTextureCacheSize

wowwiki.wikia.com/wiki/CVar_gxTextureCacheSize

About GLSL, it used to help a lot to disable it. I always just did, but since I was revisiting stuff anyways....it feels like it isn't needed anymore. NVidia driver has gotten way better at it. See also: www.phoronix.com/scan.php?page=news_item&px=NVIDIA-378.09-Beta-Linux

I plan to do some /timetest 1 tests to confirm. But just haven't gotten around to it. wowwiki.wikia.com/wiki/Taxi_Time_Test

SET worldPreloadNonCritical "0" improves loading times when zoning into eg. Dalaran and such.. With the default "1", wow loads a lot slower. From what i gather is that it kinda loads textures "on the fly" a bit more after you move in, rather than load everything before you zone in.

This is a issue not exclusively related to wine tho, as the battle.net forums is loaded with ppl setting this due to slow loading times in windows, and it helped a buddy of mine aswell, and he is using Win10.

When it comes to gxTextureCacheSize its a bit more hit & miss. I used to have it at 1024, but set it to 2047 per your previous recommendation. I might try to put it back to 1024 perhaps. Wow does not utilize gfx mem on my card at all enough to my taste... I dont think it will in windows either, and perhaps even less when using dx9. Removing it or setting it to 4096 (what i have physically) does cause slightly worse performance tho. I have never seen wow use more than around 800'ish MB regardless of setting this to 1024 -> 4096

I have done a bit of twiddelig with the viewdistance in the past, and setting it to 10 or near max will lower the fps when i overlook from high (eg. flying high above a populated Dalaran or the likes). Putting it to 3 is just a preferred issue to not have those dips in fps when flying overhead, and kinda dont bother me much tho. But i can do some testing what that taxi_time_test thingy if i manage to reproduce a stable fps in low-pop areas. The reason? Cos having 10 players vs. 400 players "randomly" will also create randomly differences in fps :)

S

You shouldn't set it to 2047 because of my recommendation. That is just the setting that works for me. But I figured that out by finding a spot in Suramar where I would lag when I turned my camera around. Then just bisecting to get to 2047. You have to check it for your own setup (like it says in the blue post).

PS: I did find it very weird that it is just below "2048" and I assume it has something to do with something the index table for the texturescache in WoW, which slows down if you get more then 2GB for GPU Ram while using DX9. Though, this could be just me jumping to a conclusion.

Yeah, i agree. Wow dx9 engine is a old one, and i guess when most tweaks and fiddling in general was done with it, it was not "normal" to have more than 2GB of vram... So it might be some optimizing that has been done towards that end? Dunno...

Did some benchies tho, and cant conclusively say one thing or another, but anyway. The tests was done by the following setup:

1. Gfx settings set to 7 - liquid detail set to "low"
2. I am running 1080P setup in windowed mode (i run a dualscreen setup in Linux, so need that)
3. Tests were done by scrolling all the way in to "first person view", did not move the mouse or "looked around" while flying
4. Tested by flying from "Hafr Fjall" in Stormheim -> "Meredil" in Suramar. Wrote down the results. Fly the same route back. Added the individual results together and divided by 2 to get a average for min/max/avg.
5. The command is "timetest 1".. it auto-disables when you land.

Results:
1024 gxTextureCache - wow-2.0 branch
min: 18.6
max: 188
avg: 84.4

2047 gxTextureCache - wow-2.0 branch
min: 14.7
max: 183.6
avg: 83.1

"Auto" (deleted the setting from Config.wtf) gxTextureCache - wow-2.0 branch
min: 15.8
max: 193.1
avg: 83.2
---
1024 gxTextureCache - 2.0-overwatch branch
min: 20.2
max: 185.8
avg: 85

2047 gxTextureCache - 2.0-overwatch branch
min: 16.6
max: 186.9
avg: 82.9

"Auto" gxTextureCache - 2.0-overwatch branch
min: 14.9
max: 187.1
avg: 83

Also did a round with GLSL Enabled, and it made for a "choppy" run, although not incredibly low average.. but clearly visible stuttering

1024 gxTextureCache - wow-2.0 branch - GLSL Enabled
min: 19.2
max: 177.5
avg: 84.2

Cant conclude one or the other tbh, and it might be better ways to test it perhaps? To me, id say its a miniscule difference between the wow-2.0 branch and the "old" 2.0-overwatch one (although i must admit i lost the source to it, and cant figure out how to get it back.. cos i compiled with gcc-6.3 and not gcc-7.2.. Dunno if it would make a difference tho, but would be nice to test)

I will keep my gxTextureCache settings to 1024 for the time being, as it seems to me it gave a couple of more fps on my rig. The "Auto" one seemed to be slightly better than 2047, so for all i know, it may default to 1024? Only the blizzard coders know i guess :P I did not test with liquid set to "Good", as it might have crashed the overwatch branch, so for comparison alone, i set it the same :) If you want better water effects, wow-2.0 is the best way to go there, as in a benchmark point of view for fps the results are equal. However, i personally feel it introduces some "microstutters" i dont have with the other source, much in the same way as enabling GLSL introduces a LOT of heavy stutters (for me), without really ruining the benchmark results. My oppinion tho :)

S

Since the latest update (2.16), Wow works again with normal wine-staging and liquid effects can bet set to more than low (for the 64bit client).

Good to know. I'll build it later.

Setting Liquid to Low is/was needed due to the OW patches from Awesie, I poked Gamax about the bug. But if WoW users can log in now with vanilla Staging, OW users should be able to do the same. Will check.

Well, I tested Staging 2.16. d3d11 feels really smooth atm. Even though it give only around 30 fps for me. It even feels better then d3d9 with the same 2.16.

Still not the same FPS as Staging 2.0 with d3d9 though. So ideally, if someone has the time / expertise to patch Staging 2.0 with the Staging 2.16 "Added 64 bit syscall thunks in fake ntdll.dll" patches, that would be the ideal.

Thanks a lot.
Actually switching to 2.15-staging (using this site wiki.winehq.org/Ubuntu) was quite easy but it always caused a memory error.
Surprisingly i could solve that (or at least reduce the appearance of that error to a bearable minimum) by switching winecfg from XP to Windows 7.

I can't say it's working like it did before - framerate sometimes drops very low and the mouse input sometimes acts really strange, but at least it's playable.
Maybe this might help someone.

"It's a bit annoying that ppl doenst read."
Thanks.

"Second it's hard to support any wrapper like lutrius if someone gets problems.
It's like playonlinux unsupported here. "
Hmmm...neither my post or the post I replied to referred (other than in passing) to wrapper. My post mentions I used Lutris then ripped everything out and started from scratch (without Lutris).

"The 64bit Client works with direct X 9 render as long liquid details are up to low.
See that submitted bugs for this app before the comments."
Unconfirmed bug...I can certainly test that tonight in my many personal investigations. I barely had time to test and out of the box install of Wine / WoW.

I went to the same round of testing as you. I'll summarize:

On Ubuntu I started with installing Wine Staging so I had a wine version installed. Here are ways you can log in.

1) Used Staging 2.15 - and launch 32 bit with command line option -d3d11. Very low fps, very laggy.
2) I then tried using Staging 2.15 - and launch 32 bit with command line option -d3d9, but I crashed before the game loaded.
3) Used Staging 2.15 with Overwatch Patches. This will allow you start 64 bit with -d3d11, I found it slightly better then 32 bit.
4) Used Staging 2.15 with Overwatch Patches. Again 64bit, this time with -d3d9, you have to set Liquid effects to Low or you crash sometimes. It is again slightly faster the other option.
5) Got Gamax to patch 2.0 with OW patches. See my wall of text below for more details. You run it with -d3d9, and set liquid details to low again. This gives absolutely superior fps.

Dox


NOTE: You can get the Staging 2.0 and/or Staging 2.15 with OW patches multiple ways:

- I compiled them myself from the Gamax repo.
- You can install them with Lutris (I did that aswell, and made an installer available for others).
- Or you can use the the runner from Lutris without installing Lutris itself, but then you have to manage your runners yourself, something Lutris handles for you otherwise.

NOTE 2: I used CSMT + __GL_THREADED_OPTIMIZATIONS + STAGING_SHARED_MEMORY=1 + STAGING_RT_PRIORITY_SERVER=90 + disable GLSL + OpenGL DisabledExtensions "GL_ARB_vertex_buffer_object2".

I also used the following additions to Config.wtf:

- SET worldPreloadNonCritical "0": Faster loading screens.

- SET gxTextureCacheSize "2047: A setting for d3d9, with 4gb Vid card this seems to work the best. Setting it higher then that makes the game slightly laggier in places like Suramar. You can fiddle with it ingame and then turn camera around to see if it gets smoother, since you have to find a value that works for your Video Card. Use: /console gxTextureCacheSize setting to change it. (More info / Copy of old Blue Post: wowwiki.wikia.com/wiki/CVar_gxTextureCacheSize)

Link in last post didn't format correctly, because of the ) at the end: wowwiki.wikia.com/wiki/CVar_gxTextureCacheSize

running 2.0 with ow patch, seems to do fine. Just a question, are the Staging settings env or reg?

Hey! I'm glad someone is using it. I see you are maintainer of the App WoW here aswell. Perhaps we can get together a good howto, and consolidate some settings for increasing FPS?

Anyways, you can read more about it here:

github.com/wine-compholio/wine-staging/wiki/Environment-Variables

Remember that you have to give yourself rights to increase priority, it is all described there. Reason for me to use it is because I have 4 cores. With CSMT + NV Threaded, 3 of those cores are fully used most of the time, the 4th core has sound / chat / wineserver / rest of OS running. By giving the Wineserver realtime prio you can stop some FPS dips when WoW needs something from Wineserver.

Running nvidia proprietary 384.69. according to readme in the driver, the threaded is now enabled by default, so the env var is not needed.

Thanks a lot for your instructions Dox!

Ended up compiling it myself, from the "mirror" link you posted below, as the main link could not be pulled, and the pre-compiled version you posted could not log on (some BLZxxxx error message after trying to log in)

A LOT smoother fps than the release 2.15-staging with d3d9. Back to what i'd say is the 2.0-rc6 i used before i quit last time (7.0-7.1 patch i think). 7.3 broke that branch without the patches, so im very happy someone takes the time to patch the old branch with "working" CSMT :P I have 40'ish fps in a populated Dala, and peaks well past 100'eds in world. I have set water to "low", and viewrange to 3... Shadows to "high", and the rest to max.

Im using POL btw, and popping in the custom wine version is probably just as easy as in Lutris :)

S

You're welcome. I didn't do the patching, the credit goes to Gamax92. If you want to clone out of his repo, you have to clone with "-b branch --single-branch", I just forked the repo and made it the main branch to make it easier for people. And what do you know? It does!

2.0-rc6 and 2.0 should have the same CSMT implementation, it was 2.1 where it was changed.

About FPS, you can really get some more fps if you do the little tweaks. I wrote about most of them above, but I haven't talked about NVidia settings (if you have it): I turn on triple buffer in xorg, and force full composition pipeline to stop tearing. OpenGL triplebuffer works better then adding VSync+Triplebuffer ingame with d3d9.

Dox


PS: I started using Lutris next to PoL when they had the OW runner. Now I have fully switched over to Lutris. Just like every program you have to learn to use it, but once you do you notice how easy it is. I find it easier then PoL atm.

Yeah, i am using the different nVidia tweaks, as you posted and a few custom ones in my xorg.conf :)

Not that familiar with git really, other than cloning a repo and doing the "git pull" to update any patches... Does your fork keep that 2.0-ow version "up-to-date" if any patches appear?

Another thing i forgot to mention i had to do to get my self-compile working was that i only built the amd64 version, so i had to make a symlink to "wine" from "wine64" in the /bin/ folder of my winebuild result..

Lutris/POL is just a gui to make switching between prefixes and different wine versions easy... AND come with different installer-scripts for predefined games/whatever. Haven't tested Lutris, and i mostly just use Wine to run WoW, so can't really see a reason to make it "even easier" as its dirt-easy as it is :P

To those interested in installing a custom wine in POL, you just put your compiled result (ie. when you compile wine with ./configure prefix=$HOME/your_folder) under $HOME/.PlayOnLinux/wine/linux-amd64/your_folder and when you start POL it shows up automagically as "your_folder" under wine versions. (PS. Look above if you only compile 64-bit version tho..)

S

My repo is just a clone of Gamax's repo, just with another branch set as master. This branch won't be changed at all. It is just a branch based on Staging 2.0 with all OW patches applied.

Unfortunately, since it has all the patches, it also gets the wine3d code changed. That is actually what introduces the crash with higher then low liquid detail. So, what we need now is: Staging 2.0 patched with only the ntdll patches, either the original from Awesie in the overwatch branch. Or the ones now in Staging 2.16.

When i try to start Wow.exe (the main game, not the launcher) i get the error
fixme:d3d:wined3d_check_device_multisample_type multisample_type 32 not handled yet
and i end up with a transparent screen and the warcraft mouse cursor and nothing else happens.
Is there any solution for this? When i google it i only find people who say "install lutris", which i won't cause i don't trust it.
I'm running wine-2.4 (Staging) on Linux Mint 18.1 which worked superb until Blizzard came up with Patch 7.3.0

If there isn't any fix for now, is there any help in sight?
Thanks for help

Temporary workaround for 2.14-staging and 2.15-staging is to run the 32-bit client, or run in XP mode (which forces the 32-bit client implicitly) but then the memory leak returns. :(

Update to wine-2.15 and use the 32bit client, it works fine (bad performance though).

Just adding some information that is in my brain here at the WineHQ WoW page. Feels like this is a good as place as any to post it. I cannot post in US forums, and EU forums linux talk is minimal. I'm sure someone will spot this.

First of all, It has been a while since I looked here, since my setup has been working great for a few years now. I have this for reference:

Intel® Core™ i5-4670K CPU @ 3.40GHz × 4 - OCed @ 4ghz with 16gb RAM
Geforce GTX970 with 4GB with 2560x1440 screen
Ubuntu 16.04 with Gnome-Shell / AwesomeWM

I have been using DX9 with Wine Staging CSMT + __GL_THREADED_OPTIMIZATIONS (Nvidia) for a long time now. This is giving me 60 fps on setting 7, with some dropping below that in raids, but this is normal. I kept using newer versions of Wine Staging till 2.0, and I stuck on that. Why? Because from 2.1 the CSMT was stripped of some performance hacks to make it work with DX11. I figure most people would stay on 2.0 with WoW, but from what I have read while I was looking for solutions for 7.3 drama it seems a lot of people actually went and kept following each new staging build. The difference in FPS is very noticable in DX9, and even more if you compare current DX11+CSMT with 2.0-DX9+CSMT.

Now I'm posting, because through the Linux_Gaming_Group, specifically the Lutris channel, I was already in contact with gamax92. He keeps the Overwatch repo going with the Awesie OW patches. I asked him if it was possible to apply those patches to to 2.0. And he said: Yes! and took the time patch it into Wine Staging 2.0 for me to play around with. Thanks Gamax92/Awesie! Now I'm trying to pass on some love here.

The Github branch in his repo is: github.com/gamax92/wine-overwatch/tree/overwatch-2.0
A clone, with that branch set as master is here: github.com/IngeniousDox/wine-overwatch-2.0

You can compile it yourself if you want, this will give you the most FPS for your buck. I suggest reading up on the Wine Wiki how to build your own. I ended up using "-march=native -O2" as compiler flags, tried -O3 but it felt worse.

If you don't want to build it yourself, which I fully understand, I also got Strider (The creator of Lutris) to run and host the build. I created 2 installer scripts myself, 1 for DX9 with now working again Wine Staging 2.0, and 1 for DX11 that uses Wine Staging 2.15 Overwatch. This way I can easily switch between the two versions, I use the DX9 if I want speed (I'm sure the graphical issues will get resolved, the crashing can be stopped by setting Liquid detail to low). And if I want DX11 I just start the other 1.

You can get Lutris here: lutris.net
You can find the WoW installers here: lutris.net/games/world-of-warcraft/

DISCLAIMER: I'm just a user of Lutris, it isn't my program, but I do play multiple Blizzard games. Having Lutris makes it easier to keep clean wine prefixes for each game. And a good 1 click installer if I want a new prefix to fiddle with is even better. But for those sceptics, that still want to get fps, here goes:

A direct link to the Runner for working WineStaging2.0: lutris.net/files/runners/wine-wow-2.0-x86_64.tar.gz (I'm sure someone else would have commented with this link if I didn't post it)

I hope this post helps some people out there that just want to play World of Warcraft on Linux with good FPS. I know there is some nice CSMT work incoming in staging from glancing over the submitted patches. So at some point I'll switch over. But for now, I'm enjoying my high fps on Wine Staging 2.0, and I hope you will 2.

Cheers,

Dox


PS: There are more tweaks you can do then these basics, but this post has gotten 2 long already. If people are interested I will make a small followup post. Or you can hit me up on Discord "Linux_Gamers_Group".

Lutris is not my program O.O. I literally organised then copy and pasted the comments from the WoW forum... because it worked for me and I thought hq-people wanted a quick fix for the patch.

I also have been getting dropouts in old zones, its fine within new dalaran, argus, etc. But I've had drop outs in one damn dungeon twice in timewalking dungeons, old dalaran and this one same place downstairs in orgrimmar over and over when I fly into the same spot. Again as people have commented, lots of windows users are getting this issue also. I would expect that because its new infrastructure, they might be trialing some things. There has been lots of resets this week so might be implementing some fixes hopefully.

Hoping even more heavily that the next issue of staging has a fix, if the dropouts are caused by the lutris overlay of wine... If this fix is implimented by wine, it would also amazingly solve the overwatch bugs id imagine and make it playable on straight wine staging.

What solved the crashes to me is putting my water to low. See also: bugs.winehq.org/show_bug.cgi?id=43641

I don't know if this helps anyone or not, but here are my observations..... I run on Ubuntu xenial with a Nvidia GTX 560. Have had 64-bit Wow running great for years.

Wine 2.16. Launcher works, Wow won't start from the launcher. Starting it by runnint Wow-64.exe yields a dialog box saying "Game Initialization Failed!"

Wine 2.15 Yields the same results as above.

overwatch-2.15-x86_64 - Launcher and Wow work and run ok using D3d 11, though performance isn't that great. It's usable in the short term but nothing like running Wow with Wine2.16 last week.

This mirrors my own experience with Debian Jessie based antiX Linux. WoW 7.2 worked perfectly well with reasonable to good performance, comparable to Windows with my creaking Nvidia GTX790. All was good until 30th August: Patch 7.3. With Wine 2.16. Launcher worked, WoW wouldn't start from the launcher. Starting it directly with Wow-64.exe (or Wow.exe) returned a dialog box saying "Game Initialization Failed!"

I tried Lutris and tbh I got in a mess with it. I'm pretty good at following instructions but there were too many gaps and assumptions for a new user (I will install a test OS and fiddle). I ripped everything out and started fresh. I installed Wine Staging (I've always used -devel to date, but all guides seems to use -staging so...) 2.16 and Set the Blizzard App Launcher to Windows XP with the 7 dll overrides I've used historically (it would not install/run without them). Now I can launch WoW with the launcher but trying to launch the Wow-64.exe (or Wow.exe) directly still returns "Game Initialization Failed!" (with or without dll overrides, setting Windows version as XP/7/10).

I set 'use 32 bit version of game' in the Blizzard App launcher and the game will launch, it crashes two or three times then I can log in. Performance is 'clippy' but FPS is low average. Playable in low graphical intensity environments. I have to disable hardware mouse and that gives me a visible, if flat, single colour grey, mouse. I can use either DX9 or DX11, DX9 performance is marginally better, I need to set graphic quailty low, 1 really to make the game anything like approaching playable. I ran out of time last night for further test.

Tonight: reinstall antiX, Debian Testing and Ubuntu. Install latest Nvidia drivers, wine-staging 2.0 and 2.16 and -devel 2.0 and 2.16. I also intend a Lutris install so I can juse that until we get changes baked into Wine that address whatever changes Blizzard has made to their game client. I look forward to skipping into WoW direct with the App and experiencing reasonable FPS again soon.

It's a bit annoying that ppl doenst read.
But I think it's easy to oversea something with so much stuff that is posted here.

Second it's hard to support any wrapper like lutrius if someone gets problems.
It's like playonlinux unsupported here.

The 64bit Client works with direct X 9 render as long liquid details are up to low.
See that submitted bugs for this app before the comments.

"The 64bit Client works with direct X 9 render as long liquid details are up to low. "
Well, like I said "I can use either DX9 or DX11, DX9 performance is marginally better, I need to set graphic quality low, 1 really to make the game anything like approaching playable. I ran out of time last night for further test. " Setting graphics low, 1, will put Liquid detail to low. And switching off Options | Game Settings | Launch 32-bit client (instead of 64-bit) returns the same Wine Error as trying to launch the game direct: "Game Initialisation Failed."

"It's a bit annoying that ppl doenst read." I agree -.-

AMD 8350
Nvidia 970, Proprietary drivers current.
Fedora 25

*add to config.wtf
SET worldPreloadNonCritical "0"
(fixes long load screen wait issues)
* env variables or hide them in a script
export __GL_THREADED_OPTIMIZATIONS=1
export __GL_SYNC_TO_VBLANK=0
winetricks glsl=enabled
winetricks vsm=3
winetricks gsm=3
winetricks videomemorysize=4096

* winecfg
wine-staging 2.15 ->CSMT on, VAAPI on
wine set to windows 10
(if your launcher doesn't display tiled inserts, run it with wine set to XP mode once, all the way to character login screen, then switch back, also -- make *sure* that both mono and gecko install in a new prefix -- I've noted that the automated install in staging often breaks and doesn't complete the registry entries)

wine64 to launch BattleNet launcher or World of Warcraft launcher ( i have all the above wrapped up in a shell script)

game options => -d3d9 and tick the "run 32 bit client"
(currently 0 addons)

12 -> 25 FPs in open areas of New Dalaran, 7->12 FPS in the hearth in foyer in New Dalaran. (but I've only spent about 15 minutes in game - so results may not be accurate yet)

I did NOT find that the overwatch-wine bundle worked - although the launcher worked and behaved as normal (see the XP mode to WIN10 mode bit) all attempts to launch the game ended up stuck in RtplWaitForCriticalSection. I'm suspecting that F25 and the build environment have a minor library difference.

I'm going to bet that whatever DRM Blizzard rolled out is *only* in the 64 bit client, not the 32 bit client.

Still crashing for me (same error 132.) I do have a Radeon card. Might this be the issue? Someone else (windows) was having a problem here, too: us.battle.net/forums/en/wow/topic/20758887160

try to look at this bugs.winehq.org/show_bug.cgi?id=43641

You might be onto something. Although I set detail to good (it was on fair), and I'm still crashing.

OK. I'm playing, water set to "fair," and I'm able to play. Haven't crashed yet. And i'm in the area where I normally am.

Sorry Atonner, you say "* env variables or hide them in a script" and "i have all the above wrapped up in a shell script". Where how would I use/set env variable and/or could you suggest how the shell script would be written (with example I could edit?)

Thanks for your help!

These are just variables for the Nvidia libraries to give better performance.
(Although I don't think the second one helps).


If you need those you can set them in an shell script where you start wow.

For example I have a script to set the wineprefix for wow, set the first variable and start the game.

It's easier to do this stuff in a script than do it every time you start the game.

I always recommend a separate prefix for each application (although blizzard games for example can be put together in one).

I downloaded wine-overwatch-2.15, and the game actually works, yay! I removed all my library overrides to see if they're still needed, and apparently not. But are there some that still improve something? Anyone using anything?

And, one of those exceptions was d3d11, and when I tried DX11, the game crashed incredibly hard. But I've seen reports of working DX11, how do you do it?

I don't even see DX11 as an option.

if use glsl is disabled, the game menu only shows dx9, but if you set glsl enabled, then the system menu in game will show dx11. wine has not finished the dx11 api, but wine 2.17 is out, and I have not tried it yet to see if that helps.

Hi,

thanks for your nice instruction and i managed to set it all up & get the game running with it. But once I want to login to my character, the loading screen finishes, and then the game crashes leaving a memory access error message.

Do you have any advice for this? I am using the overwatch-2.15 wine, with no library changes whatsoever.

I think it's a WoW bug. There are numerous posts in Tech Support and General about people crashing to desktop randomly. I can reproduce it near the keep in Stormwind and in Broken Shore.

But for me this crash is not random, but every time within the loading screen as soon as it finishes up.... I dont even get to crash somewhere :(

The randomness is the location at which you will crash, not when you're going to. Once you run into such a location, the game will just freeze and the access violation will pop up (as you explained). If you try to load that character again, the game will crash as soon as loading's finished (so you're still on the loading screen when the access violation pops up). What you can try to do is log into another character, play a bit, then log into your crashed character and move away from wherever you were. Chances are however that you will still crash whenever you zone, load, or move into range of something.

I've found if I switch to DX11, I can play fine (but get a weird blue sheen to everything, along with odd text.) But if I switch back to dx9, I crash again (access violation.)

I've found for me it happens at the edge of Stormwind towards Northshire, Northshire, Burning Steppes, and around the Tomb of Sargeras.

Other places reported are Frostwall, Ironforge, and Stormshield. (I was able to verify the Tomb of Sargeras one.)

Is this a WINE or a WoW bug? How do we get it fixed?

Switch to Dx11, that solved all my problems with crashing in some places... But its slower than Dx9, at least it works.

Posted by Pontudinho
I think there is no need to compile wine-overwatch... I downloaded precompiled binaries from lutris.net/files/runners/wine-overwatch-2.15-x86_64.tar.gz, unpacked them at /opt and using the wine binary from this package, I managed to play the game.

Using Linux Mint 18.2 (Ubuntu 16.04 derived) here.
us.battle.net/forums/en/wow/topic/20758687677?page=2

The Overwatch 2.15 x86_64 can be found from the above link.

This version works for me, but is very slow and high CPU consuming ...

Copied over from: us.battle.net/forums/en/wow/topic/20758857016
Also located at: us.battle.net/forums/en/wow/topic/20758687677

Trackers fix also worked for me.
1. Downloaded Lutris lutris.net/downloads/
2. Downloaded battle.net lutris.net/games/battlenet/
3. Downloaded WoW [didn't let it reinstall itself with the 40gb, just on lutrix] lutris.net/games/world-of-warcraft/
4. Redirected Lutris's battle.net to load to my already installed WoW.
5. Then followed Tracker's comment [unpacked it in my download folder and lutris auto-found it in the dropdown menu, though I also downloaded overwatch but didn't let it fully install too].

Loads fine now. Thanks heaps :hugs: forums.

Original posts:

Tacker's Comment:
FYI - If you use Lutris to run WoW, go into Manage Runners, then choose Wine - Manage Versions and select the Overwatch 2.15 x86_64. Once that's downloaded, in the Warcraft icon, right click and configure, go to the wine version section and change it to use the new overwatch one you just downloaded. Came right up after that for me.[/quote]

Isaacnewtoon's follow up Comment:
I use Lutris!
It worked for me! Thank you, thank you thank you!!!
I was getting a bit overwhelmed reading through the proposed solution listed at winehq appdb.winehq.org/objectManager.php?sClass=version&iId=33768 by user chiro, involving github.com/gamax92/wine-overwatch

Side note: Lutris makes gaming on Linux super easy and I highly recommend it![/quote]

Its nice that you want to help others with your guide, but some other just don't want your advertise for your program.
Can You point out whats the error and show the patch(es) that it?

bitbucket.org/awesie/wine-overwatch/commits/ check the ntdll patches.
Not a proper solution, so they won't become upstreamed.

bugs.winehq.org/show_bug.cgi?id=40479 is likely the error

Are these compiled like Staging is? (That is, patch the source, compile WINE?) Or are they compiled separately from WINE? (It says it needs a shared WoW64.)

github.com/gamax92/wine-overwatch/issues/5

Answered my own question, for anyone else looking.

Is it possible to use gallium nine withim wine-overwatch?

Patch 7.3 came out today and as it is closes with a "Game failed to launch" error. The battle.net launcher works fine still...

They switched to the same protection like Overwatch and SC1 have.
Post logfiles and try gamac version for overwatch.

Hello, guys! I've decided to play wow a bit again. Been struggling with battle.net all day with no results.
Old library overrides don't seem to work very well, battle.net just shows some random error and dies even before letting me to input email + password.
Though I can see the login window, no login buttons can be seen, error window being popped up every 2 seconds.
I'm using arch with wine-2.14.
Could anybody know the correct way of actions here (i'm the wine newb)? Thanks in advance!

Please ask at the appdb entry of the battle net app

apparently i'm an idiot yet once again! wine-2.14 staging works just fine.

Does someone faced with very slow loading especially in Dalaran?

It happens in windows or linux. happens on other computers here in the house. first load into dalaran takes a very long time. Definitely not a problem on our end, as quite a few people in my guilds are also having the same issue.

Steve

But in windows my loading to much faster...

Then try this. Put elevator=deadline on the grub command line, and reboot.

This don't help me.
# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq bfq
I noticed when I play with DX11 my loading becomes a bit faster.

Add
SET worldPreloadNonCritical "0"
in Config.wtf. That fixed it for me.

Yes, it works! Thank you. Now my HDD fully used on loading.
Without this option HDD periodically don't used while loading.

After installing the Development 2.12 my FPS in wow dropped to 1 and the game became completely unresponsive. Switched to DX9 and set GLSL to disabled with winetricks. FPS now around 45-50 in world, 20-22 in Dalaran-Broken Shores, 18 in combat, solo or raid. Running Fedora 26, kernel 4.11.9-300 selinux set to permissive.

Which settings/hardware do you use?
I play at 4k and play just fine with staging, csmt and d3dx9

in game setting level 7 for everything. even leave ssao enabled, and seems to work fine. Like I said, DX11 is where the problem lies. I can run DX9 in game, and get good fps and the game is playable. Legion is optimized for DX11 and until 2.12 Development from wine, worked good with DX11. Reverting game client to DX9 until the next wine release. GTX 970, Nvidia proprietary 384.47 and 4gig on card. AMD FX 6300 six core, 16GB ddr3 1600. Kernel 4.11.9-300 on Fedora 26.

I have been using staging just fine with DX11 and although I get FPS dropouts in Dalaran and raid or PvP environments it's pretty stable with decent output. I recently updated the WoW client (and perhaps wine) but now I can login but after 10-20 seconds on the character screen my game locks up.

The only playable way I have found so far is to revert to 2.10 devel and switch back to DX9 on a lowered graphics setting. I am getting stable FPS but obviously something is wrong with staging and the updated patch.

I have the same issue here.

And I too.

Because I don't have knowledge to compile wine or similar I need to wait a patch included in one version of wine-staging.

I looked Internet for RPMs for wine-staging 2.8 (and wine-staging-32bit 2.8, of course ) but I have failed (I have openSUSE Leap 42.2).

Been having this issue with the 64-bit live client, it started about a day before the 7.2.5 patch dropped: 5-10 seconds after login, the game freezes (need to kill with xkill or wineserver -k).

I tried nuking my addons/settings, eventually reinstalling the entire game in a new 64bit prefix. I tried wine-staging and wine-staging-git, also recompiled the git version with 'march=native' as suggested in another thread. At the time, the 7.2.5 PTR still worked fine, so I hoped the 7.2.5 patch would magically resolve the issue, and it did! But alas, since another hotfix was pushed, I am back to square one. PTR still works fine, but live still crashes seconds after login.

I can play for a little while using the 32bit client, but it doesn't give me the same performace and it runs out of memory and crashes which kinda cramps my playstyle.

Any thoughts?

Same problem here. Wow either locks up on the character select screen or stops at 90% load bar. The 32-bit also works for me atm. And like you said running out of memory which makes playing really annoying.

-mtune=native is the issue, look at the bug report bugs.winehq.org/show_bug.cgi?id=42805

Thanks for the info! I've tried building with 'march=bdver2' (for my processor) as well as 'mtune=generic' and it still freezes in both builds. Perhaps I'm doing something wrong? Or this solution doesn't help with my processor? Let me know if there is any useful output I can contribute.

Which gcc version to you use? I've got some issues with builds from gcc 7.1.
Generic did the trick for me (my cpu is broadwell ep).

using gcc 7.1.1 20170528
kernel 4.11.5-1-ARCH
AMD FX(tm)-6300 (Family 21, Model 2)

CFLAGS="-march=bdver2 -mtune=bdver2 -O2 -pipe -fstack-protector-strong"
or
CFLAGS="-mtune=generic -O2 -pipe -fstack-protector-strong"
yeilds same (freeze) results

I am experiencing the same issue, if I roll back to 2.8.x it's fine (as of a week or so ago) but anything later than that locks up shortly after opening the Char Select Screen or if I try to sneak in a quick selection it will lock up at ~90% in the load screen.

gcc 7.1.1
kernel 4.11.5-2-ck-piledriver
AMD FX 8320

I have tried compiling 2.9.1 and 2.10.1 with
CFLAGS="-march=bdver2 -O2 -pipe -fstack-protector-strong" as well as native and x86-64 all with the same result

I can get away with running in 32bit but I take a performance hit or at least I assume I do. It could be the newer versions of wine or something else of course as I can't compare 64bit.

Try to build with GCC 6.3 and mtune generic.

I've tried the latest wine-stating and hit the same issue.
Either some of the patches or plain wine is the issue.

I tried the serveral version from current to (0a16521c7e1490e224bef8104953aebb7e9e7f28) to the tag 2.10.
I've tried a version after 2.9 and the commit that was save of is 25e345194ddf9a518405ce038ea91883417a785e.

You can grab pkgbuild with what I build my pkg if you wish:
github.com/Thaodan/thaopkgs/tree/master/wine-staging-git

Please be so kind and try if gcc 7.1 makes no issues here.
You can also try some commits after the save commits and report to me wich made the issue.

i compiled your PKGBUILD on my system, as-is, and the game runs fine with no freeze.

I've found the patch that makes issues.
I've disabled it and now the latest version works fine.
That patch is the issue:
github.com/wine-compholio/wine-staging/commit/ee5545a45f164d640c9b1cd6575a5645afaeb4a9

Just grab my latest pkgbuild.

I do not know how to install this patch, could anyone help me please?

The simplest thing would be to downgrade to wine-staging 2.8 until this problem gets fixed in the latest wine-staging. Exactly how to do this will depend on your distro, but it's easy to look up. Otherwise, you can compile wine + the staging patches (excluding the patch that causes the issue) from source using these instructions: github.com/wine-compholio/wine-staging/wiki/Packaging

Thank you for responding. I tried to install the patch and mention above: github.com/wine-compholio/wine-staging/blob/ee5545a45f164d640c9b1cd6575a5645afaeb4a9/patches/patchinstall.sh

But I could not apply it, because I'm new to linux, I had a little difficulty.
Anyway, let's wait for a compilation next to the wine. \O

Has this been reported in the bug? It would be nice if the next release fixes this issue.

I run Fedora 25, can not use pkgbuild, can you give me something, that lets me compile please. I miss being able to play WoW. Thanks.

Would you mind showing the steps used to build the wine with the package build. I am on 64 bit and need WoW64 windows support as well. Any help is greatly appreciated.

had the same problem with wine-staging. wine-devel (& wine-stable) seems to work for now, but the performance is not as good.

I'm having the same issue. I tried wine-devel, and it does work with no hang, but it's unplayably slow.

Issue is sorted for me, Wine-Staging 2.11, WoW 7.2.5

Since my Windows PC died I've been able to get onto private servers of various expansions just fine, but the battle.net launcher, I cannot get to run, does nothing but crash. I think if I had all of the game files for 7.2.5 I should be able to connect to live without the launcher, but I need those. If anyone could help out by either directing me to a direct download of the files, or uploading your wow directory to some google drive accounts. I think I can get this to work if I can avoid the launcher.

i've had success using 'winetricks corefonts vcrun2015' on a clean 64-bit prefix and then launching the blizzard app installer. Currently using wine-2.10 (Staging) with CSMT enabled.

I have a "5.1" channel speaker setup on a "7.1" onboard soundcard. Regardless of my ALSA configuration, WoW only recognizes 2 channels. The console tool "speaker-test" and numerous other programs confirm ALSA is configured correctly. The audio tab in winecfg recognizes 5.1 availability and I set all the outputs to 5.1 from the default of stereo. I even tried to put this in my ~/.asoundrc:

pcm.!default {
type plug
slave.pcm "surround51"
}

That actually worked on speaker-test, but had no effect on the available sound configurations in WoW. I get sound from all 6 speakers, but the World\ of\ Warcraft/Logs/Sound.log file confirms it's still stereo, and not only that, the sample rate is only 44.1 kHz while my soundcard is actually physically 48 kHz. I've tested this up to the latest 2.9 wine-staging, the problem exists in every version. Is this really the best it can do?

####################################
World\ of\ Warcraft/Logs/Sound.log:
####################################

6/9 19:44:36.152 => SI3 Init
6/9 19:44:36.209 => WoW Version 7.2.0 (24015) Apr 27 2017
6/9 19:44:36.259
6/9 19:44:36.309 => User Settings Report:
6/9 19:44:36.359 - ========= PLAYBACK =========
6/9 19:44:36.409 - Enable All Sound [1]
6/9 19:44:36.459 - Enable SFX [1]
6/9 19:44:36.509 --- Enable Emote Sounds [1]
6/9 19:44:36.560 - Enable Music [1]
6/9 19:44:36.610 --- Loop Music [0]
6/9 19:44:36.660 --- Pet Battle Music [1]
6/9 19:44:36.710 - Enable Ambient Sounds [1]
6/9 19:44:36.768 - Enable Dialog [1]
6/9 19:44:36.818 --- Enable Error Speech [1]
6/9 19:44:36.868 - Sound at Character [1]
6/9 19:44:36.918 - Sound in Background [1]
6/9 19:44:36.969 - Enable Reverb [1]
6/9 19:44:37.019 -
6/9 19:44:37.069 - ========== VOLUME ==========
6/9 19:44:37.119 - Master Volume [1.00]
6/9 19:44:37.169 - SFX Volume [1.00]
6/9 19:44:37.219 - Music Volume [1.00]
6/9 19:44:37.269 - Ambience Volume [1.00]
6/9 19:44:37.319 - Dialog Volume [1.00]
6/9 19:44:37.369 -
6/9 19:44:37.419 - =========== MISC ===========
6/9 19:44:37.469 - Sound Channels [32]
6/9 19:44:37.519 - Sound Cache [64MB]
6/9 19:44:37.570 - Mix Mode 2 [0]
6/9 19:44:37.620 - DSP Buffer Size [AUTO]
6/9 19:44:37.670 - Armor Foley SFX (Self) [1]
6/9 19:44:37.728 - Armor Foley SFX (Others) [1]
6/9 19:44:37.778 => End of User Settings Report
6/9 19:44:37.828
6/9 19:44:37.870 - SE3 Init...
6/9 19:44:37.928 - FMOD Memory Init
6/9 19:44:37.970 - FMOD System Create
6/9 19:44:39.238 - Setting Output Type
6/9 19:44:39.820 - 8 Output drivers detected
6/9 19:44:39.914 --- [0] System Default
6/9 19:44:39.964 --- [1] Out: default (Out: default)
6/9 19:44:40.014 --- [2] Out: HDA ATI SB - ALC892 Digital (Out: HDA ATI SB - ALC892 Digital)
6/9 19:44:40.064 --- [3] Out: HDA NVidia - HDMI 2 (Out: HDA NVidia - HDMI 2)
6/9 19:44:40.114 --- [4] Out: HDA NVidia - HDMI 0 (Out: HDA NVidia - HDMI 0)
6/9 19:44:40.164 --- [5] Out: HDA NVidia - HDMI 3 (Out: HDA NVidia - HDMI 3)
6/9 19:44:40.214 --- [6] Out: HDA NVidia - HDMI 1 (Out: HDA NVidia - HDMI 1)
6/9 19:44:40.264 --- [7] Out: HDA ATI SB - ALC892 Analog (Out: HDA ATI SB - ALC892 Analog)
6/9 19:44:40.314 ** Using Driver [0] System Default (Out: default (Out: default))
6/9 19:44:40.366 - DSPBufferSize = AUTO DETECT
6/9 19:44:40.415 - Setting DSP Buffer Size
6/9 19:44:40.465 - Using Control Panel Speaker Mode STEREO
6/9 19:44:40.506 - Setting Software Format (44100, 2, 1).
6/9 19:44:40.556 - Requested 32 channels.
6/9 19:44:40.626 - Initializing Software Channels
6/9 19:44:40.696 - Init FMOD Game System
6/9 19:44:40.757 - Ok
6/9 19:44:40.807 - Setting Rolloff Scale
6/9 19:44:40.857 - Setting Rolloff Callback
6/9 19:44:40.899 - Sound Bus Init
6/9 19:44:40.949 - Init Suppressors
6/9 19:44:41.019 - SE3 Init Success.
6/9 19:44:41.076 - Setting device callback
6/9 19:44:41.125 => SI3 Init Complete.
6/9 19:44:41.184
6/9 21:05:31.280
6/9 21:05:31.360 => Shutting Down SI3
6/9 21:05:31.402 - Shutting Down SE3
6/9 21:05:31.518 - Shutting Down SE3 COMPLETE.
6/9 21:05:31.573 => Shutting Down SI3 COMPLETE.
6/9 21:05:31.618

Do native apps recognize 5.1?
I'm using pa with a 5.1 profile and Wow sets the sound to 5.1.

Yes, and like I said, I can confirm with speaker-test that it's not just 5-channel stereo. It has worked in native games for years now. A long time ago, it used to even work for me with wine in WoW too, in fact. But it's been broken in all Blizzard games for a while now.

Did you copy over your install from Windows, by any chance? I know I'm grasping at straws here, but it's driving me nuts. My install is Linux-only.

No just installed it with Linux. But this makes no difference.
Maybe there's an issue with alsa and wine.
Check the sound tab of winecfg.

I've definitely done that too. I'm really out of clues. I suppose pulseaudio could be adding something... but I've started to suspect it's actually a registry thing.

Then try a new prefix.
Wow doesn't depend on the actual anyway.
Do you use Pulseaudio?
Than just use pulse.
The asound.conf isn't relevant than.
You need to set the pulse profile to 5.1.

New prefix?? Do you really think I didn't try that about a thousand times? Do you realize I've been playing WoW in wine since release?

"Just install pulseaudio, I don't know why" isn't an acceptable solution, sorry. If you can figure out what pulseaudio is providing to wine in terms of speaker configuration that can't be set with alsa configuration, that would be very helpful. There has to be a way to simulate it. Pulseaudio does not provide multi-channel support itself, so whatever is going wrong here is metadata-related.

>New prefix?? Do you really think I didn't try that about a thousand times? Do you realize I've been playing WoW in wine since release?
I have no idea how long you play Wow on wine, I just wanted to help. Dont be rude.

"Just install pulseaudio, I don't know why" isn't an acceptable solution, sorry. If you can figure out what pulseaudio is providing to wine in terms of speaker configuration that can't be set with alsa configuration, that would be very helpful. There has to be a way to simulate it. Pulseaudio does not provide multi-channel support itself, so whatever is going wrong here is metadata-related.
> I sounded like you already use pa for native applications and if this is true the pa profile is relevant and the asound conf is ignored.

You're right. I didn't need to be rude. I'm sorry. I know you were just trying to be helpful. It didn't seem like you read my initial post very well though, because twice before I snapped, you asked about things I'd covered in the post.

Can you please check something for me? This actually would be very helpful. If your setup is as described, I have trouble believing 5.1 sound is actually recognized in-game, even if winecfg's audio tab recognizes it as available. If I'm wrong and it is though, then in the sound options panel in-game there should be some speaker-setup pulldown menu that has a "5.1" option which is selectable. I suspect you actually don't have this option and you're really just getting stereo sound replicated to all speakers, like me. Don't feel bad, it took me a while to notice when this had happened too, and some careful testing to be sure. It's also worth noting here that Starcraft 2 (which I have installed in a separate wineprefix) also suffers from the same issue. The tooltip says that the speaker setup options available came from the Windows Control Panel, which as far as I can tell just stores settings in the registry. Since we don't have this in wine though, either pulseaudio is not working either, or it must be making/faking the necessary audio settings or registry changes automatically somehow. That's my hypothesis at this point, at least. If you could verify this one way or another, it would help a lot.

I installed the 4.12-rc4 kernel and Noveau driver with latest wine with Gallium 3d support -
I have a Nvidia 970 card and world of warcraft run pretty good - Had the same performace ( low ) at the priodriver 381:22 . But the sound were much better . I use hdmi .
Amd fx 6100 6 core
16 gb DDR3 1600

Can some try with a amd Card ?
On Windows 10 i can run the game on ultra with no problems .

Well . Wow runs better with Noveau (padoka) and wined3d9 pacth than wine staging with nvidia 382.22 drivers . Today i tanked all raids with 1080 P with the lowest settings .9-30 dps boss fights . Thats playble - But if nouveau driver could clock my card it had been over 100 fps - ;( Im ordered a budget gaming card Msi rx 560 4gb oc to see if AMD cards with open source driver are better . Fingers cross that my 100 dollars are well spent ;)

wine-staging-nine on Arch linux .

With Opensource drivers and enable wine nine support i can play on High setting and tank RAIDS in 40-50 fps . Fu** Nvidia ! Now my Nvidia 970 is on the shelf and im using my cheap Amp rx 560 card .

Running wow-64.exe, all the reg hacks worked except useglsl disabled. when i try that, wow-64.exe complained about no 3D. set to enabled, game works. decent performance on my amd fx-6300 with geforce gtx 970 and nvidia proprietary version 381.22. No more logging to windows to play one game. game config is using DX11, and i am running wine staging 2.8, linux kernel 4.10.17.

I used the same reg edits and the 381.22 nvidia drivers, but I used D3D9 instead of D3D11 and it works with useglsl disabled. Windows 10 option, Wine Staging 2.8, kernel version 4.10-21. Geforce 1050ti, intel e8400 cpu. Not that great FPS (30ish in dalaran), almost to a crawl in big raids, but not bad overall for a computer that is largely 8+ years old.

You don't mention, are you running wine64 to launch wow64.exe? Also, I have gone into grub and set elevator=deadline on the linux command line. and that seems to help with disk access. Dalaran for me, on Uther, around 55Fps, graphic setting is 6 but SSAO needs to be off. Drops to 35Fps in combat, regardless of group size. Join groups to kill world boss, no fps drops. Did have to disable one addon, that was dropping me to 5fps in combat. Once I did that the game got really playable. I no longer log to windows, to just run the game. I am thinking I may never have to touch windows again. I am working with the addon author of the one that killed my fps, to see what can be done. Legion is optimized for D3D11 and when I do try it with D3D9, the fps suffers. I have 17 addons installed, and no problems with them. I log to windows, to update them, as curse has no linux client. I could use the website, to download and install the zip files, but I am lazy. Prefer just to copy the addons folder once it us updated in windoze. Have fun.

it is wine64 to launch wow-64.exe. i also set elevator=deadline in grub and it seems to have helped as well, also switched over to enabled glsl and D3D11, seems to work better overall. Less slowdowns. probably as good as it will get for me until i either buy a new mobo/cpu/ram or do the gallium-nine route again like i had with my older AMD card before.

I think as the work on the dx11 api progresses, we will see more improvement in game performance across the board for linux based systems. I would dearly love to tell Windows where to go, but for now, I do have to use it occasionally. At least I can limit that some more, since WoW is working in wine. Also fixed the addon that was causing my fps to drop in combat. I stay around 40Fps even in world boss raid groups. i am glad that my suggestions aided you in some small way as well. Enjoy!

What is the addon you needed to disable? I have the same issue. The game (on my aging hardware) is quite playable, but, in large World Boss groups or large raids, I don't know that I hit even 5 fps...


M.

Carbonite main module, which is required for the quests, notes, and warehouse modules that I run. I would drop to 0 fps in combat and my character moved like a claymation stick figure. I found that if I went to the carbonite world map, right click, select Show... and unchecked the Show Guides POI that I could keep using carbonite. I am currently working on a fork of the main addon, to see if I can get the guides back. Not a deal breaker, as I can see the fp on the map, so still know where everything is. Graphics set at level 5 but turn off SSAO since the opengl render that is emulating the dx11 calls, does not support that feature. Have fun.

Alternatively, you can use the Lcurse python script at github.com/ephraim/lcurse to update your addons on linux. It is very clean and simple, and can update addons directly from curse or github. I use it and it works superbly! Open source and doesn't require windows :)