ArmoredVehicle.2849

I've been monitoring the situation on this, fortunately enough this game doesn't really benefit from bleeding edge Wine releases so it's ok to be a little behind with the version.

Different WM's and compositors can affect performance, especially on low end systems, I switch my low end laptop to a plain openbox session for gaming which helps a bit. I think these kind of tweaks are best left to the user to experiment with though.

I've been testing the rammed cache for the past couple hours. On my main system with an SSD (both game + cache) didn't notice much difference (SSD is a Samsung Evo 250GB). I'm sure if I looked hard enough I'd probably spot something. The real surprise though came from my 2nd system which has no SSD, without the rammed cache loading times were a bit longer and even after I got into the game, some stutter was present till the game loaded all the cache. Turning on the rammed cache though was a different story, loading times were quicker by a rough 10-15sec estimate and the stutter was much less after as I got in game. I think a fast storage for Mesa (Intel/AMD) helps a lot here since the shader cache is composed of thousands of small files, Imagine the HDD trying to load all those shader files + the game's data = stutter. What do you know though, a small 75MB ram drive can make the difference. On the technical side: I'd love to implement this in a user friendly way with as little interaction from the end user as possible, inputting the sudo password will be required for sure in order to mount the drive itself. The sync'ing can be done either at interval times (ticking) or after the game's exe file is closed (flush everything at the end). Implementing this feature in the installer shouldn't be too hard, I could rewire the custom cache folder to be the mounted ram drive, and add a secondary folder to store the shaders.

@"ZenAge.4863" Interesting find there with TacO, I've only ever managed to get it working up to the "BlackTaco" part. From what I can gather it requires some tinkering and it doesn't look like something that can be setup entirely out of the box without some tweaking, feel free to correct me here. Maybe this can be provided into a form of separate addon as in "unzip in GW2 folder and run sh file"? Regarding the shader cache - I think a ram drive is a bit overkill if the cache is read from an SSD. However I like the idea, can't say no to better performance. What if instead of rsync'ing data back and forth, we could mount a ram-file the game reads/writes to at launch and unmount when not in use? Thanks for the input, I like your ideas :)

It uses DXVK which is DX9 to Vulkan. d912pxy might work with VKD3D but I never tried it.Having said that, (so far) all the DX12 games I tried in Wine perform slower than DXVK's DX11 implementation, I don't think GW2 would fair any better. Most probably you can with some tinkering, wouldn't count the game as playable though.

1) I put up the ftp server a few months ago because of that google issue, you're not the only one not able to access it, I recall someone else had the issue a few pages back. 2) I downloaded the package from the server and ran the MD5 test, the result is the same as on the front page. Have you tried re-downloading it? 3) That was a small slip up, I've recently updated the server's package and it didn't retain all settings, I found out the entire system was explorable only a day later (woops). The image files, they're a mini photo shoot for my dad for a local magazine, sending large pictures by email is not very practical, the SSH folder is meant to be for private stuff I transfer from home to work. :) 4) The legacy packages are basically stuck at Wine 2.21 due to some patches incompatible with modern Wine versions, without these patches the game would run slower. I've uploaded them on the FTP server, link is here: ftp://jrugia.com:1025/GW2_Legacy_Packages/ 5) I'll try to get in touch with liberodark. His 1.9.1 package is from last December which could use a little update.

Are you sure the Kernel you were using had the fsync patched in? Because the game performs at half performance without both *syncs.

It does break something on my very peculiar setup. When using action cam and a gamepad (so I am using xf86-input-joystick), I can't move the camera, it gets locked to a specific direction. However, this problem only happens while using a gamepad, if I use the touchpad it works (despite the fact that the underlying code for both ultimately boils down to xf86PostMotionEvent). because of this I've been using wine staging 4.21 until now (the issue is present in all 5.x staging releases, not the vanilla ones). Recently I noticed this same issue in another game (mouse movement doesn't work while the game hides the cursor, only when opening a menu and getting a cursor back), so I am thinking of filing a bug report. It's just been difficult so far to even collect information for it. I am mostly writing this comment as a headsup, in case you have any advice to share. Thanks for the feedback, the only workaround to this would be to apply the staging patches without the affected patch. I need to read a bit how to exclude some of the staging patches in order still provide the good stuff that works (such as esync). Might take some time though but I'll keep it in mind. I didn't notice a difference in GW2 (probably because I don't WvW in large groups), in the usual areas performance is more or less the same for me. What I did notice however is that in other games, esync works in where fsync doesn't (not counting stability here). My kernel is built from the Mainline source + fsync patch from https://github.com/Frogging-Family/linux-tkg Thanks :)

Apparently MoltenGL only translates OpenGL ES which is a bit different than the "desktop" OpenGL. I think I get your point, by using something similar, it might save ANet a lot of hassle from starting from scratch to switch to Metal. TBH I'd rather have them just to do the latter and be done once and for all with the low performance issue.

So here we are at the big version 2.0 of the package, I've been meaning to get this out of the door sooner but it got held back due to other projects. So what's new? I've updated the Wine build from 4.21 to the 5.7, this upgrade doesn't really affect the game much but if it doesn't break anything why not, regardless it's still built on Debian 9 so it should work on any distro released in the last 2 years. Keeping on the Wine topic, I've also added Fsync support, it's disabled by default but you can read below for further details how to use it. For AMD GPU users I've enabled ACO by default for the game, those familiar with it already know the benefits but if you're new, just know that it improves performance in a lot of games. Last but not least there's the obligatory DXVK update. Let me know if you encounter any issues. Changelog: Wine updated to 5.7, Staging patches applied as well as Fsync support (more on that below).Updated DXVK to 1.6.1For AMD GPU users, the game will now make use of the ACO shader compiler by default. Running up to date Mesa drivers is highly recommended.FSync support in Wine has been implemented.Regarding FSync: This feature is for advanced users and can be used instead of ESync. To use it requires a patched kernel, as such it is disabled by default. Users wishing to enable it need to go in “bin” folder and open the “user_run” file in a text editor. From there uncomment (remove the # sign) from “#export WINEFSYNC=1” and in turn disable Esync (add the # sign) to “export WINEESYNC=1”. It’s important not to use both at the same time.

The game uses OpenGL on macOS which is the single biggest performance killer here. It is no secret that for some time OpenGL is in a bad state on macOS and unfortunately ANet opted to use that over the more advanced Metal API. Aside from this, the game is also better optimized on Windows. Currently your alternatives are 2: Setup Bootcamp with Win10 just for the game or install a modern Linux distro (the latter might be a bit tricky).

You should be able to play the game at medium details and 1080p just fine with those specs. Just keep in mind that Shadows and Player Models will still affect performance the same way it does on native Windows.

I must be incompetent or blind, because I can't find a single DLL, only folders. Direct link to the file mentioned: https://github.com/doitsujin/dxvk/releases/download/v1.6/dxvk-1.6.tar.gz;)

While the general idea is that a wrapper creates an overhead, there are certain cases where wrappers can actually improve performance, see here:

Just a few points I'd like to mention here. People who suffer from overheating problems can break down to multiple factors (dust, clogged ventilations, dried up thermal paste, background tasks using cpu power), while GW2 is CPU intensive it doesn't stress it as much as one would imagine, the game is certainly not to blame here.You speak of RTX as if everyone can afford or has one, also don't forget some GW2 players are also AMD users.DX12 is a dead end API being locked to 1 OS and the Xbox (which is still Win10 based), Vulkan would be a much wiser choice due to its' wider cross platform support while still offering the same level of performance.

I wouldn't choose any of these 2 and instead opt for the much better AMD 3600 (non X). Not only the 3600 matches and sometimes beats the 9400F but it also offers 6 more threads, the price is slightly higher but totally worth it in the long run. Benchmark: Also if you're concerned about temperatures, I'm running the older 1700X that was released in 2017 using the Wraith Prism cooler and I've rarely seen it go beyond 65 degrees. I'm not trying to sound like an AMD fanboy but the CPU's have come so far that I can hardly recommend Intel.

So while your distro is quite old, technically it might still be possible to run the game. A few possibilities for the cause I can think of: The Vulkan loader library (libvulkan) is too old, part of the GW2 package (DXVK) requires at least Vulkan 1.1 support, meanwhile Ubuntu 16.04 comes with 1.0.61 as latest.Some missing libraries, please ensure the Wine package from your package manager is also installed, the game will not use it but this method ensures a lot of the required packages are installed in the system.Make sure libfreetype6:i386 (the 32bit package) is also installed.Driver configuration, which unfortunately is the area where I really can't help as I don't own any laptops with an Nvidia GPU.

While Nvidia is still my main gaming GPU, I did finally acquire an AMD card to test with, the RX 5500 XT (8GB Model). Very happy with the performance so far and stable in all the games I've thrown at it. Screenshot was taken using the latest Mesa 20.0.2 release + Kernel 5.5.10. Please note that the FPS represented below is bottlenecked by the Intel G4560 CPU it's being ran on. DXVK 1.5.2 up to 1.5.4 had a few regressions which affected Mesa drivers but were fixed in 1.5.5, haven't had any issues since. Regarding your crash, can you specify in which areas it happens? I can try to replicate the issue on my end.

Thanks for the headsup, a slip up on my part. I've re-uploaded the correct package :)

The i3-4160 still holds up quite well for most games and in the case of GW2 it will perform very adequately in most areas, in crowded battles though you'll have to reduce Shadows and Character Model Limit+Quality. Upgrading your GPU is the sanest choice here. As for your CPU, even if you get the money, don't bother upgrading it to a better one that uses the same motherboard socket. Better off saving up for a Ryzen 3600 or equivalent 9th Gen Intel i5.

Indeed you can! To be honest I've had little time to work on them these days.Please use the links from the ftp server not the google drive ones as I've just updated the packages to include DXVK 1.5.5 (google drive links not updated yet) :)

Yes and even GW2Radial. The currently known mod that doesn't work is TacO.

There have been a few regressions in the latest versions of DXVK, can you please give it a shot with v1.5.4? I'd do it myself but haven't played through the story yet (and have been generally busy with other projects). Also can you please post your setup, namely GPU Model/Type and Driver version.

Reminds me of the first time I launched the game on my ultra wide monitor (3840x1080):

It's a known issue with DXVK when setting Shadows to "Ultra" and only happens on Nvidia cards - https://github.com/doitsujin/dxvk/issues/1329#issuecomment-576494090 Try latest DXVK 1.5.3