Mack.3045

> @"Bardock.4718" said: > It's about the matchup in pvp and wvw:) > > Since when is Warrior a losing matchup against thief? > He counters everything I can do with blind/daze or the thief just evades or blinks away and reset the combat, bc he tanked damage, to reengage and to finsih you off. > > Every D/P thief I just see spamming its 3 and 4 button while you cant do anything. You cant even press Mending because of pistol 4 or instant F1 > S/D I just even more blinky. The spam of blinds isn't there exactly but still obnoxius. > Condi thief is just doing his thing while triggering the whole soul out of you xD > and Deadeye is just teleporting arround the block while being strealth etc. pp > And if I hit eventually a bullcharge because the thief messed up, he just blinks away and took his resonable 10 damage from bullcharge. > > Rightnow the only real counterplay vs D/P bullcharging while the thief is performing is P5 D2 Stealth jump because he's locked in a animation > Against others it's just watching out for a mistake while they slowy drain your health. > > Don't see this as a flame post please. I just wanna know how to beat them? Or I wanna know it's not my fault:3 It's just "anet fault" > > Greetings from Germany:) I rarely loose to thief in duels , keep in mind this is either in PVP duelling servers or the Arena. **WvW is another story.** Happy to share tips / build in-game. Mack Magnusson (Berserker)

> @"ArmoredVehicle.2849" said: > > @"Mack.3045" said: > > > @"ArmoredVehicle.2849" said: > > > 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. > > > > 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 ;) Thanks Armored Vehicle. Are you on Discord ? I had a few questions for you and would be easier to discuss there :)

> @"Aaron malouf.9423" said: > Hi, i want to install this but im worried about maybe getting a time out or possibly banned by using this. is it safe to use ? Completely safe to use. ?

> @"alcopaul.2156" said: > > @"Mack.3045" said: > > > @"alcopaul.2156" said: > > > so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics? > > > > > > DX9 is backwards compatible and it is assumed that old software runs fast on new software, right? > > > > Hi :) > > > > Good question! > > > > I'll give a in-depth technical explanation to answer your question and explain the mechanisms used to go from dx9>translation layer>dx12 render pipeline by using the d912pxy with GW2. > > > > **Dx912pxy and the D3D12 transitional layer.** > > > > **What does this do?** > > This translation layer provides the following high-level constructs or components (and more) for the GW2 engine to implement in the rendering pipeline. > > > > **Resource binding** > > The D3D12 resource binding model is quite different from D3D9 and prior. Rather than having a flat array of resources set on the pipeline which map 1:1 with shader registers, D3D12 takes a more flexible approach which is also closer to modern hardware. The translation layer takes care of figuring out which registers a shader needs, managing root signatures, populating descriptor heaps/tables, and setting up null descriptors for unbound resources. > > > > **Resource renaming** > > D3D9 and older have a concept of DISCARD CPU access patterns, where the CPU populates a resource, instructs the GPU to read from it, and then immediately populates new contents without waiting for the GPU to read the old ones. This pattern is typically implemented via a pattern called "renaming", where new memory is allocated during the DISCARD operation, and all future references to that resource in the API will point to the new memory rather than the old. The translation layer provides a separation of a resource from its "identity," which enables cheap swapping of the underlying memory of a resource for that of another one without having to recreate views or rebind them. It also provides easy access to rename operations (allocate new memory with the same properties as the current, and swap their identities). > > > > **Resource sub-allocation, pooling, and deferred destruction** > > D3D9-style apps can destroy objects immediately after instructing the GPU to do something with them. D3D12 requires applications to hold on to memory and GPU objects until the GPU has finished accessing them. Additionally, D3D9 apps suffer no penalty from allocating small resources (e.g. 16-byte buffers), where D3D12 apps must recognize that such small allocations are infeasible and should be sub-allocated from larger resources. Furthermore, constantly creating and destroying resources is a common pattern in D3D9, but in D3D12 this can quickly become expensive. The translation layer handles all of these abstractions seamlessly. > > > > **Batching and threading** > > Since D3D9 patterns generally require applications to record all graphics commands on a single thread, there are often other CPU cores that are idle. To improve utilization, the translation layer provides a batching layer which can sit on top of the immediate context, moving the majority of work to a second thread so it can be parallelized. It also provides threadpool-based helpers for offloading PSO compilation to worker threads (d912pxy 2.4.1 uses a configurable PSO cache amount plus native DX12 caching at the driver level ) Combining these means that compilations can be kicked off at draw-time on the application thread, and only the batching thread needs to wait for them to be completed. Meanwhile, other PSO compilations are starting or completing, minimizing the wall clock time spent compiling shaders. > > > > **Residency management (memory management)** > > This layer incorporates the open-source residency management library to improve utilization on low-memory systems. > > > > The other component here to consider is user hardware. > > > > If someone is already CPU/GPU bound in DX9 natively with GW2 then i wouldn't expect the D912pxy to help. > > The end-user also needs a GPU that supports/ is capable of rendering with the DX12 api. > > > > If there's CPU/RAM/GPU/VRAM resources available/untapped, then definitely expect an uplift in performance. Ultimately, try it for yourself and see :) > > > > > > I like the part that it goes multicore when rendering. > > and by your definition, there's lots of going on with the DX12 and your interface/translation layer says it handles them all meticulously. > > but say if the client goes DX9 -> interface/translation layer -> DX12, will the graphics rendering be from DX12 to the interface/translation layer and finally to the GW2 client? No, the rendering pipeline is GW2 Client, Game DAT, DX9, D912PXY >DX12API - your monitor :)

> @"ArmoredVehicle.2849" said: > 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. 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

> @"alcopaul.2156" said: > so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics? > > DX9 is backwards compatible and it is assumed that old software runs fast on new software, right? Hi :) Good question! I'll give a in-depth technical explanation to answer your question and explain the mechanisms used to go from dx9>translation layer>dx12 render pipeline by using the d912pxy with GW2. **Dx912pxy and the D3D12 transitional layer.** **What does this do?** This translation layer provides the following high-level constructs or components (and more) for the GW2 engine to implement in the rendering pipeline. **Resource binding** The D3D12 resource binding model is quite different from D3D9 and prior. Rather than having a flat array of resources set on the pipeline which map 1:1 with shader registers, D3D12 takes a more flexible approach which is also closer to modern hardware. The translation layer takes care of figuring out which registers a shader needs, managing root signatures, populating descriptor heaps/tables, and setting up null descriptors for unbound resources. **Resource renaming** D3D9 and older have a concept of DISCARD CPU access patterns, where the CPU populates a resource, instructs the GPU to read from it, and then immediately populates new contents without waiting for the GPU to read the old ones. This pattern is typically implemented via a pattern called "renaming", where new memory is allocated during the DISCARD operation, and all future references to that resource in the API will point to the new memory rather than the old. The translation layer provides a separation of a resource from its "identity," which enables cheap swapping of the underlying memory of a resource for that of another one without having to recreate views or rebind them. It also provides easy access to rename operations (allocate new memory with the same properties as the current, and swap their identities). **Resource sub-allocation, pooling, and deferred destruction** D3D9-style apps can destroy objects immediately after instructing the GPU to do something with them. D3D12 requires applications to hold on to memory and GPU objects until the GPU has finished accessing them. Additionally, D3D9 apps suffer no penalty from allocating small resources (e.g. 16-byte buffers), where D3D12 apps must recognize that such small allocations are infeasible and should be sub-allocated from larger resources. Furthermore, constantly creating and destroying resources is a common pattern in D3D9, but in D3D12 this can quickly become expensive. The translation layer handles all of these abstractions seamlessly. **Batching and threading** Since D3D9 patterns generally require applications to record all graphics commands on a single thread, there are often other CPU cores that are idle. To improve utilization, the translation layer provides a batching layer which can sit on top of the immediate context, moving the majority of work to a second thread so it can be parallelized. It also provides threadpool-based helpers for offloading PSO compilation to worker threads (d912pxy 2.4.1 uses a configurable PSO cache amount plus native DX12 caching at the driver level ) Combining these means that compilations can be kicked off at draw-time on the application thread, and only the batching thread needs to wait for them to be completed. Meanwhile, other PSO compilations are starting or completing, minimizing the wall clock time spent compiling shaders. **Residency management (memory management)** This layer incorporates the open-source residency management library to improve utilization on low-memory systems. The other component here to consider is user hardware. If someone is already CPU/GPU bound in DX9 natively with GW2 then i wouldn't expect the D912pxy to help. The end-user also needs a GPU that supports/ is capable of rendering with the DX12 api. If there's CPU/RAM/GPU/VRAM resources available/untapped, then definitely expect an uplift in performance. Ultimately, try it for yourself and see :)

Hi all. For anyone wanting to you reshade with the latest build d912pxy 2.4.1 build without issues, I recommend using the latest Gshade available here. https://t.co/40fsp8fjEz?amp=1 Just select the DX12 option when installing. Enjoy !

> @"Polish Hammer.6820" said: > So i had this installed before but it was an old version and I want to update to the newest one. However the zip file I download doesn't include an installer. How do I install the latest release? Windows defender didn't remove it either. It just isn't included. Hello, i just downloaded a fresh zip of 2.4 and unpacked. The installer file is there. Not sure what is happening on your end !

Updated original post to reflect pre-release version 2.4 and change notes.

> @"Anime.2895" said: > I just wish gw2 could make use of extra cores/threads, my pc runs the game phenomenally, but it's much more expensive than your average users pc, I think for people with lower end hardware it would be nice for gw2 to use more threads/cores. > > It's a fantastic game, and I'm extremely grateful that it isn't subscription based, my wife and I try to put 20$ each into the gemstore a month in hopes that gw2 will continue improving, we love this game and it deserves some qol improvements We already have dx12 support using the d912pxy and it's free. You can find the guide here https://en-forum.guildwars2.com/discussion/110553/want-to-use-directx-12-dx12-for-gw2-heres-a-guide-on-using-the-d912pxy-on-windows-10

> @"hanifemelissaiklimirmak.3621" said: > Yes, correct detection English is not my native language, but the problem is that game developers don't do anything Yes, it's highly unlikely that they'll look at a new engine until GW3. Being that's out of our control, we already have a free option that works and a developer who constantly updates and maintains the d912pxy ?

What are your hardware specs? I'm assuming English may not be your main language based on what you wrote. You can always give the d912pxy a try. Here is the guide https://en-forum.guildwars2.com/discussion/110553/want-to-use-directx-12-dx12-for-gw2-heres-a-guide-on-using-the-d912pxy-on-windows-10#latest

> @"Ralios.5023" said: > Hello community! > problem is as follows: i can play fine and all put fps isn't to good. when i look at my resource management it shows that nothing really runs at it's full capacity. GPU hits like 60% and CPU around the same margin. RAM is not fully used either and OS+GW2 are located on a SSD. > i already set priority of gw2 in task manager to highest and gpu is set to maximum power usage. > as i understand it GW2 uses single thread performance so one would expect that 1-2 cores are running at max but all cores are running on equal percentages (40-60%). > > my rig: > GTX 1080 > Intel i7 4790k > 16gb Ram > Win 10 > > any help would be apprecciated, > thanks > > best regards The game in it's native state is a bit of a shemozzle. My suggestion is to try running the game in DX12 by using the d912pxy. You'll find a guide on the forums here https://en-forum.guildwars2.com/discussion/110553/want-to-use-directx-12-dx12-for-gw2-heres-a-guide-on-using-the-d912pxy-on-windows-10#latest For support you can discuss any issues with the community here via Discord including the developer https://discord.com/invite/fY9KADf

> @"gmmg.9210" said: > The downtime between blind is maddeningly small, and the burn dps is too strong. Yerloqq, run shout Berserker or Shout SB with Soldier runes / and "On My Mark" for the reveal and you'll laugh off those blinds and burns :P Mack

> @"Quadeard.8457" said: > Hi guys. Not sure were I should drop my question so I try here (were else?). > I'm running D912PXY + some other addons trough GW2 Addon Manager, as well as GShade. All this works perfectly. > > My problem is that I'm unable to game capture or window capture GW2.exe with OBS Studio. Capture screen is blank, then sometimes OBS crashes. The only way is screen capture, wich is annoying. > **Can anyone successfully capture GW2.exe with d912pxy + GShade trough OBS ?** Hi, that would be an issue with OBS specifically and how it hooks into what's being rendered. I'd jump on the d912pxy discord channel and ask there. Otherwise ask the guys who author the OBS software. Good luck!