A little depressing.....

I wish I could play PVP with a computer above recommended specs. Guess that day will never come.

This is what happens when developers try to build their own engine from a pre existing . This will really become noticeable as new games in 2017 start taking advantage of the new unreal engine . Just looked through some of the highlights and full wind simulators , hair , cloth are just amazing to witness .

On the other side, there are those of us that think as much about the quality of content as the graphics, and think that just because its not using the best of this and that technology-wise it still works and is fun to play.

If you have the need to have the best and newest tech the moment it comes out, you are either very rich or very broke.

The game is no where near doomed . If graphics were the deciding factor WOW would of died a long time ago . Brand loyalty , expanding content and keeping things addicting are the other factors to MMO survival . People won't run over to a new better graphic game if they feel attached to the current . Zeni is new to the gaming world and slow but they do realize enough of this to keep the base game running . I have serious doubts about the PvP aspects here . That is the toughest community to retain in all games .

Woah now, I'm not sure you understand the importance of Mantle/Vulkan/Direct3D 12.

In the traditional, driver-oriented APIs (Direct3D 11 and older), the driver is performing insane amounts of validation, error checking and correction. As a result, when a draw call is issued by the 3D application's renderer, it takes up a large amount of CPU time.

For example, in Direct3D 9, your framerates will suffer extremely once you go past 3.5k draw calls on an AMD CPU (sub 30fps), or past 10k draw calls on an Intel CPU (again, sub 30fps). On Direct3D 11, just double the number of draw calls for the best possible scenario.

For those that don't know, each individual object in a game, whether it be a single plant, a character's hair, a ring, a boulder, or a house, will issue around 4 or 5 draw calls minimum. The more lights and shadows upon an object, and that the object is casting, the draw calls will increase 1:1; five lights on an object? Five more draw calls, at least. Five shadows on an object? Five more draw calls, at least.

And with models that have multiple textures, the draw calls will rise exponentially. Seven draw calls that would be issued on an object that only has one set of diffuse, normal and specular maps? Well this one has two sets, so that's 14 draw calls. Three sets of textures? That's 21 draw calls. Etc. etc. The solution to that conundrum is to use texture atlases, but these gobble up vRAM, overburdens the GPU due to all the extra shader instructions required for anisotropic filtering being used on the large (often >8192x8192 in size) textures, use up large amounts of drive space, as well as being a pain in the ass for the artists to create.

There is little that can be done to alleviate this bottleneck on said APIs. There are two solutions, when looking solely at the issue of draw call performance. One, is to create an API that allows for parallel issuing and validation of draw calls. This is what AMD demonstrated a short while before DICE collaborated with AMD to bring this to the consumer space; an embarrassingly parallel graphics API.

However, this still has the limit of several thousand draw calls being issued per core. Same CPU performance hit, but with four cores (i.e, four CPUs) handling draw calls. In other words, if we take D3D9's 3.5k draw call ceiling and chuck in parallel submission, we would ideally get 14k draw calls on a quad core CPU.

That's still exceedingly paltry. Compare Oblivion to Fallout 4; Fallout 4 is issuing many more draw calls, and has a moderately higher object density, but it's still using the exact same 5x5 active game area system (ugrids), as well as using the same LOD system. Why? Because even with Direct3D 11's more efficient draw calls, it's nowhere near enough to accommodate moderate-long draw distances.

So what must be done? Exactly what Mantle, Direct3D 12 and Vulkan are; parallel draw call submissions, with the graphics driver being a fairly "raw" interface between the game and graphics card. So rather than having to perform fail-safe, catch-all, better-safe-than-sorry, we-don't-know-what-will-happen-so-we'll-play-it-safe, CPU-crunching error checking, have the engine programmers perform the necessary error checking and such.

Whilst that sounds scary to the ignorant, that's because there's a lack of perspective. A good way to look at it, is the difference between, say, Lua and C++. Lua is a scripting language that is absolutely not what a realtime program (e.g, Skyrim, 3DS Max, Photoshop, Cubase, etc.) should be made with; it's exceedingly wasteful on the CPU. The upside? Extremely easy to get a handle on, and will take care of a large amount of error checking (memory leaks and threads, mainly).

But if you want to have a realtime application that won't have a framerate running the low twenties on the most beefy of consumer hardware available, you will need to use C++; at the cost of having to do error checking and fail-safes manually, the performance of your program will perform magnitudes faster.

That's the difference between Direct3D11 and these newer APIs; more manual renderer code, in order to gain magnitudes more performance.

If we were to compare the most intensive match on Trueflame, with a Direct3D 11 renderer and a Vulkan renderer, you would find that a venerable old Phenom, like yours truly has, will be thrust into the low teens. On Vulkan? I'd be surprised if the framerate wasn't hitting close to 50, if not 60.

I still play old Sega games. What difference does it matter if they're just brilliant, entertaining games?

MajinCry wrote: »

Woah now, I'm not sure you understand the importance of Mantle/Vulkan/Direct3D 12.

In the traditional, driver-oriented APIs (Direct3D 11 and older), the driver is performing insane amounts of validation, error checking and correction. As a result, when a draw call is issued by the 3D application's renderer, it takes up a large amount of CPU time.

For example, in Direct3D 9, your framerates will suffer extremely once you go past 3.5k draw calls on an AMD CPU (sub 30fps), or past 10k draw calls on an Intel CPU (again, sub 30fps). On Direct3D 11, just double the number of draw calls for the best possible scenario.

For those that don't know, each individual object in a game, whether it be a single plant, a character's hair, a ring, a boulder, or a house, will issue around 4 or 5 draw calls minimum. The more lights and shadows upon an object, and that the object is casting, the draw calls will increase 1:1; five lights on an object? Five more draw calls, at least. Five shadows on an object? Five more draw calls, at least.

And with models that have multiple textures, the draw calls will rise exponentially. Seven draw calls that would be issued on an object that only has one set of diffuse, normal and specular maps? Well this one has two sets, so that's 14 draw calls. Three sets of textures? That's 21 draw calls. Etc. etc. The solution to that conundrum is to use texture atlases, but these gobble up vRAM, overburdens the GPU due to all the extra shader instructions required for anisotropic filtering being used on the large (often >8192x8192 in size) textures, use up large amounts of drive space, as well as being a pain in the ass for the artists to create.

There is little that can be done to alleviate this bottleneck on said APIs. There are two solutions, when looking solely at the issue of draw call performance. One, is to create an API that allows for parallel issuing and validation of draw calls. This is what AMD demonstrated a short while before DICE collaborated with AMD to bring this to the consumer space; an embarrassingly parallel graphics API.

However, this still has the limit of several thousand draw calls being issued per core. Same CPU performance hit, but with four cores (i.e, four CPUs) handling draw calls. In other words, if we take D3D9's 3.5k draw call ceiling and chuck in parallel submission, we would ideally get 14k draw calls on a quad core CPU.

That's still exceedingly paltry. Compare Oblivion to Fallout 4; Fallout 4 is issuing many more draw calls, and has a moderately higher object density, but it's still using the exact same 5x5 active game area system (ugrids), as well as using the same LOD system. Why? Because even with Direct3D 11's more efficient draw calls, it's nowhere near enough to accommodate moderate-long draw distances.

So what must be done? Exactly what Mantle, Direct3D 12 and Vulkan are; parallel draw call submissions, with the graphics driver being a fairly "raw" interface between the game and graphics card. So rather than having to perform fail-safe, catch-all, better-safe-than-sorry, we-don't-know-what-will-happen-so-we'll-play-it-safe, CPU-crunching error checking, have the engine programmers perform the necessary error checking and such.

Whilst that sounds scary to the ignorant, that's because there's a lack of perspective. A good way to look at it, is the difference between, say, Lua and C++. Lua is a scripting language that is absolutely not what a realtime program (e.g, Skyrim, 3DS Max, Photoshop, Cubase, etc.) should be made with; it's exceedingly wasteful on the CPU. The upside? Extremely easy to get a handle on, and will take care of a large amount of error checking (memory leaks and threads, mainly).

But if you want to have a realtime application that won't have a framerate running the low twenties on the most beefy of consumer hardware available, you will need to use C++; at the cost of having to do error checking and fail-safes manually, the performance of your program will perform magnitudes faster.

That's the difference between Direct3D11 and these newer APIs; more manual renderer code, in order to gain magnitudes more performance.

If we were to compare the most intensive match on Trueflame, with a Direct3D 11 renderer and a Vulkan renderer, you would find that a venerable old Phenom, like yours truly has, will be thrust into the low teens. On Vulkan? I'd be surprised if the framerate wasn't hitting close to 50, if not 60.

That is actually one of my only few gripes overall to be honest, the totally unnecessary use of lua. Sure its easier to get to grips with and will be easier to make addons for and such and ..yadada the list goes on, but lua has never been reliable preformance wise, there was a time when it was but not anymore.

Fact is they should never of built the engine of a prexisting engine to begin with, it takes time and money but they should of built their own just for ESO.

DOOMED!?!?

blimsta wrote: »

YautjaLanu wrote: »

A little depressing.....

No not at all. If anything things are going to become so much better. The soon Directx is put in the bin the better.
we have some good thing ahead.

Whats depressing for me is playing games that are of such a substandard.

We all came here looking for the next big mmo but the truth is, isn't not here yet.

By Akatosh I l have to wonder how so many people got appointed to speak for EVERYONE. Some special star was shining when they were born? A birthmark that indicates they are a really really special snowflake? How does it happen?

*You* came looking for the next big mmo. You are currently disappointed they aren't catering to *your* specific wants and dreams.

*I* came here for a co-op when I want, single when I don't, no pvp required if I'm not interested in it, Elder Scrolls world game. Guess what, O special disppointed special snowflake. I found what I came here for. Not strictly Elder Scrolls single player, but not WoW or COD settings either.

Please, don't stay in a game that disappoints you, or depresses you. You apparently need some special perfect world that caters to your specific specialness. No one will force you to remain here, disappointed and depressed. Send your gear to Altemriel and leave a shred of happiness for someone before you leave to go on to better pastures. And other forums where you can be disappointed and depressed about other games that will never meet your standards.