ArmoredVehicle.2849

New package update 🙂 Changelog: - DXVK updated to 1.9.2-async - For AMD/Intel users running Mesa 21.1.0 or newer, the game will now make use of the new single-file shader cache feature. As opposed to the default shader cache method which creates thousands of files per game, this creates just 3 files per game/application. For non-SSD users this might help reduce stutter.

In my tests I found the ramdisk to be useful only in case of a normal HDD to prevent stuttering during shader compilation. If you're running the game on an SSD, especially an M.2 NVME it shouldn't make much difference, if any at all.

Hello, Could you please provide some details about your system, namely the CPU, GPU and Distro you're using 🙂 If you're using my package and want to try the ramdisk method. In the GW2 folder, you'll find a folder named "shader_cache", open a terminal window in it and copy and paste the following: sudo mount -t tmpfs -o size=128M tmpfs ./ The command above will create a 128MB ramdisk which is enough for this game. As you're probably aware, all contents will be lost as soon you turn off or reboot the PC.

Can you please be a bit more specific with "what you have now?". My packages run in an entirely portable way, which means for example if you're currently running GW2 using Lutris, my package won't interfere with that installation as it's contained in it's own folder. Therefore makes it easier to compare performance. DXVK-DX11 is already supported out of the box in the package. Considering how mature DXVK already is, I'm hoping we won't have any bad surprises with this game.

Working on it 🙂

Can you please provide us some info regarding this new pc? The most important parts would be: CPU, RAM Amount and Graphics Card.

Everything seems to be in order, I even double checked the entries with mine and they're the same. Which distro are you using? I could try to install it into a virtual machine and see what's holding it.

Can you please upload screenshots of the following 3 files: /etc/systemd/system.conf /etc/systemd/user.conf /etc/security/limits.conf

When in WvW does it occur in large fights or even by yourself/small group? Sometimes I get these errors too, they happen at random areas, even on the login screen. As of lately I haven't had any though. In case you need, I've uploaded the old Wine 5.7 based version however it's running a slightly older version of DXVK too. Links: http://jrugia.com/wine_gw2_2.2.0_nvidia.tar.xz http://jrugia.com/wine_gw2_2.2.0_intel_amd.tar.xz If you think the old version runs better for you, I guess I can make a mini update with newer DXVK. 🙂

Unfortunately yes, usually depends on my mood and schedule 🙂 The good news though: The update is finally here and that includes a modern Wine version (6.10) and the newly released DXVK 1.9 (async patched). Both Google Drive and HTTP direct links are now updated and working.

Hello everyone, I'm happy to announce that a new package version is available, I have 'finally' rebased it to a newer Wine version (6.10). Please note that I don't personally use ArcDPS so I don't know if it will solve the issues you've been having with it. Nevertheless I tested the game and didn't notice any issues. Happy Sunday 🙂 EDIT (15/6/21): I'm aware DXVK 1.9 has been released today, GW2 package update will be available in a day or two.

Most likely there will be a release with just dxvk update and then a rebase to Wine 6.10 soon after it. 😉

Can you try increasing the limit again, let's say '9999999' and re-test pls?

Does the issue occur only when trying to run it with Taco?

Thanks for checking it out :) And with that solved, I guess it's time to rebase the package to Wine 6.5

Thanks for the headsup, I was aware of this issue which is why the package is still at Wine 5.7. Didn't know it's still not fixed. If I'm not mistaken, the connection issue is also present in later 5.xx versions. At this point it wouldn't make much sense especially since the game works well enough as it is. There are a few things I'm looking forward though such as: Mesa's single file shader cache which might debut in Mesa 21.1fsync2-futex2 implementation which might replace esync for performance benefits. Eventually Wine will have to rebased in order to welcome the new features. It's only a matter of when. :)

Can you please post your system specs and gpu drivers version? Also in the same folder as the play.sh script, you can run the 'debug.sh' script in a terminal window, which will print out any errors that might help indicate where the issue is coming from. You can copy and paste that log here :)

Hi mate, here is the async patch build of dxvk 1.8 with the optimized SPIRV shader compilation time patch included (as per pull request #1582 ) https://github.com/doitsujin/dxvk/pull/1582 "uses bit::cast instead of direct memcpy, and the additional DxvkShader constructor is less verbose, passing a const SpirvModule& and building flags directly from it instead" This will be slightly faster than the vanilla aysnc 1.8 version for your testing. https://www.dropbox.com/s/3daz94ardnugo34/dxvk-1.8-async%20%281%29.tar.gz?dl=0 Thanks for your help, had some time to test out the new builds, no issues on my end. :) New update announcement: I've went ahead and updated the package, only DXVK has been touched/updated this time. I've also tested arcdps and it's working fine on my setup (AMD GPU). Regarding the rebase to Wine 6.x, to be honest I'm still a bit hesitant about this, and the reason is that I'm still seeing reports of the network error. I'll see if I can run a few tests of my own regarding this. This weekend I've also worked on improving the non-google drive download links, they're now linked to an http server as opposed to the previous ftp based setup. Patches - On the first page in the downloads section I've added a patch to easily go from 2.1.0 to 2.2.0. Installation is simple, extract it into the game's folder and merge/overwrite all files when prompted. Depending on the complexity between package updates, a patch might not always be available. Have a nice weekend ;)

A new DXVK version has been released today (1.8), the async version also ready. Currently testing it with GW2 for any possible regressions, if everything checks out you can expect a package update over the weekend :) Sorry, no Wine rebase to 6.x yet.

Between those GPU's it won't make much difference (if any at all) in GW2, I've played the game on various desktop cards GTX 1060, RX 5500 XT, RTX 2060 Super and RX 6800. Game didn't perform any better with one or the other. As has always been the case with this game, the CPU is a more contributing factor to performance.

Nothing yet, sorry. I'll get to it eventually.

Hi, this issue is occurring in Linux due to a regression in modern Wine versions. Using an older version (such as 5.7) resolves the issue. You can find more info here: https://en-forum.guildwars2.com/discussion/31192/playing-guild-wars-2-on-linux-performance-optimizations-and-more/p21 Also, on the same thread, I'm providing a package for GW2 on Linux which has most optimizations out of the box and is compatible with many distros. It's also portable, won't touch your personal files and doesn't require root access (sudo) either.

Hi, it's the "data" folder. Merry Xmas :)

Hi, I've wanted to do that but my github skills are kinda crappy, also not sure where to begin. But to break it down this is what the package is composed of: Wine 5.7 + Staging Patches + FSync PatchFolders: bin,lib,lib64 and share belong to the Wine build, the 'deps' folder contains a few libraries but I doubt they're required and might be removed in the future.Folder 'data' is the Wine prefix itself, aside from the dxvk dll's and overrides, I've also replaced a few symbolic linked folders with actual folders to make the package portable.All the files in the 'bin' folder named beginning with "user_" are the scripts I added and make up most of the settings.setup.sh and setup.dat (which is just a renamed zip file) are the setup components, I made these to unzip automatically during setup to avoid confusion.the arcdps_easysetup folder is also a small addition of mine to make the addon easier to install/uninstall.That's the entire setup pretty much. ;)

I doubt ANet will bother with this, Mac support has always been limited. Heck the game itself is still using OpenGL on macOS and the api is deprecated (still present but not supported or optimized). If I had to pour resources on Mac I'd focus my efforts on getting the game on Metal which is what most programs/games are using these days and a larger amount of people would benefit from this. As a sort of hitting 2 birds with 1 stone, the performance might even improve on M1 with Rosetta.