Serious unexplainable Performance Differences - got proof

[dmarkwick 261]

Okay I get what you are saying - but then that's still something unnecessary, isn't it?

Just because you could theoretically look trough a hypothetical window in the house doesn't mean they can't cull if there isn't a window.

Well, possibly, my interest in game engines is strictly amateur, but we all know that ArmA/ArmA2's engine is necessarily different from other games in that it needs to be open and all structures have the possibility of being destroyed. So there is no possibility of optimisation techniques like BSP trees etc, because there is no permanent geometry apart from the terrain.

It goes a bit with above tests - maybe material is not only used for penetration but also for culling, so wood - often seen on fences and other "see-trough stuff" might have different culling than concrete.

You might be right about that, but I think it's more likely to be related to view geometry. Perhaps both are used.

[Meek 10]

Is the concept really that hard to grasp? If you are inside a town or village, you are looking towards walls ALL of the time. Not towards ONE specific wall, but you are basically encircled by walls, and if the engine renders stuff behind those walls it's absolutely pointless for gameplay, bad for performance.

What you said was completely correct, but you are forgetting an important factor.

The game needs to determine if you are able to see the object behind that building or not.

In most FPSes (Half-Life 2 for example) what parts of the map the player can/can't see is determined when the map is being compiled, this works well in such games, where the game is mostly inside buildings and confines areas.

ArmA2 would not be able to use the pre-compiled check of what the player can/can't see because buildings are destructible. This means that a more computationally expensive method of determining hidden objects would be used, and that it must be done at runtime, and for a much larger area of the map. A hidden object check in ArmA2 would be substantially more computationally expensive than regular FPSes.

Let's take a look at some examples.

• Flying an aircraft
  
• Parachuting
  
• Standing on the top of the hill
  
• Standing in the middle of a field
  
• Standing in a forest
  
• Standing on top of a tall building
  

Under most circumstances you will be able to see nearly everything, running a hidden object check would most likely result in something we already know, nearly everything is visible. Congrats, you just wasted processing power. Frames were potentially dropped :butbut:.

Let's say you are inside a structure or inside a city, this is the only time when a hidden surface removal would be profitable, framerate improves significantly . But at the cost of frames being dropped in all other situations.

ArmA2 is not the only game that doesn't do hidden surface removal checks, it's quite common in games that are sandboxy.

Do not misinterpret me, I think there is lots of room for optimisation, but this isn't one of them.

[Helmut_AUT 0]

Valid point, good argument. The irony is of course that those few places where a visibility check might actually help are those were a lot of detail is visible and slows down GFX considerable.

And I'd still love to find out what the deal is when looking at the ground. I think these are separate things we're looking at here - one is the lack of culling/frame rate improvement when facing a wall, the other is that there seems to be a constant rendering overhead even if there is REALLY nothing in your view except a ground texture.

Oh, found something else: http://forums.bistudio.com/showthread.php?p=1305947#post1305947

The color grading in some missions is purely done by shader, they can also add film grain. While it looks cool I wonder if that doesn't confirm my assumption that a lot of the bottlenecks we are seeing at high res are actually shaders. I know for example in SH4, enabled post processing costs 20% frame rate. Here this almost seems like they have different layers of post processing stacked onto each other, which would explain why even monster cards struggle with high resolutions.

Edited June 10, 2009 by Helmut_AUT

[dmarkwick 261]

And I'd still love to find out what the deal is when looking at the ground. I think these are separate things we're looking at here - one is the lack of culling/frame rate improvement when facing a wall, the other is that there seems to be a constant rendering overhead even if there is REALLY nothing in your view except a ground texture.

I think, if we take the previous explanations as valid, then it's possibly as simple as culling taking place on a purely horizontal directional basis. That is, the same culling is done on your orientation whether or not you're looking up or down. A simple cull of all objects behind your left & right bearings.

Oh, found something else: http://forums.bistudio.com/showthread.php?p=1305947#post1305947

The color grading in some missions is purely done by shader, they can also add film grain. While it looks cool I wonder if that doesn't confirm my assumption that a lot of the bottlenecks we are seeing at high res are actually shaders. I know for example in SH4, enabled post processing costs 20% frame rate. Here this almost seems like they have different layers of post processing stacked onto each other, which would explain why even monster cards struggle with high resolutions.

I think you're right that a lot of FPS is gobbled up by fancy shaders. I'd like the opportunity to lose as many as I want for SP play certainly.

[ECH 10]

Thats exactly what they are trying to point out, massive problem with the graphics engine. This clearly displays that people are NOT getting the performance they should with the same amount of detail.

---------- Post added at 12:20 AM ---------- Previous post was at 12:15 AM ----------

This is called overdraw right? So this would mean that the graphics engine isn't properly communicating with the graphics cards. Therefor the graphics cards processing depth that you cant see. Which ultimately means that once again, BIS has not optimized correctly for the graphics cards.

So is this a problem when using ATI? Nvidia? or both?

Edited June 10, 2009 by ECH

[SANGEKi 10]

So is this a problem when using ATI or Nvidia video cards?

It's a "problem" with the engine itself.

[ECH 10]

... My system is

i7 @ 4.2Ghz

6Gb RAM 1600

GTX295 OC'ed

...I will loan my mates GTX285 and 4890 to test see which works best and i think the 4890 will beat out my gtx295

Once you do this could you create a new thread discussing the results? I would look forward to reading what you observed, thanks!

Edited June 10, 2009 by ECH

[POTS 0]

What you said was completely correct, but you are forgetting an important factor.

The game needs to determine if you are able to see the object behind that building or not.

In most FPSes (Half-Life 2 for example) what parts of the map the player can/can't see is determined when the map is being compiled, this works well in such games, where the game is mostly inside buildings and confines areas.

ArmA2 would not be able to use the pre-compiled check of what the player can/can't see because buildings are destructible. This means that a more computationally expensive method of determining hidden objects would be used, and that it must be done at runtime, and for a much larger area of the map. A hidden object check in ArmA2 would be substantially more computationally expensive than regular FPSes.

Let's take a look at some examples.

• Flying an aircraft
  
• Parachuting
  
• Standing on the top of the hill
  
• Standing in the middle of a field
  
• Standing in a forest
  
• Standing on top of a tall building
  

Under most circumstances you will be able to see nearly everything, running a hidden object check would most likely result in something we already know, nearly everything is visible. Congrats, you just wasted processing power. Frames were potentially dropped :butbut:.

Let's say you are inside a structure or inside a city, this is the only time when a hidden surface removal would be profitable, framerate improves significantly . But at the cost of frames being dropped in all other situations.

ArmA2 is not the only game that doesn't do hidden surface removal checks, it's quite common in games that are sandboxy.

Do not misinterpret me, I think there is lots of room for optimisation, but this isn't one of them.

Ah, what you say does make sense, but only if its equaly computationaly expensive to shut it down as it is to start it up. So I still dont think it would be a bad thing. But you still talk like a CPU is a weak part of your computer and it is not. A small counting control algorithm wouldn't be that hard to shutdown in the internal threads.

EDIT: Could you tell me what kind of other games do this?

[rowdied 44]

1920x1200

Fill rate 100% (set manually in .cfg)

Settings

Viewdistance = 3.5k

Textures - Very High

Text memory - Very High

AA - High

Terrain/Object/Shadow - Normal

PP - LOW

Now I have played with all settings one by one and FRAPs, doing a little benchmark by running around a set course (not 100% accurate but it gives you and idea)

I run once to load the textures into memory, then record it.

Basically Textures drop my AVG by 1 going from Low to Very High

texture memory, Like wise Anistroptic filtering does not affect my performance at all.

Draw distance is negligable performance diff say going from 2500-4000 may lose 2 fps..

Like I said I am having difficulty in getting SLi going, I am just about to try after cleaning out drivers (I tried 4 drivers to see if any diff).. Going back to 186.08 now.

EDIT:

WOW FINALLY: Got SLi working!! Things I tried before but worked after using driver cleaner and re-installing drivers.. or could be new profile I made using nhancer?

Anyway what i did is clean drivers, install 186.08

I run game with -winxp -cpucount=8

Nhancer profile is copied from Arma 1, but I enabled multi core optimisation and of all things I used AFR-4 (Quad sli) * I have previously tried evry single setting in nhancer and didn't work *

Anyway that fixes one problem, no doubt nvidias next driver set should encompass a native profile for this game that works properly. I know I have been trying for days to get SLi going and when i almost gave up it seems to have kicked in.. I will do more testing and see what was the cause, as I know a lot of others were having SLi woe's, some managed to fix via "crysis.exe" trick, some used -winxp etc..

I'm glad to hear because I was running the dgame with your exact settings and was getting the same results with my Q9550 @ 3.4 and a gtx 260.

How is the 295 working now and what are your fps?

[FraG_AU 10]

I'm glad to hear because I was running the dgame with your exact settings and was getting the same results with my Q9550 @ 3.4 and a gtx 260.

How is the 295 working now and what are your fps?

Funny thing is that it has not changed much in the "cities' Still 30-35avg. Maybe why I didn't pick it up earlier.

In the wilderness its 40-60fps with avg of 48.

Before I was getting 29fps no matter what I did, whether I had shadows full or not etc..

I still think SLi is not being fully utilised but, new drivers bring new hope ;) The load balancing graph shows 65-70% Sli efficiency which is not the best!

[Fresh- 6]

Fascinating thread gentlemen...since the engine is new, we can only hope it will be optimized over time with the observations you bring to the table. Perhaps there are unforeseen engine characteristics causing these FPS differences. I have a good feeling things are going to be ironed out, as they always have been in previous engines.

In the meantime, I'm still having a hoot in multiplayer. I have my settings on 'very low' until I upgrade my video card, the engine seems fine and it's still beautiful!

[Balgorg 10]

The Arma 2 engine is just an updated version of the Arma 1 engine, itself updated from OFP. So thats the problem. Yes this game, and all the games in the linup are great modern warfare simulations, but how many times can you 'update' and engine?

So i recon the problem comes from the fact that BI need to develop a new engine from scratch. Imagine if the Quake engine from ID was endlessly recycled. ID realised that rather than updating an engine its better to make a new one. That way the engine can be styled from the ground up to produce the effects you need, and during development any major bottlenecks can be ironed out.

With Arma 2 they have been adding greater detail, more effects, and more complex AI, to an ageing engine. Sure the code has had a major over hall, but underneath its an old codger.

[Razorman 10]

;1306614']Fascinating thread gentlemen...since the engine is new' date=' we can only hope it will be optimized over time with the observations you bring to the table. Perhaps there are unforeseen engine characteristics causing these FPS differences. I have a good feeling things are going to be ironed out, as they always have been in previous engines.

In the meantime, I'm still having a hoot in multiplayer. I have my settings on 'very low' until I upgrade my video card, the engine seems fine and it's still beautiful![/quote']

Sorry to burst you bubble but this is NOT a new engine, it's a very old engine that's been constantly updated, this is ARMA 1.5 final, not ARMA 2.

Updated too much imho, it can't cope with whats being asked of it performance wise.

[householddog 10]

I tried out the same experiment in COD4. It doesn't seem to give any frame rate increase when stepping out from a wall.

Its possible it could be due to the insane frame rates I am getting (250fps) I am not really sure.

I played around with zbuffer settings using atitray, it really didn't seem to make much difference.

---------- Post added at 07:51 AM ---------- Previous post was at 07:48 AM ----------

Sorry to burst you bubble but this is NOT a new engine, it's a very old engine that's been constantly updated, this is ARMA 1.5 final, not ARMA 2.

Updated too much imho, it can't cope with whats being asked of it performance wise.

Dunno if its really updated either. You can pump huge renders, polys etc even into very old 3d engines.

You could even try replicating this Arma on the old DoomI 2D engine. It just a matter of getting very inefficient result. IE, what we are seeing now. ;)

[Shadowclaw 10]

Okay, this gets to the point where I really have to believe the engine has code problems or design problems. I can't explain it any other way, and I would really appreciate if we can hear from the devs here.

Using a GF9600GT, everthing to low except textures (normal) and shadows (normal), VD 1200, Fillrate 100% at 1920x1200.

Now, the test:

On the small island in Utres, walk to the first wooden house in Strelka, the first on the right as you come up from the beach.

Drop your gun.

Walk up to the house facing NW and place yourself directly in front of a stretch of wooden wall with NO windows or anything in it. With your nose touching the house, so the house blocks everthing else, straight on.

Gives me 24 FPS.

Now, I move to the opposite side of the house, walk up to a bare stretch of wood wall, and do the same.

34 FPS.

That's a 40% frame difference. Looking at the SAME texture from the SAME distance with nothing else on the screen.

I really can only explain this by assuming that they are not properly culling background objects as they get blocked by other things. Because when you are looking SE at the house, behind it is mostly open ocean. When you are staring NW "trough the house" you are looking at the destroyed church.

I have no way to take apart the engine and know what BIS has done here, but I do know that 40% framerate difference looking at the same texture should not happen. Can someone throw this on the bugtracker please?

I suppose the diffrence is really what the engine tries to do in the background. If it would just count this 1 texture it would give you insane fps but when you would turn around to look somewhere else your fsp would drop below ground zero because they haven't been "pre-calculated" what would make for a horrid game experience. At some point the diffrence in fps is logical.

I sure think you could optimize everything to a far better result than it is now.

[Helmut_AUT 0]

Okay, I now believe the poster who said A2 is totally CPU-bound.

With new 185 drivers, some detail changes and Keygets no-blur mod, I was able to raise my avg. in my "Strelak" benchmark to 29 from 22. Even if I apply the color correction function that tints everthing brownish.

But when I play "Trial by Fire" SP mission, with only a handfull of units - my framerate tanks down to 22.

This is the same village, same graphic settings, same color correction applied - it must be CPU-reasons why I'm seeing such decrease.

The graphics engine still is slow - still only gives me 18 fps sometimes in forrests or worse. I still believe it needs optimizing. But that doesn't matter when even the smaller SP missions already bottleneck me on a 5000+ AMD (which is better than recommended specs).

[von_paulus 0]

But that doesn't matter when even the smaller SP missions already bottleneck me on a 5000+ AMD (which is better than recommended specs).

Remember that your CPU has only 512Kbx2 in L2 cache. That's a bottleneck for sure.

[FraG_AU 10]

Funny thing is that it has not changed much in the "cities' Still 30-35avg. Maybe why I didn't pick it up earlier.

In the wilderness its 40-60fps with avg of 48.

Before I was getting 29fps no matter what I did, whether I had shadows full or not etc..

I still think SLi is not being fully utilised but, new drivers bring new hope ;) The load balancing graph shows 65-70% Sli efficiency which is not the best!

OK, did more tests my SLi is not working, back to square 1. What happened is my game crashed during some driver testing and reverted back to higher details, my fps boost simply came from lowering shadow detail/object detail to normal..

(PS> My avdanced settings tab was not coming up, I may have write protected the .cfg file when I was trying something)..

So yeah no SLi still.

[Cionara 10]

I haven't read the whole thread but what you describe in the first post is the same like when you're standing near a tree. It only happens on the shadow side. Like with the house, looking into the direction of the sun.

It's the HDR that does this framedrop. With a setting in the menu to disable HDR I think it would be a lot better. But they have to patch such a setting into the game.

There's Kegetys mod but it doesn't disable it, it just lays a new mask on the screen and Arma2 calculates the HDR although.

[POTS 0]

The Arma 2 engine is just an updated version of the Arma 1 engine, itself updated from OFP. So thats the problem. Yes this game, and all the games in the linup are great modern warfare simulations, but how many times can you 'update' and engine?

So i recon the problem comes from the fact that BI need to develop a new engine from scratch. Imagine if the Quake engine from ID was endlessly recycled. ID realised that rather than updating an engine its better to make a new one. That way the engine can be styled from the ground up to produce the effects you need, and during development any major bottlenecks can be ironed out.

With Arma 2 they have been adding greater detail, more effects, and more complex AI, to an ageing engine. Sure the code has had a major over hall, but underneath its an old codger.

I dont know how a completely new engine will help arma2. So I guess you want MORE bugs to fix? Besides, if BIS were to attempt to create a new engine, it would look very much like their current one, just with more bugs.

[Balgorg 10]

I dont know how a completely new engine will help arma2. So I guess you want MORE bugs to fix? Besides, if BIS were to attempt to create a new engine, it would look very much like their current one, just with more bugs.

I dont agree, many other developers have had success through the abandonment of their earlier engine.

Certainly tinkering with an existing engine can have decent results, examples of this are how the Quake engine was morphed into the Quake 2 engine. ID then abandon's the old build and came up with the Quake 3 engine. Other developers took the Quake 2 engine and modified it with great results, Halflife 1 is an example, also Daikatana (naff game, but great use of the older engine).

ID took the Quake 3 engine and developed it until they realised a new approach was needed, hence the Doom 3 engine. At the moment Carmac is working on a new engine.

Thing is, have you ever heard of major problems with these game engines? Over the years I have never had a single problem with any of ID's engines. Its different with COD 4's build of the Doom 3 engine, they have modified the existing build and this has led to incompatability and instabilty for many people.

I think that BI need to start again, and make Arma 3 all new. Sure it might be very much like the old engine, but it would be designed with modern hardware in mind. Fully use DX10, Quad cores and SLI with no problems. All the 3 latter are currently an issue with this arma 2 engine.

[POTS 0]

I dont agree, many other developers have had success through the abandonment of their earlier engine.

Certainly tinkering with an existing engine can have decent results, examples of this are how the Quake engine was morphed into the Quake 2 engine. ID then abandon's the old build and came up with the Quake 3 engine. Other developers took the Quake 2 engine and modified it with great results, Halflife 1 is an example, also Daikatana (naff game, but great use of the older engine).

ID took the Quake 3 engine and developed it until they realised a new approach was needed, hence the Doom 3 engine. At the moment Carmac is working on a new engine.

Thing is, have you ever heard of major problems with these game engines? Over the years I have never had a single problem with any of ID's engines. Its different with COD 4's build of the Doom 3 engine, they have modified the existing build and this has led to incompatability and instabilty for many people.

I think that BI need to start again, and make Arma 3 all new. Sure it might be very much like the old engine, but it would be designed with modern hardware in mind. Fully use DX10, Quad cores and SLI with no problems. All the 3 latter are currently an issue with this arma 2 engine.

You know how old the source engine is? DX10 is not that good, dont buy into that please. And the engine is called real virtuality 3 btw. ArmA used real virtuality 2.

[DaveG 0]

I doubt it's the hdr causing the slowdown since it's working all the time. It's most likely to do with the z buffer which all games use to make sure stuff that's behind other stuff doesn't get drawn in front of it. If there was no z buffer the objects would need to be sorted front to back, by distance from the camera each frame. this will be very slow! using a z buffer is much quicker but from different view points there will be different amounts of pixels that are overdrawn (rendered more than once) and thus you can have different frame rates looking at the same textured polygon depending on what stuffs behind it and what order the data is presented in.

[POTS 0]

I doubt it's the hdr causing the slowdown since it's working all the time. It's most likely to do with the z buffer which all games use to make sure stuff that's behind other stuff doesn't get drawn in front of it. If there was no z buffer the objects would need to be sorted front to back, by distance from the camera each frame. this will be very slow! using a z buffer is much quicker but from different view points there will be different amounts of pixels that are overdrawn (rendered more than once) and thus you can have different frame rates looking at the same textured polygon depending on what stuffs behind it and what order the data is presented in.

But is losing 15 fps normal? Like I said, 1-5 fps I wouldn't care to much, but 15?

[Törni 0]

Changing my graphics card from 9600gt to 260gtx did wonders for me. With the older card the game was suffering from slow downs. With the new card I get 100+ frames by looking into sky. You can just forget about running the game in high resolutions with mid range cards.