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

[windies 11]

My post is about a question you asked. I said nothing about armas performance and i cant understand why you think that i did. Are you sure you fully understood my post?

No I understand it. I'm just defending my points because they are the only relevant portion of the argument that isn't steeped in semantics or biased uneducated opinion. You're ability to discern how I word things vis a vis how you want to interpret them is pretty immaterial to the real argument at hand.

And even still, you're quote of what I said with big bold letters, is still not me saying that concurrency is some end all be all goal for the developers to pursue. It's simply saying that more processing power is better, be it from a faster processor or through better concurrency or through optimization of program code.

Stupid argument is stupid.

Edited October 15, 2013 by Windies

[Hunter Rose 10]

@10T and Windies

heres your solution guys...unfortunately A dev dismissed it as "middleware" :( ...but it sounds good though:)

http://www.texasmulticoretechnologies.com/services/

That is VERY interesting. Of course, BIS seems to dismiss a lot of great ideas. I really am beginning to wonder about that.

---------- Post added at 03:26 ---------- Previous post was at 03:23 ----------

Honestly, it has to happen if an A4 ever happens. Or they manage to get a rabbit out of the hat with RV, which is very unlikely.

You can teach some tricks to an old dog, but the dog don't get younger with that, will be somewhat rusted\slower in doing so and eventually it will die.

And the RV "selling points" are becoming standards with new engines (these are capable of incredible things, like rivers :j:)

Totally agree. The next Arma has to be on a multicore / multigpu engine or it just won't be able to compete. Just read some of the threads on the Steam forums. A LOT of people want their money back. This game was WAY over-marketed.

[progamer 14]

That is VERY interesting. Of course, BIS seems to dismiss a lot of great ideas. I really am beginning to wonder about that.

---------- Post added at 03:26 ---------- Previous post was at 03:23 ----------

Totally agree. The next Arma has to be on a multicore / multigpu engine or it just won't be able to compete. Just read some of the threads on the Steam forums. A LOT of people want their money back. This game was WAY over-marketed.

Over marketed? I never once saw an ad other than on BI's website. People should have researched to product before purchasing. And why do people want a new engine? No other engine can do what RV4 does, which is why VBS2 used the engine as well. Asking for a new engine is never going to happen because whyndon't you just fix the issues in the original engine and upgrade it.

[Hunter Rose 10]

Who exactly ? where do these great minds reside ?

Right here, bro.

[progamer 14]

Arma 4 will not come out for at least 5 years.

[fumanwho 10]

No I understand it. I'm just defending my points because they are the only relevant portion of the argument that isn't steeped in semantics or biased uneducated opinion. You're ability to discern how I word things vis a vis how you want to interpret them is pretty immaterial to the real argument at hand.

And even still, you're quote of what I said with big bold letters, is still not me saying that concurrency is some end all be all goal for the developers to pursue. It's simply saying that more processing power is better, be it from a faster processor or through better concurrency or through optimization of program code.

Stupid argument is stupid.

Are you saying bis should optimise their code? To get more performance.

[windies 11]

Are you saying bis should optimise their code? To get more performance.

Never said they shouldn't.

[10t 12]

...if I had said "better concurrency is A way to achieve that goal", it wouldn't come off as an absolute.

Well, yes. If you had used different words, then what you wrote would have meant something different. And the distinction between those two things and why it's important is what I was pointing out. Though, if you had put it that way, it would have been a little at odds with the rest of that post. Even the rest of that paragraph.

I said that saying process concurrency is not a goal and is unimportant is misleading...

You're quite right - saying it's unimportant would be misleading. That said, I've seen no-one say that process concurrency is unimportant. Maruk's post which you responded to was in fact him pointing out the difference between the statements "concurrency is not a goal" and "the number of threads avaiable for resource handling won't improve current RV's state". To which you replied (in part) "hardware usage is exactly what you want to measure". Which prompted my post, re-stating the difference between those things.

The problem with your whole argument, is that it goes against the tide of technology as it stands today and in the future.

I truly hope it doesn't, since what I'm saying applies not just to process concurrency but to "ways of trying to make things better". In any field. IT, business, medicine, gardening, cheesemaking.

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.

For my part, I'd summarise your point as "All else being equal, an increase in hardware usage (under load) means an increase in performance. Therefore the focus should be on increasing the amount of hardware usage available to the engine and the success or otherwise of that effort can be measured by hardware usage".

Edited October 15, 2013 by 10T

[dm 9]

Honestly, it has to happen if an A4 ever happens

In your opinion :)

You can teach some tricks to an old dog, but the dog don't get younger with that, will be somewhat rusted\slower in doing so and eventually it will die.

Once again, the core engines behind CoD, BF, and pretty much every other game out there is "old".

Hell, even GTA V is built on a 7 year old engine... Are you expecting Rockstar to toss it out and start a fresh in GTA VI too?

[fumanwho 10]

Never said they shouldn't.

I wasnt asking you to discuss anything you have not said. Why are you unable to give a straight answer?

[Polygon 11]

In your opinion :)

Once again, the core engines behind CoD, BF, and pretty much every other game out there is "old".

Hell, even GTA V is built on a 7 year old engine... Are you expecting Rockstar to toss it out and start a fresh in GTA VI too?

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

GTA4-5 engine is mostly optimized for consoles, as on PC it was rubbish (worse than A2 or anything). If everything is well within the engine, why rewrite it? }

You assume that RV in its scalability and potential will never be outdated thus requiring a >50% low-level rewrite or such?

Not an engine programmer, but with every iteration RV seems to improve, and I'm quite satisfied with its current state, excluding MP performance and focus on polycount/renderer scale, instead of actual functionality that improves / affects gameplay - the most important element - heavily.

[Smurf 12]

Once again, the core engines behind CoD, BF, and pretty much every other game out there is "old".

Hell, even GTA V is built on a 7 year old engine... Are you expecting Rockstar to toss it out and start a fresh in GTA VI too?

No, bacause what they have now seems to work pretty well with modern hardware and make use of them. When

can be true for every release and Dev "joke" about "welcome to the 2000's", you know something is not right.

[calin_banc 19]

Not an engine programmer, but with every iteration RV seems to improve, and I'm quite satisfied with its current state, excluding MP performance and focus on polycount/renderer scale, instead of actual functionality that improves / affects gameplay - the most important element - heavily.

Well, ArmA is the same thing as The Elder Scrolls - decent, but it needs community help to make it truly good. It's hard to wrote in idea about the gameplay without being dismissed as "this is not a simulation", "this is not priority", "this is not CoD/Bf" etc. For a realistic infantry-military-sort-of-a-game, it falls short - no shooting from the car, no bipods or any kind of weapon resting, difficult customization (you have to take the weapon from the ground, remove the accessories, take yours back again, put the accessories on it and make you way THEN), no easy customization from the Editor (no fog slider or other stuff like that as well, like a map editing tool), no way to easy jump over obstacles, climb (climb using ropes or rappel down), moving around stuff on the map, no proper physics on the avatar or vehicles (making all sorts of stunts and accidents with the sports car at 300km/h plus is fun, rolling over with the quad bike can be fun as well, but overall game breaking), incredibly stupid/cheating AI (sorry, but it is a proper mess and pain in the bum to play with them on open ground/filed scenarios) and so on. Sure, hard core fans or people like me who like the game with all of its shortcomings can still enjoy it and have some nice hours of fun in it, but that doesn't mean it good enough.

Anyway, polygons and new GPU effects can be added, most of the time a high end GPU has a lite load to process if you don't throw silly amounts of AA or downsampeling on it. Overall, I must say, a good, solid jump from ArmA 2 which says it all really - if you want, it can be done!

Also, until now engines were hold back by consoles, we all know that. Slowly, new ones will be here that can do more or less, the same thing - http://www.dsogaming.com/news/ubisoft-explains-why-it-created-a-new-engine-for-watch_dogs-instead-of-licensing-one/

“We built the Disrupt Engine alongside the project, since the beginning. We knew what we wanted to achieve required us to build new tech. This was caused by the density of a modern day city, the staggering amount of details, the ability to cross this world at speeds of 150 miles an hour while preserving all the details, our intention to push the player immersion and the high fidelity of the world. But beyond that, we wanted to have a dynamic game world that reacted to the players actions. Our game direction did not allow for a static world that only played carefully pre-designed scenarios. In WATCH_DOGS, players have the freedom to choose their own plan using a large array of approaches and the game needs to respond to them. This required us to increase the interactivity of our game engine affecting all areas: physics, graphics, animation, AI…â€

Now that sounds great, especially if Watch_Dogs stays true to those dynamic claims. But what about the other engines like CRYENGINE and Unreal Engine 4? According to Dominic, there are no solutions that match Ubisoft’s criteria for Watch Dogs, as those engines are very much driven toward serialized content.

“Now, on the subject of third party technologies, there are no solutions that we know of that matches those criteria available. The engines you refer to are very much driven toward serialized content that you generally traverse through “levelsâ€, not a fully open world game without choke points and loadings. They also manage online in a traditional manner, having you go through lobbies and menus, separating multiplayer and single player. There is also a considerable strength in having full ownership on one technology. It empowers the developers and favours innovation in every areas. It guarantees that no area of the technology is a black box, that the team can adapt and extend the game’s engine to answer all of its needs.â€

Sure, a city, even a big one, is nothing compared to the size of Stratis alone, never mind Altis, but size alone isn't everything, is about making sure you have rich, vivid world that feels ALIVE. :)

[jiltedjock 10]

For my part, I'd summarise your point as "All else being equal, an increase in hardware usage (under load) means an increase in performance. Therefore the focus should be on increasing the amount of hardware usage available to the engine and the success or otherwise of that effort can be measured by hardware usage".

Anyone who already runs their single player missions using the method I described in Post 189 already knows that the client engine runs better when the AI processing is offloaded to an otherwise unused core. Therefore it seems to be a reasonable statement, in the context of this engine. Given a ground up engine rewrite is extremely unlikely, improving the concurrency of processing by the existing engine by a means similar to this seems a worthwhile avenue to explore.

[windies 11]

Anyone who already runs their single player missions using the method I described in Post 189 already knows that the client engine runs better when the AI processing is offloaded to an otherwise unused core. Therefore it seems to be a reasonable statement, in the context of this engine. Given a ground up engine rewrite is extremely unlikely, improving the concurrency of processing by the existing engine by a means similar to this seems a worthwhile avenue to explore.

Some people just want to argue the status quo because it IS the status quo irregardless of facts or information presented to them contra to their point.

[Make Love Not War 10]

If you offload the mission AI to a separate core by running your mission on a dedicated server instance - on your quad core alongside your client - your client performance, as measured by average FPS in the client, is better and less prone to spikes. Additionally, the mission AI is usually noticeably better. Finally, all the TPW suppression, GL4 or whatever else scripts you are running are local to the server which again takes the load off the client..

You brought this up again, so I gotta admit I don't understand what you're doing here. As far as I always understood it, dedicated server means that the PC running the server can't be used concurrently as a client. That's the whole point of "dedication", right? Can you please explain your process here in greater detail?

Edited October 15, 2013 by Make Love Not War
spelling

[10t 12]

Anyone who already runs their single player missions...

Ok. I get what you're saying. I don't have any idea how it's relevant to anything I've said, let alone the bit of my post you quoted. Could you do the summary thing I mentioned (in the paragraph immediately before that) for me? Otherwise I can't reply sensibly at all.

[ric 1]

@windies , this has a 30 day free trial, give it a shot and tell us what you find.

https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1503&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=EVAL〈=

Performance profiler for serial and parallel performance analysis.

Collect a rich set of data to tune CPU & GPU compute performance, multi-core scalability, bandwidth and more

Sort, filter and visualize results for quick insight into performance bottlenecks

Automate regression tests and collect data remotely using the powerful command line

[jiltedjock 10]

Ok. I get what you're saying. I don't have any idea how it's relevant to anything I've said, let alone the bit of my post you quoted. Could you do the summary thing I mentioned (in the paragraph immediately before that) for me? Otherwise I can't reply sensibly at all.

The gist of it is that because you are running the the mission on the dedicated server, AI gets offloaded to its own core [cores, really, as it uses about 1 and a half] running under the server executable, and therefore scripts, spawns etc do not affect any of the threads running under the client exe. In effect, this is more concurrent processing albeit because 2 exes are running. And because the impact of this is better client performance, it is relevant to the discussion - increased concurrent processing is leading to measurably better client performance.

It may show a way forward for scaling the engine up to quad cores or greater in a way which it doesn't at the moment.

---------- Post added at 10:10 PM ---------- Previous post was at 10:08 PM ----------

You brought this up again, so I gotta admit I don't understand what you're doing here. As far as I always understood it, dedicated server means that the PC running the server can't be used concurrently as a client. That's the whole point of "dedication", right? Can you please explain your process here in greater detail?

Save your mission as multiplayer, launch it on your PC using the server executable, launch the client exe and join the server. Obviously you have to set the server up properly but that is covered in many other threads.

[das attorney 858]

//

Forgive me if I snip out your whole quote.

I totally agree with what you're saying here. I've done lots of tests and found that running the mission on DS and joining as client on the same PC will use my CPU about 70% - 80% on all 4 cores (not that that is the goal) - but, it's much smoother as client and less stutter when units spawn in.

I'm going to do a little vid and tutorial as I have a mission coming out soonish. In fact, I'm really tempted to disable SP and if people want to play in SP, then they'll have to launch a DS on their own PC.

Maybe that won't be a popular approach, but will guarantee much better performance than running as an SP mission.

As a mission maker, I would rather deal with complaints about how to launch it rather than complaints about shit performance.

[Make Love Not War 10]

Save your mission as multiplayer, launch it on your PC using the server executable, launch the client exe and join the server. Obviously you have to set the server up properly but that is covered in many other threads.

Thanks for the explanation; I will definitely give that a shot. Interesting find in regards to the performance boost.

Edit: @Das Attorney: Yeah, both disabling SP for your missions along with tutorials on running through a DS are excellent ideas. Although, if people are already able to improve performance in this manner, it really makes me scratch my head as to Marek's overall position regarding the concurrency issue (ie., any potential improvements to performance are not worth the investment in programming time and effort).

Edited October 15, 2013 by Make Love Not War

[10t 12]

The gist of it is...

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.

[jiltedjock 10]

Forgive me if I snip out your whole quote.

I totally agree with what you're saying here. I've done lots of tests and found that running the mission on DS and joining as client on the same PC will use my CPU about 70% - 80% on all 4 cores (not that that is the goal) - but, it's much smoother as client and less stutter when units spawn in.

I'm going to do a little vid and tutorial as I have a mission coming out soonish. In fact, I'm really tempted to disable SP and if people want to play in SP, then they'll have to launch a DS on their own PC.

Maybe that won't be a popular approach, but will guarantee much better performance than running as an SP mission.

As a mission maker, I would rather deal with complaints about how to launch it rather than complaints about shit performance.

Yes, it is particularly good for playing missions such as MSO or HAC as a single player, with many AI spawns occuring and no stutter for the client.

[windies 11]

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.

I assumed things like the headless client where known by most all anymore as examples of how more process concurrency would help performance from within the engine, aside from obvious reasons.

Do you understand my argument towards the developers now though?

[calin_banc 19]

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).

As you can see the CPU usage obviously increased as well. That is/was the whole point of "better scaling on multiple cpu cores"/"better concurrency.