Battlefield 4 Patch 2/13/2014 with Mantle improvements

[3DVagabond]

He is basing it on low level versus high level principles and experience with DX and OpenGL. If he's worked on consoles, then he may have good examples of how low level stuff is done.

The general idea is DX is high level, and as a result, does a lot more for the developer per command. It handles more of the memory management behind the scenes than you'd get from low level programming. These functions have been fine tuned over the years and are generally pretty solid, with known problems.

With lower level coding, the developer must control a lot more, including a lot of the memory management. With more control, it is more likely the developer will make mistakes. There is just more that can go wrong.

You said the same thing I did except you come to the conclusion it's going to create more problems because the devs are in control. You, can see it that way. I see it as less chefs in the kitchen to cause problems. When there is a problem it's the game. It's not DX, it's not Mantle, it's the game. The dev doesn't have a black box to code through and can more easily debug it and fix it.

 

[bystander36]

You said the same thing I did except you come to the conclusion it's going to create more problems because the devs are in control. You, can see it that way. I see it as less chefs in the kitchen to cause problems. When there is a problem it's the game. It's not DX, it's not Mantle, it's the game. The dev doesn't have a black box to code through and can more easily debug it and fix it.

Have you ever coded for games, or with a low level language such as C and a high level language such as Lua?

High level languages are slower, but they are rock solid.

The black box idea you are talking about, may make things harder to fine tune, and optimize, but it does prevent errors.

That black box has been used in 1000's of games. Any problems it may have had, have either been well documented or fixed.

With a low level coding approach, every game is different, and all the things that a "black box" does for you, automatically, the dev has to do and it hasn't had nearly as much time to flush out the problems. Every game or engine created, requires time to flush out the problems.

There are advantages to both approaches. Low level approaches do give you better abilities to optimize code. High level approaches have fewer places to create errors.

 

[3DVagabond]

Have you ever coded for games, or with a low level language such as C and a high level language such as Lua?

High level languages are slower, but they are rock solid.

The black box idea you are talking about, may make things harder to fine tune, and optimize, but it does prevent errors.

That black box has been used in 1000's of games. Any problems it may have had, have either been well documented or fixed.

With a low level coding approach, every game is different, and all the things that a "black box" does for you, automatically, the dev has to do and it hasn't had nearly as much time to flush out the problems. Every game or engine created, requires time to flush out the problems.

There are advantages to both approaches. Low level approaches do give you better abilities to optimize code. High level approaches have fewer places to create errors.

Well, considering the issues BF4 had on release, I'd say that DX isn't quite as automatic as you are saying it is.

 

[bystander36]

Well, considering the issues BF4 had on release, I'd say that DX isn't quite as automatic as you are saying it is.

You aren't understanding.

They still have to write tons of code and all that code the dev's create can have errors, but using low level code just multiplies the amount of code you have when dealing with the graphics engine, which will allow for more errors.

 

[3DVagabond]

You aren't understanding.

They still have to write tons of code and all that code the dev's create can have errors, but using low level code just multiplies the amount of code you have when dealing with the graphics engine, which will allow for more errors.

I understand. I said it in my first post.

I assume he's basing that on the fact that devs are going to be coding more directly and the API is doing less. I'm not sure how that translates to less stability and more bugs though.

You are just jumping to the conclusion that we're going to have buggier less stable games because of it. It's going to be better optimized for the hardware that Mantle will be running on. If there is a bug it's in all likelihood going to be in the game code and the devs can correct it. It's not going to be created by something DX is doing behind the scenes and it's not going to be created by the driver translating from the API to the GPU since the API is written so the game can talk more directly to the GPU with less abstraction going on. The devs have said it's going to make debugging easier. We still have people wanting to ignore everything the devs have said and put down the API with theoretical scenarios. BF4 running the DX path should show that all this "ease of coding and bug free stability" being associated to DX simply doesn't exist. This isn't exclusive to BF4 either. There are plenty of examples of buggy DX games going back as far as you want to look. BF4 just shows that issues still haven't gone away.

 

[bystander36]

You can go on to have blind faith in every marketing point made, but I'll wait to see what we get.

I really don't think you understand code much either, by your comments. No matter how high or how low level code is, dev's make errors and create bugs.

High level coding requires fewer lines of code than lower level code. It means you have to manage more by your own code. It doesn't mean you don't have to manage anything.

Low level code just increases your odds for errors. High level code reduces it, as there is less coding to do.

How good their debugging tools really are may play some part in it too. If the tools are good enough, maybe there will not be as many errors, but time will tell.

And just because there are bugs in code, doesn't automatically make it a DX bug or a Mantle related bug.

 

[Will Robinson]

Considering there hasn't been a lower level coding API than DX in general use how do you assume that?

 

[3DVagabond]

You can call what the devs are saying marketing points if you like. You have no evidence that they aren't being accurate in their assessment other than insinuating it's some kind of paid conspiracy. They are the only ones, not you or me that's for absolute certainty, who have actually written game code for Mantle, and they're gushing with positivity.

As always, the proof is in the pudding, and it's too early to pronounce Mantle a success. That's either technically or commercially. The same goes though for all this negativity about it's bad for gaming because of fragmentation, it's going to be buggy, it's going to be unprofitable, etc... The devs have made it pretty clear that DX is not at all simple to program for. That DX is holding them back. That DX is very difficult to debug. They've asked for Mantle (or something Mantle like) because Microsoft won't address their wants.

I also find it interesting that while MT has been a part of DX11 all along it's taken Microsoft until Win 8.1's latest patch to get it working to an appreciable degree right at the same time Mantle hits the streets. Coincidence? Maybe. Competition from Mantle? Maybe. Will it be run on prior DX11 OS's? Nope! They will do just like they always do and force you to upgrade your OS if you want it. When are people going to have enough of this type of arm twisting the market? We need competition in everything or nothing will get better and we'll get dragged over the coals financially. I say good on AMD and I hope they are successful improving the market and our gaming experience. That is where my positivity comes from.

 

[bystander36]

Considering there hasn't been a lower level coding API than DX in general use how do you assume that?

Because every other example of low level versus high level shows that low level has more errors than high level code. It is simple statistics. If you have to code 10 times more, you will increase your odds for errors. And it isn't simply a matter of more code, the low level you go, the more complex the code is, as a general rule.

Granted, there are other factors, and who knows, maybe Mantle won't introduce more bugs, but the odds are pretty good it will.

 

[AnandThenMan]

Because every other example of low level versus high level shows that low level has more errors than high level code. It is simple statistics. If you have to code 10 times more, you will increase your odds for errors. And it isn't simply a matter of more code, the low level you go, the more complex the code is, as a general rule.

Granted, there are other factors, and who knows, maybe Mantle won't introduce more bugs, but the odds are pretty good it will.

Less abstraction means less bugs not more.

 

[VulgarDisplay]

Because every other example of low level versus high level shows that low level has more errors than high level code. It is simple statistics. If you have to code 10 times more, you will increase your odds for errors. And it isn't simply a matter of more code, the low level you go, the more complex the code is, as a general rule.

Granted, there are other factors, and who knows, maybe Mantle won't introduce more bugs, but the odds are pretty good it will.

The code may be more complex and longer, but there is no high level API making unintended decisions for you that you have no idea are going to occur. With the low level code what they write is exactly what they get.

 

[_UP_]

You can call what the devs are saying marketing points if you like. You have no evidence that they aren't being accurate in their assessment other than insinuating it's some kind of paid conspiracy. They are the only ones, not you or me that's for absolute certainty, who have actually written game code for Mantle, and they're gushing with positivity.

As always, the proof is in the pudding, and it's too early to pronounce Mantle a success. That's either technically or commercially. The same goes though for all this negativity about it's bad for gaming because of fragmentation, it's going to be buggy, it's going to be unprofitable, etc... The devs have made it pretty clear that DX is not at all simple to program for. That DX is holding them back. That DX is very difficult to debug. They've asked for Mantle (or something Mantle like) because Microsoft won't address their wants.

I also find it interesting that while MT has been a part of DX11 all along it's taken Microsoft until Win 8.1's latest patch to get it working to an appreciable degree right at the same time Mantle hits the streets. Coincidence? Maybe. Competition from Mantle? Maybe. Will it be run on prior DX11 OS's? Nope! They will do just like they always do and force you to upgrade your OS if you want it. When are people going to have enough of this type of arm twisting the market? We need competition in everything or nothing will get better and we'll get dragged over the coals financially. I say good on AMD and I hope they are successful improving the market and our gaming experience. That is where my positivity comes from.

I'll start by saying that my card history (last 4) was 6950, 670, 7970 and now the 780 Ti. That is to show I have no brand preferences. I'll also say I really like AMD because they support more open standards, and I do believe that is where we need to go with everything. Propriety code should be a thing of the past (as much as possible).
I'll also say that I think it is great that we get another API, as DX has been a bit "still" for a long time now, and a field with no competition is going nowhere.
But, all that said, low-level coding will usually have more bugs. Just as a way of explaining think of how many people code in low-level languages. Look for positions and see how many you see for languages like C and Assembly. Now look at how many are for high-level languages such as Java, Python and so on. Most programmers, even if they learned low-level languages, don't really use them, and have less experience coding for them. It's just the way it is, because it's easier, and most people prefer doing something easier (or using simpler tools or however you want to call it).
Now, Mantle might be a great success, and I hope that happens, but what BrightCandle and bystander36 are trying to say is that low-level code adds more complexity (a lot more) and more code. That, by probabilities alone, is enough to add bugs. How hard/easy it is to fix them? We don't know. But the bugs are probably going to be there, and more rather than less.
To use you analogy of the chef, then it's not before many chefs now 1 chef, it's before 1 chef and many sous chefs and helpers, and now 1 chef. Alone. Mantle might offer some great new tools, but that, as you said, time will tell.

 

[AnandThenMan]

DX has low level coding as well, it's just not exposed to the game developers. In fact it has more layers, which means more complexity and more potential failure points. It may be safer from a coding perspective than Mantle (Johan said as much) because if you're not experienced then you can certainly cause a serious fault and take down the whole system.

Which is why D3D will happily coexist with Mantle, if you don't need to the metal access you don't have to use it, take the safe but slow path. But if you want the freedom to push the hardware, Mantle is for you. So in reality most of the major game releases will benefit from Mantle.

 

[3DVagabond]

I'll start by saying that my card history (last 4) was 6950, 670, 7970 and now the 780 Ti. That is to show I have no brand preferences. I'll also say I really like AMD because they support more open standards, and I do believe that is where we need to go with everything. Propriety code should be a thing of the past (as much as possible).
I'll also say that I think it is great that we get another API, as DX has been a bit "still" for a long time now, and a field with no competition is going nowhere.
But, all that said, low-level coding will usually have more bugs. Just as a way of explaining think of how many people code in low-level languages. Look for positions and see how many you see for languages like C and Assembly. Now look at how many are for high-level languages such as Java, Python and so on. Most programmers, even if they learned low-level languages, don't really use them, and have less experience coding for them. It's just the way it is, because it's easier, and most people prefer doing something easier (or using simpler tools or however you want to call it).
Now, Mantle might be a great success, and I hope that happens, but what BrightCandle and bystander36 are trying to say is that low-level code adds more complexity (a lot more) and more code. That, by probabilities alone, is enough to add bugs. How hard/easy it is to fix them? We don't know. But the bugs are probably going to be there, and more rather than less.
To use you analogy of the chef, then it's not before many chefs now 1 chef, it's before 1 chef and many sous chefs and helpers, and now 1 chef. Alone. Mantle might offer some great new tools, but that, as you said, time will tell.

I understood that's what BrightCandle meant before bystander36 even tried to clarify. That's what my post, "I assume he's basing that on the fact that devs are going to be coding more directly and the API is doing less", was saying.

In this particular case though the devs have said that they have issues with DX's closed nature that they've been asking Microsoft to address and allow them more transparency but they've refused to. They've specifically said that debugging their code is especially difficult because of that. You are correct that there are far more people who can code in Python, Perl, etc. than Visual C++.net. It's not like it's a dead language though. It is used a lot in game programming. Devs write low level for consoles and have been doing it forever (figuratively speaking, of course. ) That is the major advantage that Mantle is leveraging. The same GCN hardware in the consoles as in current Radeon graphics. (Before anyone tries to twist that, I never said that Mantle is used in consoles.)

Anyway, I'm not saying there won't be issues. I just take exception to people who have never seen Mantle, never mind written a line of code for it, stating unequivocally that games written for Mantle are going to be buggier and less stable than games written for DX. I understand completely why they are saying it. I'm just saying it's not a forgone conclusion. Just about everything that's been said so far on these boards about Mantle is only opinion based on virtually zero knowledge and those who do have knowledge on Mantle can't be believed because, according to most of Mantle's detractors, they are paid AMD shills. When Johan did come over and post here he got accused of trying to turn the Mantle thread into a marketing thread. Unfortunately, someone who could give us some insight was treated rudely and likely won't be back.

 

[bystander36]

You may also be misunderstanding what they mean when they say it is difficult to do things with DX. It is hard to make DX do things they didn't intend it to do, due to it's higher level nature, but it is easier to do things it is intended to do than a low level API.

If the dev's are trying to do things DX wasn't intended to do, I'm sure it will be harder to code for, but is that what most dev's are going to do? Is that what any dev is doing? I have no idea how often that is.

 

[Will Robinson]

DX has low level coding as well, it's just not exposed to the game developers. In fact it has more layers, which means more complexity and more potential failure points. It may be safer from a coding perspective than Mantle (Johan said as much) because if you're not experienced then you can certainly cause a serious fault and take down the whole system.

Which is why D3D will happily coexist with Mantle, if you don't need to the metal access you don't have to use it, take the safe but slow path. But if you want the freedom to push the hardware, Mantle is for you. So in reality most of the major game releases will benefit from Mantle.

I agree,that sums it up nicely.:thumbsup:
On a side note,I bet a lot of the junior devs and perhaps even some of the old lags rely heavily on libraries of other people's code.
Mantle appears more suited to advanced programming skills and/or a passion for pushing the envelope WRT the quality of the graphics and the speed with which it runs.

 

[selni]

You can call what the devs are saying marketing points if you like. You have no evidence that they aren't being accurate in their assessment other than insinuating it's some kind of paid conspiracy. They are the only ones, not you or me that's for absolute certainty, who have actually written game code for Mantle, and they're gushing with positivity.

As always, the proof is in the pudding, and it's too early to pronounce Mantle a success. That's either technically or commercially. The same goes though for all this negativity about it's bad for gaming because of fragmentation, it's going to be buggy, it's going to be unprofitable, etc... The devs have made it pretty clear that DX is not at all simple to program for. That DX is holding them back. That DX is very difficult to debug. They've asked for Mantle (or something Mantle like) because Microsoft won't address their wants.

I also find it interesting that while MT has been a part of DX11 all along it's taken Microsoft until Win 8.1's latest patch to get it working to an appreciable degree right at the same time Mantle hits the streets. Coincidence? Maybe. Competition from Mantle? Maybe. Will it be run on prior DX11 OS's? Nope! They will do just like they always do and force you to upgrade your OS if you want it. When are people going to have enough of this type of arm twisting the market? We need competition in everything or nothing will get better and we'll get dragged over the coals financially. I say good on AMD and I hope they are successful improving the market and our gaming experience. That is where my positivity comes from.

I've always found odd that people are surprised Microsoft wants to charge for software updates.

 

[3DVagabond]

I've always found odd that people are surprised Microsoft wants to charge for software updates.

We were supposed to have DX11 MT all along. This is more like charging for a bug fix as opposed to an update.

 

[tweakboy]

This looks like FEAR . gl

 

[GaiaHunter]

Console games are coded at a lower level than PC games.
I've always heard that console games were less buggier.

 

[BrightCandle]

Over the last 40 years or so we have learnt quite a lot about code and bugs, not enough to avoid creating bugs of course but we have lots of stats. The number of bugs seems mostly to depend on the number of lines written, regardless of language or the level of abstraction. Thus high level languages and approaches produce fewer bugs as they also require less lines of code. That is I am afraid an established fact.

To paraphrase what Johan said about DirectX was that he had trouble determining what the performance of DX features was going to be due to lack of transparency. They had to do a number of workarounds and odd approaches to solve problems for performance reasons due to lack of driver transparency and such. He has also said that the multithreaded contexts were exceptionally buggy. But I have never heard that DX is a buggy mess at all, its more the abstraction layer hides the performance characteristics of the underlying card and that is an issue for BF and Frostbite engine. The other devs at the Gsync session where he talked quite a bit about Mantle and why he wanted it largely disagreed on these points however and were happy enough with DX and openGL.

The other side to this is that the need to tweak performance also means hard to read code, hard to write code and could very well introduce lots of bugs of its own. We do have some limited data that says non obvious code hides more bugs than simple code. The current movement in the programming world is to write functional code that when looking at the method it is immediately obvious what it does based on high layers of abstraction, it simply hides less bugs. So distorting your approach for DX in order to get fewer draw calls etc can also introduce problems due to performance.

Mantle is new, the developers don't know it very well, its likely not documented very well yet (seeing as how the dev docs haven't even been released yet and APIs rarely are at the start) and so its no surprise that developers will make a lot of mistakes, in the beginning. Once it becomes better understood I suspect we'll see fewer bugs on Mantle when games are designed for it, because they won't have to distort quite so much to get good performance and that I think will weigh slightly positively against the increased line count of the lower level API with more resource management. But overall I think in the end I doubt it will dramatically better or worse in bugs than programming against other APIs, its the first uses of it that will be buggy.

I am still concerned somewhat about the way in which features interact and the implicit rules but until I see the API I can't be clear what its doing and what problems it exposes me to. Its of concern to me that the dev kit hasn't been released yet, there is no way for proper adoption to even start until that happens.

 

[ShintaiDK]

I've always heard that console games were less buggier.

Thats simply a myth. Consoles had patches since 2003:
http://www.geek.com/games/the-first-patch-to-ever-hit-a-console-is-coming-soon-552151/

Also with consoles there is an incentive to avoid patches:
http://kotaku.com/5884842/wait-it-costs-40000-to-patch-a-console-game

 

[Paul98]

It all depends on what is being done and how it's supported on the different API's. Once it's out of beta and documented there shouldn't be memory leaks as long as the developers deallocate memory after use.

 

[Skurge]

Thats simply a myth. Consoles had patches since 2003:
http://www.geek.com/games/the-first-patch-to-ever-hit-a-console-is-coming-soon-552151/

Also with consoles there is an incentive to avoid patches:
http://kotaku.com/5884842/wait-it-costs-40000-to-patch-a-console-game

Console games are less buggy that is for sure, but it also depends on the Dev, Blizzard and valve games are very stable on any platform and Bethesda games are buggy no matter the game.

Dan baker mentioned that the mantle build of their Engine had less lines of code than their D3D build.

 

[el etro]

I've always heard that console games were less buggier.

Consoles are made to one hardware, with one API and only one audience. This makes console games development more efficient to find bugs in the games and correct them before the final version is out.

And the performance penalty of DX versus low-level API is not so great like people are thinking. See Beyond3D forums to know about the workarounds console games developers do to improve image quality on the older hardware consoles have.