re: Beyond recommended requirements - Terrible Performance

[AlecDelorean 10]

Yeah, i spent some time... B-)

There are way too many dirty ripoffs and edits around at this time. Mission makers have to keep in mind that scripting has to be more elegant and efficient, make more use of the modules and tools BI already provides within the A3 editor.

@Myke

i know what you want to say, but you have to admit that the best rig for A3 seems to be a dualcore 10GHz CPU with 4 GB RAM and a 3 GB VRAM GPU running Win7 32bit. Very unrealistic. I have an i7 extreme 6 core, 24 GB DDR3 RAM, nvidia 3 GB VRAM (384bit DDR5) running Win7 Ultimate and A3 on a SSD. I think i pretty much have the engine and the fueltank for the year 2013...

[maddogx 13]

4. NOW go back into the editor and place some friendly AI direct in front of you (not 1 - 5 units only, add complete squads, "This is war" you know...) Then preview again and watch how your CPU keeps that usage of 40-60%, your FPS going down and your GPU taking a break because it has to wait longer for the CPU (GPU usage going down). Repeat adding AI as you like and watch your FPS going down more and more...

This is the really strange part, because it supposedly shouldn't be the case since ARMA2. According to this blog post (specifically mousing over picture number 2), the AI path calculations should be happening separately from the main rendering thread. In other words, adding more and more AI should mainly affect the speed of AI path calculations and not bog down the renderer so much.

Ideally, if the AI threads were running 100% asynchronously from the renderer (no thread locks), the effect of AI path calculations on rendering performance would even be zero; but clearly this is not the case.

[AlecDelorean 10]

I'm running the DEV build since the first Alpha release and i had lots of fun playing A3 over the last months, so i don't want to complain about anything yet (it's still a BETA). I'm just getting curious. In 2 days we will see, please let the miracle happen...

[verstand3n 13]

shouldn't the cpu load go up when more AI's are calculated?

[maddogx 13]

shouldn't the cpu load go up when more AI's are calculated?

In theory, yes. In practice however... *shrug*

Edited September 10, 2013 by MadDogX
spelling

[[frl]myke 14]

@Myke

i know what you want to say, but you have to admit that the best rig for A3 seems to be a dualcore 10GHz CPU with 4 GB RAM and a 3 GB VRAM GPU running Win7 32bit. Very unrealistic. I have an i7 extreme 6 core, 24 GB DDR3 RAM, nvidia 3 GB VRAM (384bit DDR5) running Win7 Ultimate and A3 on a SSD. I think i pretty much have the engine and the fueltank for the year 2013...

I was pointing to the fact that making a 64bit exe wouldn't help at all. A3 can use up to 4GB but it doesn't use it. So giving more RAM to use wouldn't help since it wouldn't use it. Once A3 fills up the 4GB it can use, then would be the time to ask for a 64bit application. Until then, it requires optimization so it really uses the resources it already could. That's what i meant with the analogy.

[windies 11]

Myke;2496295']I don't see how AI calculations done by CPU might profit from more RAM. It's like saying that if your car isn't running fast enough' date=' you'll need a bigger fueltank. A3 is LAA and can therefor use up to 4GB.[/quote']

Yeah but that's both paged and non paged. So basically if you set Maxmem=2047 it will only use up to 2047mb of Physical ram and then 1.5x of that in paged memory, because that is how the engine is set to distribute it. You're still only using 2gb of actual physical RAM at most. You don't know that it wouldn't use it because the engine is programmed through a hard limit not to use it.

I'm not supporting though that it will improve AI calculations haha.

---------- Post added at 12:01 ---------- Previous post was at 11:49 ----------

This is the really strange part, because it supposedly shouldn't be the case since ARMA2. According to this blog post (specifically mousing over picture number 2), the AI path calculations should be happening separately from the main rendering thread. In other words, adding more and more AI should mainly affect the speed of AI path calculations and not bog down the renderer so much.

Ideally, if the AI threads were running 100% asynchronously from the renderer (no thread locks), the effect of AI path calculations on rendering performance would even be zero; but clearly this is not the case.

It's been the issue since the beginning of the Alpha, although I think it has more to do with the FSM behaviors than it does from pathfinding. Put 100 AI down and give them all aware or combat full speed waypoints and watch your FPS drop, then switch them all to careless behavior and watch as your FPS is affected but not nearly as bad. Careless behavior disables or skips some of the FSM Behavior routines which alleviates some of the problem.

[AlecDelorean 10]

Well, from my humble view, if you can take some load from the cpu (loading textures, objects, geometry etc. from the HDD, swapping the data) because they're already in RAM you indirectly save some time for calculating AI per frame... And Altis is a hungry beast, give it a bigger belly.

64bit is also about more bandwidth...

Edited September 10, 2013 by AlecDelorean

[[frl]myke 14]

Well, from my humble view, if you can take some load from the cpu (loading textures, objects, geometry etc. from the HDD, swapping the data) because they're already in RAM you indirectly save some time for calculating AI per frame... And Altis is a hungry beast, give it a bigger belly.

64bit is also about more bandwidth...

Compiling in 64bit wouldn't solve these problem since the engine isn't written that way. You can see this already now. What is the memory footprint of A3 actually? Does it fill up the 4GB it can use? Or does it stay below 2GB? If it stays below 2GB, why doesn't it use more? Why does it leave more than half of the available RAM unused? It's the engine. It is designed to reload and swap data. Even if you would make it a 64bit application and have 128GB Ram installed, it wouldn't make a change since the engine isn't designed for this.

[AlecDelorean 10]

@Myke

I know what you are saying, all this is already known, i read it on several statements. You are slowly coming to the point. The decision to go 64bit had to be made several years ago. It would mean a massive overhaul for the engine. Consuming lots of time, money and manpower. Maybe all these problems will get sorted out through harder optimizing the engine as it is in the moment, but i cant let go of the feeling that on some point the designers just ignored what programmers recommended or vice versa. Again, just my opinion, from my perspective.

[windies 11]

Myke;2496461']Compiling in 64bit wouldn't solve these problem since the engine isn't written that way. You can see this already now. What is the memory footprint of A3 actually? Does it fill up the 4GB it can use? Or does it stay below 2GB? If it stays below 2GB' date=' why doesn't it use more? Why does it leave more than half of the available RAM unused? It's the engine. It is designed to reload and swap data. Even if you would make it a 64bit application and have 128GB Ram installed, it wouldn't make a change since the engine isn't designed for this.[/quote']

ArmA 3 fills up a max of I believe 3.5gb of available RAM between paged and nonpaged. It can't use anymore than that because it's a hard limit. You wouldn't know if the program used more unless you compiled it for 64 bit and rewrote how the memory is addressed through the malloc. Trying to say that "OK, in a 32 bit environment ArmA doesn't use more than 3.5gb" is foolish because that's a hard limit that it could never pass due to architecture.

I would guess that with Altis loaded, depending on view distance and object distance and various settings, ArmA could easily have a footprint of 6gb-8gb easily. I mean if it didn't, why would we need disk streaming to get around the 32 bit barrier? What do you think reloading and swapping data is if it's not a memory footprint? It's literally the same thing as paged versus nonpaged memory. It's their "Non-addressable Memory Store", basically they bypass the inherent limits of 32 bit addressing by trying to use a file mapping API to address memory which is a very slow and inadequate way of doing it for the demand that the engine requires.

The proof of that is in the game itself and the inherent issues with smooth loading assets, smooth loading LOD's and Objects, the tricks used to lower memory usage like lowering texture's on objects both near and far and lowering object LOD's. The massive stuttering problems with trying to keep Altis data in memory before needing to swap it out for more Altis data.

I agree with you that the engine isn't designed for 64 bit memory addressing, but does that mean that it's optimal to use 32 bit addressing forever or even right now in this case? You're argument centers around "The engine isn't written for it so it wouldn't benefit from it" and the only thing you are right about is that the engine isn't written for it. It would benefit from it, if it was written for it.

[AlecDelorean 10]

I second that! Thank you Windies.

I wonder if, at least at the very beginning, in that small time window when the decision fell "Let's make Arma 3..." the idea of going 64 bit was even on the table. And then, why they decided against it... Well, too late for now. They made so many right decisions, the game looks amazing, the controls and the handling are so much better, the new features, designs, AI improvements, the setting etc. - there are so many things i like about this game. I really hope these performance issues will not become the stab in the back of A3.

[TSAndrey 1]

Myke;2496236']Um' date=' no. Minimum from latin "minimus" = least, smallest. So lowest settings. Recommended stands for "Normal" like normal settings. This misinformation is the cause for people complaining they can't run the game on high although their PC has recommended specs. One has recommended specs, he start with normal settings and the game should be playable with decent FPS.[/quote']

Nah, in many cases people below minimum requirements can run games on low settings, while people around minimum requirements can play it on Normal or higher. (I don't directly mean A3)

[[frl]myke 14]

ArmA 3 fills up a max of I believe 3.5gb of available RAM between paged and nonpaged. It can't use anymore than that because it's a hard limit. You wouldn't know if the program used more unless you compiled it for 64 bit and rewrote how the memory is addressed through the malloc. Trying to say that "OK, in a 32 bit environment ArmA doesn't use more than 3.5gb" is foolish because that's a hard limit that it could never pass due to architecture.

I would guess that with Altis loaded, depending on view distance and object distance and various settings, ArmA could easily have a footprint of 6gb-8gb easily. I mean if it didn't, why would we need disk streaming to get around the 32 bit barrier? What do you think reloading and swapping data is if it's not a memory footprint? It's literally the same thing as paged versus nonpaged memory. It's their "Non-addressable Memory Store", basically they bypass the inherent limits of 32 bit addressing by trying to use a file mapping API to address memory which is a very slow and inadequate way of doing it for the demand that the engine requires.

The proof of that is in the game itself and the inherent issues with smooth loading assets, smooth loading LOD's and Objects, the tricks used to lower memory usage like lowering texture's on objects both near and far and lowering object LOD's. The massive stuttering problems with trying to keep Altis data in memory before needing to swap it out for more Altis data.

I agree with you that the engine isn't designed for 64 bit memory addressing, but does that mean that it's optimal to use 32 bit addressing forever or even right now in this case? You're argument centers around "The engine isn't written for it so it wouldn't benefit from it" and the only thing you are right about is that the engine isn't written for it. It would benefit from it, if it was written for it.

I stand corrected. Didn't knew about A3's memory footprint.

I can only guess that BI didn't rewrote the engine for 64bit because it would have taken too much resources and time. But that's only guesswork, nothing official.

---------- Post added at 08:59 ---------- Previous post was at 08:57 ----------

Nah, in many cases people below minimum requirements can run games on low settings, while people around minimum requirements can play it on Normal or higher. (I don't directly mean A3)

What people "can" and what it effectively means are two different pair of shoes.

[call_911 10]

Has anybody noticed/experienced a slight performance improvment on Altis after last dev branch? I OC'd cpu to 3.9-4.0ghz, made sure each time i run ArmA I set priority to high in task manager an steam to low. Also tried some command lines/game settings from http://www.day0.com.au/forum/arma/70-arma-3-alpha-performance-tweaks-and-settings-guide not much to scream an shout over but least I can somewhat function in game now. Was getting upper teens to low 20 fps an now it's upper 20 fps to maybe 30-32fps. And what is it about ArmA an turning things on high or ultra having a reverse effect than what u'd originally think? Noticed that in ArmA1 an ArmA2 also.

[Zorg_DK 10]

I haven't seen A3 go over 2gb. 2047 is the highest you can set -maxmem to, right? It would be nice if it could be set to 4096. 2gb seems like a very low number for such a complex game, and for instance everytime I open the map the game has to draw all the textures, I don't know if that's because I only have 1gb of video ram though.

Has anybody noticed/experienced a slight performance improvment on Altis after last dev branch? I OC'd cpu to 3.9-4.0ghz, made sure each time i run ArmA I set priority to high in task manager an steam to low. Also tried some command lines/game settings from http://www.day0.com.au/forum/arma/70-arma-3-alpha-performance-tweaks-and-settings-guide not much to scream an shout over but least I can somewhat function in game now. Was getting upper teens to low 20 fps an now it's upper 20 fps to maybe 30-32fps. And what is it about ArmA an turning things on high or ultra having a reverse effect than what u'd originally think? Noticed that in ArmA1 an ArmA2 also.

I've only tested in the editor with a limited units in place, but yes, it's very smooth now, with minimal stutter.

[maddogx 13]

Has anybody noticed/experienced a slight performance improvment on Altis after last dev branch? I OC'd cpu to 3.9-4.0ghz, made sure each time i run ArmA I set priority to high in task manager an steam to low. Also tried some command lines/game settings from http://www.day0.com.au/forum/arma/70-arma-3-alpha-performance-tweaks-and-settings-guide not much to scream an shout over but least I can somewhat function in game now. Was getting upper teens to low 20 fps an now it's upper 20 fps to maybe 30-32fps. And what is it about ArmA an turning things on high or ultra having a reverse effect than what u'd originally think? Noticed that in ArmA1 an ArmA2 also.

Yeah, with a reasonable number of AI (~50-60) it's very smooth on Altis. Also tested a small MP coop (just two people) and it worked very well.

It's mainly the larger scale battles where the problems start.

[k3lt 3]

Yeah, with a reasonable number of AI (~50-60) it's very smooth on Altis. Also tested a small MP coop (just two people) and it worked very well.

It's mainly the larger scale battles where the problems start.

You mean 60 AI spread all over the map?

Try to put 60 AI fighting each other in Kavala and check fps.

I bet it will dip into some low 30's even with your overclocked i7 2600k.

Edited September 11, 2013 by k3lt

[maddogx 13]

You mean 60 AI spread all over the map?

Try to put 60 AI fighting each other in Kavala and check fps.

Not spread out, no, it was fairly tight quarters. I had roughly 40 vs. 20 (including myself and a couple of vehicles) fighting over the bio-dome structures near the center of the map. (No scripting except for a few triggers and task modules.)

Haven't tried fighting in Kavala yet, but it's worth a shot. Will probably do that tomorrow for the full release.

[fortune 10]

Not spread out, no, it was fairly tight quarters. I had roughly 40 vs. 20 (including myself and a couple of vehicles) fighting over the bio-dome structures near the center of the map. (No scripting except for a few triggers and task modules.)

Haven't tried fighting in Kavala yet, but it's worth a shot. Will probably do that tomorrow for the full release.

Hey Guys i tested Stuff like placing AI teams in different locations too.

I simply made groups fighting each other consisting of 1 OPfor 1 Bluefor 1 Indep Rifle Team so were talking about 24 AI's per location x 8 = 192 infantery AI units (They all were Set in a circle of approx max 200 m.

If you place the AI on nearly open fields they just kill each other without much struggling but putting them into Big towns (no matter where youself on the map in the editor) the fps drops to below 25 as stated by k3lt. So for me it seems like due to the fact the AI is not "scripted" but rather acting like individuals (more or less) takes more calculating power the more complex the Terrain is. If you only put them to open Terrain like airfields it doesnt starts lagging like you place em in towns.

Windows 7 64Bit

EVGA Classified 3 e759

i7 920 @ 4.4 Ghz / HT on

12GB Dominator GT DDR3 @ 1866 / 9.9.9.27

GTX Titan 1175 Mhz Core 3200Mhz Ram

Game rests on a dedicated Samsung 840 SSD (128GB)

res. 2560*1440

Edited September 11, 2013 by fortune
spelling

[maddogx 13]

Hey Guys i tested Stuff like placing AI teams in different locations too.

I simply made groups fighting each other consisting of 1 OPfor 1 Bluefor 1 Indep Rifle Team so were talking about 24 AI's per location x 8 = 192 infantery AI units (They all were Set in a circle of approx max 200 m.

If you place the AI on nearly open fields they just kill each other without much struggling but putting them into Big towns (no matter where youself on the map in the editor) the fps drops to below 25 as stated by k3lt. So for me it seems like due to the fact the AI is not "scripted" but rather acting like individuals (more or less) takes more calculating power the more complex the Terrain is. If you only put them to open Terrain like airfields it doesnt starts lagging like you place em in towns.

Windows 7 64Bit

EVGA Classified 3 e759

i7 920 @ 4.4 Ghz / HT on

12GB Dominator GT DDR3 @ 1866 / 9.9.9.27

GTX Titan 1175 Mhz Core 3200Mhz Ram

Game rests on a dedicated Samsung 840 SSD (128GB)

res. 2560*1440

Yeah, it makes a lot of sense that AI pathfinding calculations become more complex in dense urban areas. It's just too bad that the framerate impact from this is so severe, as it is something that should be happening asynchronously/concurrently to the rendering process.

[k3lt 3]

It has nothing to do with AI pathfinding (or not much atleast), in open fields i'm getting nearly 60fps most of the time but when i enter major city (even without AI) my fps drops by a half to 30 and below. (Agia Marina is very good example)

Rendering cities/villages is the biggest performance hit in my opinion, not ai calculations.

This is from my experience.

[fortune 10]

It has nothing to do with AI pathfinding (or not much atleast), in open fields i'm getting nearly 60fps most of the time but when i enter major city (even without AI) my fps drops by a half to 30 and below. (Agia Marina is very good example)

Rendering cities/villages is the biggest performance hit in my opinion, not ai calculations.

This is from my experience.

Oh okay, that differs from my experience giving this a try when coming home later. If there is no AI involved i usally get 45+ FPS all over the map execpt some really strange render behaviors like stand on the feets of the big Military like Towers. I could try to make a Video of it or give you the exact coords on altis of the Tower. I get a stable fps of 60 on an empty Server but stepping on one the the concrete sockets of the Tower fps Drops to 5-8 and only recovers if i leave the socket. This happened to 2 of my friends in the exact same way to give some more examples.

Edited September 11, 2013 by fortune

[maddogx 13]

It has nothing to do with AI pathfinding (or not much atleast), in open fields i'm getting nearly 60fps most of the time but when i enter major city (even without AI) my fps drops by a half to 30 and below. (Agia Marina is very good example)

Rendering cities/villages is the biggest performance hit in my opinion, not ai calculations.

This is from my experience.

That's true but not really surprising, as rendering hundreds of high detail objects doesn't happen "for free". It's pretty obvious that an empty field with just a couple of small objects renders much faster than a huge town with dozens of nearby buildings (including interiors). The engine will try to reduce distant LODs to lower the scene complexity, but this only works up to a certain point.

Your framerate in towns will be heavily dependent on your object detail setting and view distance (something a lot of people tend to set way too high). With object details on standard and view+object draw distance at 3km, I can run through an empty Kavala with 50+ fps.

[k3lt 3]

That's true but not really surprising, as rendering hundreds of high detail objects doesn't happen "for free". It's pretty obvious that an empty field with just a couple of small objects renders much faster than a huge town with dozens of nearby buildings (including interiors). The engine will try to reduce distant LODs to lower the scene complexity, but this only works up to a certain point.

Your framerate in towns will be heavily dependent on your object detail setting and view distance (something a lot of people tend to set way too high). With object details on standard and view+object draw distance at 3km, I can run through an empty Kavala with 50+ fps.

I run with object/terrain detail at lowest settings with 1k/800m view/detail distance.

In your opinion, those settings too high for recommended system specs?

Or should i play with everything turned off/low in windowed mode @ 320x240 resolution?