alcopaul.2156

and they nerfed WoD of Spellbreakers. and this lelz Zerg Ball that has all the uptime health like from 60% to 100% for what, less than 1 second, and roll in a line and press skills in sync to DDOS you and the only thing that can save you is if you SIDESTEP their Zerg Ball and set your grafix to Best Performance, still exists.

50 cannot-be-killed-lelz-engineers-coz-of-turrets-and-all-the-boons-without-even-expiring that can throw [Grenades] @ 1.6K damage critical each. and what's that? 80K damage with all [Grenades] hitting? but 5 maxed number of AoE hits / player so 10 engis can throw [Grenade] and hit 5 persons EACH add to that 40 engis more... and you're facing what? 50 man stacked squad.

you cannot even encrypt the sarcasm anymore. someone hijacked the encryption?

> @"Mack.3045" said: > > @"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 :) that's pretty much the flow that i wanted to see. ;)

> @"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?

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?

> @"Balthazzarr.1349" said: > > @"alcopaul.2156" said: > > > @"Balthazzarr.1349" said: > > > Limiting to 35 players will never happen. Not unless ANet decides that wvw is dead and wants us to just move to another game that is. > > > > but the 2-3 additional maps, right? > > > > all brand new, if you want. > > Nope. That would actually cause some big fight groups to have to split up. imo it simply wouldn’t fly. big fight groups? aka those who have fast internet equals fast DDOS coz they press heavy damage skill in sync and the other ball wipes? yo, 2012 wvwvw. time to get some new tactics going coz its like 2021.

> @"mzmz.6289" said: > everytime the fights end in less than 1min, doesnt matter how many ppl you have. imagine you r in the ts with crowded ppl, and you just get run over and die in a sec. for healers can only heal for their team, imagine you have to look where your teammate r in the huge squad. wvw is the unique feature of gw2, but it is most fun destruction. The developers dont play their own game or wut it's called "who can DDOS faster?".

> @"Balthazzarr.1349" said: > Limiting to 35 players will never happen. Not unless ANet decides that wvw is dead and wants us to just move to another game that is. but the 2-3 additional maps, right? all brand new, if you want.

you want to remove transmutation charges or you want the transmutation charges to be gotten via gems only and reset all the transmutation charges that each of the players of guild wars 2 have to zero?

or you can enter sPvP and after the match, your character is alive once more.

if your guardian build can solo the overgrown grub, you can technically tank 4 zergs.

(and ye, please use your autocorrect to grammatically correct the first sentence. thanks.)

> @"Fueki.4753" said: > > @"alcopaul.2156" said: > > > @"Sigmoid.7082" said: > > > > @"alcopaul.2156" said: > > > > well no one made the petition yet so how can you be sure that ANET wants them to underperform? > > > > > > > > lelz. > > > > > > Because they have come to us and said exactly that. That they are deliberately designed to be weak so race isn't a factor when picking class. > > > > but mistfire wolf (not the hounds) can be used by all races and any classes. > > And Mistfire Wolf isn't available to all players. gems? it's up in the BLTC. it is not available if it came only in boxes and no one is selling GW2 vanilla deluxe boxes anymore.

1. dive into the water area 2. if you see an underwater post supporting a bridge, encircle that and the thief tries to kill you by encircling that too, 3. the thief feels s====_(you know). 4. he goes away.