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

[metalcraze 290]

A screenshot is better than words

This was made in OA with Nvidia's driver AO which does have issues in ArmA2 preventing it from being usable other than for screenshots and in ArmA3 NVidia AO doesn't work at all.

As you can see with all those shadows that grass and bushes have the ground seems a lot more lively.

[igneous01 19]

This engine is the best thing we have for this market right now. People claiming that simply swapping engines and releasing two years from now as 'not that difficult' are living in a dreamworld. This is what would happen if the engine was changed:

- Read the documentation : easily a few weeks, months, whenever a problem occurs in the API

- Rewrite all code that 'plugs in' to the engine; those api calls that are used in RV are not going to be the same, or even exist in another engine. Consider for ex:

size_t RV::cacheRsc(Rsc* p_rsc, flags)

that would exist in RV to cache resources (like graphics or data that is not directly on the players screen), first, they probably designed their own resource class that defines a resource.

now imagine FrostByte's is

DWORD FB::commitCacheAllocation(void * rsc, void * dest)

suddenly, whatever flag options that were provided in the RV engine are not usable here. Maybe there was a flag that would allow the engine to cache a resource to multiple locations. This signature only allows 1 location, also the name is different, the parameters are different, and the return value is also different.

This is what makes changing engines a very VERY slow process.

- Deal with technical issues and limitations that exist in this new engine

changing an algorithm that did some process because the new engine would either fail to process the result, a compile error, or simply not supported. It happens.

- Systems and performance testing

- rebuilding the game from the ground up, all over again

There's a reason why Battlefield 2 to Battlefield 3 gap was so long, because They probably starting working on BF3 a year or so after BF2 released.

so no, dont change engines, unless people want to wait 6+ years to see a new Arma game.

[xendance 3]

This engine is the best thing we have for this market right now. People claiming that simply swapping engines and releasing two years from now as 'not that difficult' are living in a dreamworld. This is what would happen if the engine was changed:

- Read the documentation : easily a few weeks, months, whenever a problem occurs in the API

- Rewrite all code that 'plugs in' to the engine; those api calls that are used in RV are not going to be the same, or even exist in another engine. Consider for ex:

size_t RV::cacheRsc(Rsc* p_rsc, flags)

that would exist in RV to cache resources (like graphics or data that is not directly on the players screen), first, they probably designed their own resource class that defines a resource.

now imagine FrostByte's is

DWORD FB::commitCacheAllocation(void * rsc, void * dest)

suddenly, whatever flag options that were provided in the RV engine are not usable here. Maybe there was a flag that would allow the engine to cache a resource to multiple locations. This signature only allows 1 location, also the name is different, the parameters are different, and the return value is also different.

This is what makes changing engines a very VERY slow process.

- Deal with technical issues and limitations that exist in this new engine

changing an algorithm that did some process because the new engine would either fail to process the result, a compile error, or simply not supported. It happens.

- Systems and performance testing

- rebuilding the game from the ground up, all over again

There's a reason why Battlefield 2 to Battlefield 3 gap was so long, because They probably starting working on BF3 a year or so after BF2 released.

so no, dont change engines, unless people want to wait 6+ years to see a new Arma game.

Umm, the reason is that they made BF 2142, BF: Bad Company 1 and 2 between BF 2 and 3 ;)

[igneous01 19]

Umm, the reason is that they made BF 2142, BF: Bad Company 1 and 2 between BF 2 and 3 ;)

Dice has multiple groups of programmers, the main group most likely starting working with FrostByte right after BF2 release, since BF2142 is easily a retexture of all assets, with some game modes created on the engine scripting language.

[xendance 3]

Dice has multiple groups of programmers, the main group most likely starting working with FrostByte right after BF2 release, since BF2142 is easily a retexture of all assets, with some game modes created on the engine scripting language.

Yes. But you said "working on BF 3" so I just went with that. Engine team is different.

[paecmaker 23]

If BI did lets say get Cryengine, would they be able to even make the game as moddable as today? They license it doesnt that got limits to what they can release for the public?

[xendance 3]

If BI did lets say get Cryengine, would they be able to even make the game as moddable as today? They license it doesnt that got limits to what they can release for the public?

That's irrelevant since Cryengine can't handle as big maps as ArmA engine. You can try it yourself in the free SDK, big (like 16 km * 16 km) maps won't work.

[suprememodder 11]

99.5% percent of people who post anything about RV are haven't the foggiest idea what they're talking about. It's like a conspiracy theory for complainers. I've thought about dubbing them (not just in an ArmA context) the engine sluts, but that might get me banned,

you don't have to know anything about how the engine functions to know that it performs terribly, looks poor in low light and overcast conditions and uses technology that was defunct since the late 90s(stencil shadows). from there, you can use common sense to deduce the other failings of the engine even if they are not explicitly disclosed.

This engine is the best thing we have for this market right now

the poor performance, doesn't fully utilize gpu or latest pc technology market? if so, bis has got that corned. to be honest, i wouldn't be so quick to criticize other engines, even if they aren't capable of "zomg huge google map terrain! that lags like hell and will barely be used", at least those other engines have working multicore.

Edited October 6, 2013 by suprememodder

[dm 9]

common sense

Then it is a shame that 99.5 percent of people also lack this basic functionality too, isn't it. :)

[igneous01 19]

you don't have to know anything about how the engine functions to know that it performs terribly, looks poor in low light and overcast conditions and uses technology that was defunct since the late 90s(stencil shadows). from there, you can use common sense to deduce the other failings of the engine even if they are not explicitly disclosed.

the poor performance, doesn't fully utilize gpu or latest pc technology market? if so, bis has got that corned. to be honest, i wouldn't be so quick to criticize other engines, even if they aren't capable of "zomg huge google map terrain! that lags like hell and will barely be used", at least those other engines have working multicore.

if thats how you feel, and would prefer smaller maps, then you are playing the wrong game. Find something like Crysis 3 or BF3/BF4, maybe some mods for Crysis to suit your needs.

Also, the multicore works in RV; The problem is that multi-threading with shared/dependent resources causes threads to block. This is why one core will spike around 80% or more, while the other cores remain below 50% (they are waiting for the thread to let go of the resource). However I will agree with you that RV's multithreaded design needs to be improved. I think there are too many dependencies between threads, and this may be causing excessive blocking. But this is only speculation.

[Polygon 11]

I remember Maruk having his word on BIF on RV engine performance and optimization possibilities. It was clearly stated that...

- the number of threads avaiable for resource handling won't improve current RV's state (not possible even in theory?)

- engineers / programmers are working hard on expanding RV (cannot recall specific stuff)

however, nothing about efficiency improvement of resource handling in threads was mentioned.

BI should simply assemble a tech team with an intent to improve/keep up to date and sell their technology in the future for market needs.

[noubernou 77]

if thats how you feel, and would prefer smaller maps, then you are playing the wrong game. Find something like Crysis 3 or BF3/BF4, maybe some mods for Crysis to suit your needs.

Also, the multicore works in RV; The problem is that multi-threading with shared/dependent resources causes threads to block. This is why one core will spike around 80% or more, while the other cores remain below 50% (they are waiting for the thread to let go of the resource). However I will agree with you that RV's multithreaded design needs to be improved. I think there are too many dependencies between threads, and this may be causing excessive blocking. But this is only speculation.

That is because almost the entirety of the core engine runs in a single thread. Resource loading being thrown across multiple threads is not going to improve much, and if the engine is so monolithic it might actually hurt performance in some cases (like you said, because of locking issues).

[Necrodancer 10]

That's irrelevant since Cryengine can't handle as big maps as ArmA engine. You can try it yourself in the free SDK, big (like 16 km * 16 km) maps won't work.

Actually the SDK has a multiplier up to 32 which makes it possible of a maximum map size of 262 km * 262 km = 68 644 SQUARE KILOMETERS. Suck on that.

[jibemorel 10]

Actually the SDK has a multiplier up to 32 which makes it possible of a maximum map size of 262 km * 262 km = 68 644 SQUARE KILOMETERS. Suck on that.

Yep by streamable instances, each one being a box of 8km*8km*2km, if I recall correctly

[maruk 80]

I remember Maruk having his word on BIF on RV engine performance and optimization possibilities. It was clearly stated that...

- the number of threads avaiable for resource handling won't improve current RV's state (not possible even in theory?)

- engineers / programmers are working hard on expanding RV (cannot recall specific stuff)

however, nothing about efficiency improvement of resource handling in threads was mentioned.

BI should simply assemble a tech team with an intent to improve/keep up to date and sell their technology in the future for market needs.

Incorrect. What I said is that concurency is not a goal at all, only real performance (higher fps, more objects on screen, more units performing complex AI computations etc.) is what matters, so end users trying to measure their CPU or GPU concurency are simply focusing their attention in wrong direction. Those interested learning more about complexity of multicore optimizations and architecture are always welcome to read this article.

[calin_banc 19]

Maruk, is it possible to estimate how much an API like Mantle (or even OpenGL) would boost performance or allow you to do extra "stuff" in ArmA series? I'm asking this considering this could be one of the most useful implementation for such an API.

[dm 9]

Actually the SDK has a multiplier up to 32 which makes it possible of a maximum map size of 262 km * 262 km = 68 644 SQUARE KILOMETERS. Suck on that.

And the RV engine is capable of unlimited terrain, largest I've seen is 1000 x 1000km, but thats already over 120 GB of data with little/no object population...

[windies 11]

Incorrect. What I said is that concurency is not a goal at all, only real performance (higher fps, more objects on screen, more units performing complex AI computations etc.) is what matters, so end users trying to measure their CPU or GPU concurency are simply focusing their attention in wrong direction. Those interested learning more about complexity of multicore optimizations and architecture are always welcome to read this article.

What about better performance through better concurrency? Saying that process concurrency is not a goal, is kind of misleading because performance is the goal, better concurrency is the way to achieve that goal. After all, more operations per second is better in any sense of computing.

CPU usage is CPU usage and GPU usage is GPU usage and it's universal between programs, that's the point of measuring it. It's disingenuous to try and say that measuring your hardware usage is focusing attention in the wrong direction when hardware usage is exactly what you want to measure. Your engine doesn't magically pull performance out of thin air, it does it by optimizing code, make more efficient use of processing cycles, or using multiple logical cpu's and still making efficient use of processing cycles across all of them. All of which is represented by hardware usage, in this case CPU and GPU usage.

Under the best of circumstances, a process should make 100% use of the CPU IF it needs to under load, represented by 100% cpu usage. Your program shouldn't decrease usage under load, unless the different threads are blocking each other which would explain why usage drops, I.E. thread stall or contention, as NouberNou said. This is what we are seeing though from the RV engine, Usage DROPPING under load rather than rising. To be more clear, if I'm at a steady 60 fps and some AI are introduced to the scenario, their associated processing "cost" shouldn't cause a massive drop to FPS as well as cause usage to drop from 80% to 50%. That means that the introduction of those AI have introduced a bottleneck within the engine that is causing it to stall. It's the antithesis of everything I was taught in even basic programming classes.

Seems like just more sweeping in this regard to me.

Edited October 7, 2013 by Windies

[FredAirland 13]

Actually the SDK has a multiplier up to 32 which makes it possible of a maximum map size of 262 km * 262 km = 68 644 SQUARE KILOMETERS. Suck on that.

theoretically yes, practically due to floating point errors any terrain above 16km x 16km is not usable...

I have been there many times and there are several posts... here's one of the most recent.

http://www.crydev.net/viewtopic.php?f=355&t=86359

[timmo1982 10]

and uses technology that was defunct since the late 90s(stencil shadows)

- There is nothing 'defunct' about stencil shadows, they require less rendering grunt and are fine depending on what you want to achieve. It's simply 'horses for courses' and rationalising where the rendering 'budget' is spent.

[10t 12]

What about better performance through better concurrency? Saying that process concurrency is not a goal, is kind of misleading because performance is the goal, better concurrency is the way to achieve that goal. After all, more operations per second is better in any sense of computing.

No. "Better" concurrency is a way to achieve better performance. And, to me, the definition of "better concurrency" is "some level of concurrency that improves performance" - not necessarily "increased concurrency".

Measuring concurrency is only a valid measure of performance if nothing else changes. If something else changes in the way the engine works (as it sounds like it would have to in this case to increase concurrency) then we don't know what the actual effect on performance would be. And performance improvement is the whole point of the exercise. I, personally, would be happy to see a reduction in concurrency if that somehow improved performance. Because I don't care what my CPU's doing, or if my expensive GPU is somehow offloading calculations to the RAID controller, or if my RAM is being bypassed entirely and everything's being done on HDD cache - if all that nonsense somehow makes the game run better then I've scored a win.

This whole issue reminds me of what I see in business or engineering, where people focus attention and effort on things that are easy to measure, rather than the things they should actually care about. They choose a parameter which is one of several important parameters and optimize that without an understanding of the effect of their actions on the whole system and therefore the final result they're after. For example, focusing exclusively on improving cashflow without proper consideration of the effect on long-term profit & loss. Or on maximising combustion chamber temperature (which is a driving factor in thermodynamic efficiency) without considering the related increase in wear, servicing costs, cooling requirements, and therefore the true impact on total cost to run - which is the real measure of success.

BI should be maximising the ratio of game performance increase compared to their effort. If increasing concurrency is the most efficient (in the performance gain per effort measure), then that's what they should focus on. If improving the algorithm efficiency in a single thread can achieve the same performance gain for less effort on their part, then they should do that. And if changing 15 different things in 15 different ways (some possibly related to concurrency) is the best, then that's what they should do.

[ShotgunSheamuS 1]

What 10T said =) Also I think theres a missunderstanding in concurrency on CPU load, just because the load on each core is full, does not mean the game is not ustilizing it to it's best. It just means it is utilizing what it requires. In fact the lower the load, the better right? This reminds me of a time when Vista just came out and some brat told me (with much pride too) that he's Vista Ultimate OS uses 7Gb of he's 8Gb of Ram, and that Vista was the best OS because it fully utilized all he's hardware. Now it's really the same principle here really... unless you dont see what I just did there.

Based on CPU load, ARMA perform's better on my rig than say BF3, WHY??? Because ARMA 3 thrashes BF3 in terms of the sheer amount of onscreen detail, and the map size etc. Because it does way more than BF3 at a lower CPU load. Like maruk said, it is easy to create a little app that will max out your cpu, for all you know, these games that "fully" utilize your cpu and gpu, are probably very poorly optimized, and poor missunderstood Maruk and other guys have spent countless nights trying to please us with any little performance boost they manage to pull out of thin cyber air... Poor guys are probably coffee addicts! lol

Now that said, I do agree ARMA still needs more performance gain in hardware. For one, ARMA is very CPU intensive, and actually fairly light on the GPU given it doesnt really utilize any heavy GPU hungry techniques, so I think the rendering that's occuring on the CPU is really just unnecessary, now I dont know anything about programming graphics, but I am sure it should be possible to offload all of that rendering to GPU, because afterall, isnt a GPU faster than a CPU?? so then perhaps view distance may be largely dependable on GPU rather than CPU as it is now. It is easier and cheaper to upgrade GPU, especially with the introduction of sli and crossfire, than it is to upgrade your CPU. I might be completely off track here with this idea, but it makes sense to me.

[xendance 3]

To appease people yelling about concurrency, just spawn few native threads in the background and make them increase a counter in an endless loop.

BAM! 100% CPU utilization.

[das attorney 857]

This whole issue reminds me of what I see in business or engineering, where people focus attention and effort on things that are easy to measure, rather than the things they should actually care about. They choose a parameter which is one of several important parameters and optimize that without an understanding of the effect of their actions on the whole system and therefore the final result they're after. For example, focusing exclusively on improving cashflow without proper consideration of the effect on long-term profit & loss. Or on maximising combustion chamber temperature (which is a driving factor in thermodynamic efficiency) without considering the related increase in wear, servicing costs, cooling requirements, and therefore the true impact on total cost to run - which is the real measure of success.

This is the best paragraph I have read on this topic. People (in general) tend to be distracted by the shiny-shiny and take their eye off the ball when it comes to looking at the whole picture.

[Ezcoo 47]

This whole issue reminds me of what I see in business or engineering, where people focus attention and effort on things that are easy to measure, rather than the things they should actually care about. They choose a parameter which is one of several important parameters and optimize that without an understanding of the effect of their actions on the whole system and therefore the final result they're after. For example, focusing exclusively on improving cashflow without proper consideration of the effect on long-term profit & loss. Or on maximising combustion chamber temperature (which is a driving factor in thermodynamic efficiency) without considering the related increase in wear, servicing costs, cooling requirements, and therefore the true impact on total cost to run - which is the real measure of success.

Indeed, what Das Attorney said... Except that I consider this paragraph as the best that I've seen on these forums in general for a while. :ok: