Arma 3 Engine - What would have been a better option and what can we learn?

[10t 12]

Do you understand...

I'm more and more convinced you haven't actually read anything I've written in this thread. You've written 1188 words (each one of which I've read at least twice) disagreeing with my point so far, all I ask (again) is that you summarise what it is you disagree with in two sentences:

Do me a quick favour, if you would. Summarise in a sentence or two how you'd express "my whole argument" - the one that goes against the tide of technology. It'll help me work out what I'm saying that isn't sufficiently clear and we can work from there to some common understanding.

Until then, I can't imagine that we're actually communicating so anything more I write would be a waste.

[fumanwho 10]

I'm more and more convinced you haven't actually read anything I've written in this thread. You've written 1188 words (each one of which I've read at least twice) disagreeing with my point so far, all I ask (again) is that you summarise what it is you disagree with in two sentences:

Until then, I can't imagine that we're actually communicating so anything more I write would be a waste.

He wont answer without adding a load of offtopic waffle, if he answers at all.

[windies 11]

He wont answer without adding a load of offtopic waffle, if he answers at all.

I don't care about you or him honestly, my argument is with the developers, not two forum users who don't amount to anything.

[timmo1982 10]

After all, more operations per second is better in any sense of computing.

With single core, yes. With multi-core its a bit more complex- There is extra processor overheard in actually farming out the work to the different cores at the start of the pipe and extra processor overhead and potential delay trying to put things all back together at the end of pipe(s).

An analogy might be sending 4 trucks through town all containing a piece of a puzzle- You can only finish the puzzle when all 4 trucks arrive at the destination. If you send all 4 trucks one way (i.e. load up one core), you are almost guaranteed that they will reach their destination at the same time. If you send them different ways (multicore) then 3 might arrive a lot more quickly but you can't finish the puzzle until the 4th truck arrives with the final piece- There are some aspects/groupings of tasks in a sim/game for which it makes far more sense to throw them all down the same pipe.

[fred41 42]

With single core, yes. With multi-core its a bit more complex- There is extra processor overheard in actually farming out the work to the different cores at the start of the pipe and extra processor overhead and potential delay trying to put things all back together at the end of pipe(s).

An analogy might be sending 4 trucks through town all containing a piece of a puzzle- You can only finish the puzzle when all 4 trucks arrive at the destination. If you send all 4 trucks one way (i.e. load up one core), you are almost guaranteed that they will reach their destination at the same time. If you send them different ways (multicore) then 3 might arrive a lot more quickly but you can't finish the puzzle until the 4th truck arrives with the final piece- There are some aspects/groupings of tasks in a sim/game for which it makes far more sense to throw them all down the same pipe.

... yes, but dont forget to mention, that our 4 example trucks, should travel with up to 4 times the serial speed, if simulated in parallel ... theoretical ...

But of course when switching to multi-threading, we have to avoid simultaneously (modifying) access to ressources (like memory structures, objects), to prevent inconsistence in our data.

Therefore thread synchronisation have to be implemented and to be optimized for each specific problem (which is not a simple task at all and very difficult to debug).

So in real, our 4 trucks will never reach the 4 times speed. Maybe 2 times the serial speed sounds more realistic (depends of the problem), taking all the synchronisation overhead in to account.

Edited October 16, 2013 by Fred41

[jiltedjock 10]

I was actually after a summary of my posts, but I get the relevance of what you're saying now.

Yes, that is an excellent example of increased concurrency leading to better performance (measured by performance, not by CPU usage).

I think if this discussion were made entirely of examples like that, it'd be much shorter, get less resistance, and have a better shot at convincing the devs to invest time in increasing the concurrency or threadedness (or whatever) of the engine. That single example (especially considering the overhead of running a second entire executable) should maybe even be enough to settle it all on its own.

The thing is it is so well known in Arma, whether or not you get it now is moot - it was a fact before you got it, which renders many of the last umpteen pages in this thread pointless.

[10t 12]

The thing is it is so well known in Arma, whether or not you get it now is moot - it was a fact before you got it, which renders many of the last umpteen pages in this thread pointless.

It was the relevance to point I was trying to make to Windies that I got. Hence my "I get the relevance of what you're saying...".

The fact that the headless client (and and the concurrency it involves) increases performance I've been well aware of for some time. Maybe February. You'll notice that nowhere have I suggested that concurrency can't, won't, or doesn't increase performance. But given how unclear I must have been for Windies, and possibly you, to have missed the distinction since page 19 - yes: those posts have all been pointless.

[jiltedjock 10]

In software development, which is the area I work in, you have to work to standards that you set yourselves - so in my area, it's a standard that is based on a three tier web architecture, because some of our goals are maximum security of the application and scalable performance through modularity. In the context of BI, if one of those standards is, say, a model of threading which will maximise concurrent processing on multi cores - which doesn't necessarily mean running a given thread across multiple cores, as we've shown - then achieving that standard is one of the goals of the project, like it or not.

You choose your standards based on your desired output, as you have been suggesting re measurable performance. It is already known that forcing elements of the engine to run in a separate thread - the server AI thread - improves client performance significantly - both measurably as FPS and qualitatively re stuttering. A small dev house like BI are not going to go down every single avenue to work out what brings the greatest benefits, unless they start from a point where they agree to rewrite the engine, so that all avenues are open. I doubt they will do this. Therefore logically they should explore avenues where performance gains have already been seen, and adopt those standards as goals of the dev process because they can have a reasonable certainty of a good outcome.

[windies 11]

It was the relevance to point I was trying to make to Windies that I got. Hence my "I get the relevance of what you're saying...".

The fact that the headless client (and and the concurrency it involves) increases performance I've been well aware of for some time. Maybe February. You'll notice that nowhere have I suggested that concurrency can't, won't, or doesn't increase performance. But given how unclear I must have been for Windies, and possibly you, to have missed the distinction since page 19 - yes: those posts have all been pointless.

You just wanted to argue the semantics of the validity of using processor usage as a way to measure performance versus measuring performance by measuring sheer performance. My point was that it performance doesn't come out of thin air, something has to change for the better in order to increase performance, whether it be better concurrence, better code optimization or better hardware.

Processor usage might not be the best way to view performance in your eyes or in the eyes of the developers, but it doesn't mean it's completely useless or that it has no bearing on performance whatsoever or even that it's the wrong metric to look at when considering performance. We all know the the RV engine is a heavily CPU dependent engine. It stands to reason that the more processor usage you can get the process to use with little to no stalls or contention across threads, or even just more separate threads from the main thread that can operate in parallel, the better the program will perform. Part of the problem is that by using processor usage as a metric, you can see that the engine has trouble either running all it's threads in parallel I.E. some threads are stalling waiting on the main thread, or the threads themselves don't make full use of processor time in which case it would be beneficial to try and multi-thread more parts of the engine if possible. You can also see that under heavy load, CPU usage drops which means that load causes the threads to stall, even the main thread.

I got the relevance of what you were saying throughout your argument, the problem is it was completely pointless semantics about what you view as a performance metric versus what I view as a performance metric when you yourself said you have zero knowledge of programming and you don't even care how BI gets performance, you just care that they do. I focused on the issue at hand, rather than go off topic with you and argue the semantics of processor usage as a performance metric. I would think that now with others pointing out the flaws in your argument and the childish immaterial nature of it, maybe you would at least stop and consider your argument or your points to possibly reconsider them, instead though you keep trucking on.

Edited October 16, 2013 by Windies

[jimmyjjohn 10]

I agree with some and disagree with some of your points, but I am in your boat. I feel this is an incomplete game that still isnt ready for release (ex: Alpha and Beta runs better than retail version) and I still recommend people arma 2 over arma 3

Thanks

[NeuroFunker 11]

Arma 3 engine has actually a name, just saying. What can we learn? From my perspective: Dynamic soundrange engine frostbyte a like, not to meantion the sound quality, echoing, reverberation, sound occlusion. Some graphical features like better dynamic shadows, nearly every modern engine, has quality dynamic shadows, without jittering, block a like effects. HBAO, which exist since 2010? Which looks good and does it's job, compared to ssao, which only does is killing your FPS, and has nearly no visual effect.

Last not least, all the new graphical features, implemented in VBS3

. Rivers, snow, quality dynamic shadows, physx based building destruction. Finally underground structures.

[calin_banc 19]

It's a good video with reference to some of today's problems, their engine and of course Mantle. 2 man months for implementation from an alpha version with not so much info about it, doesn't sound bad at all and the performance is there. And once you have the engine, you have the foundation for a next ArmA, Day Z, Take On ... etc.

PS: Before going "oh, but it's AMD's thing", it's not! It's open for all or at least it will be from next year and it works on all OSes, not just 8 like the latest DX.

[Alpha Whiskey Romeo 17]

What if RV engine, if not rewritten from the groundup, will become the main obstacle for technically more advanced and smoother future Arma titles?

That's a very interesting and valid point. Perhaps that is the question we should be posing and discussing?

[Leon86 13]

It's a good video with reference to some of today's problems, their engine and of course Mantle. 2 man months for implementation from an alpha version with not so much info about it, doesn't sound bad at all and the performance is there. And once you have the engine, you have the foundation for a next ArmA, Day Z, Take On ... etc.

PS: Before going "oh, but it's AMD's thing", it's not! It's open for all or at least it will be from next year and it works on all OSes, not just 8 like the latest DX.

Mantle would be nice for things like viewdistance and model detail, but it will not help the simulation, which is the main performance killer in arma.

Still, would be nice to run 10km viewdistance with current performance levels, but not really worth spending much time on.

[progamer 14]

Why do we need a new engine? Just look at VBS3's videos to see that this engine will not hold us back.

[roshnak 41]

Didn't BIS just go through a big process of refactoring to strip out old code? I know I remember some posts about rewriting a bunch of stuff with the AI because there was a bunch of old code left over and it wasn't clear what it was for.

I assumed that the reason that Arma 3 is in the state it is in is because refactoring turned out to be a bigger job than they thought. Obviously I don't know for sure that this is the case.

The engine is 12 years old and has many, many games behind it. You have to imagine that over a decade a substantial amount of bloat is introduced. There are entries in the key config that are left over from previous games. At some point you are rewriting so much of the engine that it's not even really the same engine anymore. Is RV at that point yet? I don't know, but they can't keep using the same engine forever.

[RushHour 11]

I regret even paying money for this shit. Kids making games.

[Alpha Whiskey Romeo 17]

I regret even paying money for this shit. Kids making games.

Then why do you continue to post on these forums that are built around a community and game you apparently loath? If I think something is garbage, I make my opinion known and then move right along, not troll about and hang around because I have nothing better to do. It's quite pathetic to be honest.

[artisanal 22]

Hi everyone. One subject picks my attention sice the announcement of arma 3, concerning directx 11. Does someone actually know what the dx11 support has brought to arma 3 ? I mean, i don't see any "star feature" of dx11 implemented in / supported by the game (such as tesselation or some nice 5.0 shaders...) .

[Alpha Whiskey Romeo 17]

Why do we need a new engine? Just look at VBS3's videos to see that this engine will not hold us back.

Jesus... It's not the same engine. The VBS engine components are the direct IP of BIS, not BI, and it isn't the same engine. The engine may have the same roots, but it's been developed completely separately for individual Mil uses. Again, I'll state it as clearly and as slowly as I can for certain people. VBS2 (which I own) and VBS3 fill a niche gap for training purposes, that's it.

It isn't the end all to mil-sim and realism based gaming.

[noubernou 77]

Jesus... It's not the same engine. The VBS engine components are the direct IP of BIS, not BI, and it isn't the same engine. The engine may have the same roots, but it's been developed completely separately for individual Mil uses. Again, I'll state it as clearly and as slowly as I can for certain people. VBS2 (which I own) and VBS3 fill a niche gap for training purposes, that's it.

It isn't the end all to mil-sim and realism based gaming.

A vast majority is the same engine. But yea, you are right, its not what everyone makes it out to be, not even close.

[NeuroFunker 11]

for example, the new fog we got in arma 3 alpha, VBS got the same a bit later. So you can exchange various features from arma to vbs, so it must work vice-versa as well.

[dm 9]

for example, the new fog we got in arma 3 alpha, VBS got the same a bit later. So you can exchange various features from arma to vbs, so it must work vice-versa as well.

Again, this actually happened the other way around ;)

[NeuroFunker 11]

Again, this actually happened the other way around ;)

even so, so we can expect snow, streaming water in the future.

[calin_banc 19]

Mantle would be nice for things like viewdistance and model detail, but it will not help the simulation, which is the main performance killer in arma.

Still, would be nice to run 10km viewdistance with current performance levels, but not really worth spending much time on.

Look again over that video. It's very difficult, close to impossible to have good scaling above 3 cores in DX (for rendering), due to it's serial fundamental constructions - also the drivers are adapted to do the same thing.

Without mantle the CPU stays at about 90-100ms for one frame, with a lot of unused time in which you can do NOTHING, with the GPU doing NOTHING ending up with around 10FPS (+/-). You can try and use all sorts of tricks, but the increase in performance is minimal. With mantle, CPU time drops to around 18ms/frame, with A LOT of unused resources which now you CAN use (for AI, physics, etc). Basically, a FX8350 at 2GHz is not limiting a r290x (and we all know AMD processors are not known for their world record as fastest/clcok), but the video card is the one who holds back performance. Considering you have 10k units shooting at each other, with each projectile as a light source (so it's there physically), you can see how tens of thousands of objects can exist independently. Moreover, you can better use the GPU to do other stuff for you like that simulation you talked about - AI, physics, weather, etc. Also, input lag is reduce, which means lower fps is more responsive than on dx.

And if 2 or 3 months let's say, seems like a lot of time to implement something that will work with every game build on that engine... what can I say, we shall all play a laggy 30FPS or under, MP and SP games. :)

Why do we need a new engine? Just look at VBS3's videos to see that this engine will not hold us back.

Sorry, but although it looks good at times, in others is just as "bad" or even worse than ArmA's 3 own engine.