Serious unexplainable Performance Differences - got proof

[soldier9945 12]

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.

What do you get in the third SP mission "Gegenangriff" when you are in the hallway in town where the first savegame occurs? (in FPS).

With these ingame settings:

Every option on "Very High", View Distance: 3600, Fillrate 100% @ 1680x1050, Veteran mode (for AI settings maxed out).

Would interest me, as a friend will buy this card soon :o Thanks!

[DaveG 0]

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

It could well be. There probably be a lot of overdraw anyway due to all the foliage. And you were near the coast when doing the test so one direction may have had not a lot but sea behind it.

[POTS 0]

This is a two dimensional representation of how things should be blocked out. The black area represents objects located on the visualy blocked grid.

Here is how a single wall would block out objects located on the visualy blocked grid.

http://img38.imageshack.us/img38/3103/occlusione.png

Here is how multiple walls block out objects on the visualy blocked grid. Notice how the black areas add up and sometimes create one black area.

http://img193.imageshack.us/img193/8658/blockedview.png

Using a 3d grid could give objects an assigned location in 3d space. And having an algorithm that assigns objects to be blocked because of their location within the blocked area should not be too CPU demanding like some say. Its fairly simple for the CPU to handle.

Now, arma2 already has a 3d grid that handles object location, so there should be no real excuse to not have something like this fully functioning.

[DaveG 0]

Seriously this is what the z-buffer is for! It's pretty much the most efficient way of dong this and is handled in hardware with little input from the programmer.

Doing it the way you suggested would involve computing the distance from the camera to each and every polygon in the scene which needs at least one square root (=very slow) per polygon. Then of course all the polygons (probably 10's of thousands) to be sorted according to this depth and rendered accordingly.

Trust me, BI know what they're doing!

[moosenoodles 0]

Anyone tried forcing the z buffer to 16 or 24 bit? Can do that with certain tools for your card.

[Alex72 1]

It will take objects behind the house in consideration as well. If there is a forest behind the wall looking one way and the sea looking the other way there will be FPS difference.

If thats a coding error i dont know. Dont think so though.

Alex

[DaveG 0]

Anyone tried forcing the z buffer to 16 or 24 bit? Can do that with certain tools for your card.

The might help if there are any z-fighting issues (flickering decals and textures) but it won't help with overdraw.

[Yoma 0]

This is a two dimensional representation of how things should be blocked out. The black area represents objects located on the visualy blocked grid.

Here is how a single wall would block out objects located on the visualy blocked grid.

http://img38.imageshack.us/img38/3103/occlusione.png

Here is how multiple walls block out objects on the visualy blocked grid. Notice how the black areas add up and sometimes create one black area.

http://img193.imageshack.us/img193/8658/blockedview.png

Using a 3d grid could give objects an assigned location in 3d space. And having an algorithm that assigns objects to be blocked because of their location within the blocked area should not be too CPU demanding like some say. Its fairly simple for the CPU to handle.

Now, arma2 already has a 3d grid that handles object location, so there should be no real excuse to not have something like this fully functioning.

I honestly know nothing about 3d engines, but maybe the engine need to precache some stuf so things can get drawn quicker if you shift position/turn around etc. It's not only about actual rendering, it's allso trying to make sure textures are in cache.

It might be a bug though, also i cannot reproduce this behaviour on my system. (q9650+285GTX)

[DaveG 0]

The game most definitely already does this. OFP did it, Arma did it, I'm sure this game does it too.

[householddog 10]

Anyone tried forcing the z buffer to 16 or 24 bit? Can do that with certain tools for your card.

Yeah, as I said before, I tried it. No noticeable difference.

ATI Tray tools does it for ATI cards.

[moosenoodles 0]

Yeah, as I said before, I tried it. No noticeable difference.

ATI Tray tools does it for ATI cards.

Yeah shouldnt I think do much as its an opengl adjustment, but im sure ive read before that you can use it otherwise. Thing is i forced it to 24 earlier and flew around the map in heli's nice and 50>100 fps :D and did not see one shimmering dual loading texture plain on the windows of doors etc etc..

Could be just random luck though, this engine has me in fits at times with its irregularities :D

[householddog 10]

Could be just random luck though, this engine has me in fits at times with its irregularities :D

Its bizarre. I am having an argument in another thread with somebody who thinks Arma2 scales well to hardware.

I really don't see it myself.

[An Fiach 10]

The simple answer could be poly count and the construction of the building. It looks the same but internally it may not be.

[householddog 10]

Yes but then you would expect the fps to change if it were the polys. It pretty well stays exactly the same, when you look at it.

At the very least there should be sweet FA rendering going on.

Obviously the game is culling renders out of your field of view. You need only look up at the sky to see that.

Its simply not using occlusion culling, in a lot of places.

I wonder if it still renders everything on the other side of a hill too?

[An Fiach 10]

Yes but then you would expect the fps to change if it were the polys. It pretty well stays exactly the same, when you look at it.

Why would it change while you are staring at it?

[householddog 10]

Why would it change while you are staring at it?

I mean it should change, either for the better or worse, when you look at it. As opposed to strafing it out of view. If there were more polys, there should be less fps, if there are less poly then more fps. As it is, there is no difference whatsoever, with a lot of buildings/objects.

If its rendering things behind the object that would explain why the FPS would not change.

Its not an entirely conclusive test, I agree, but interesting, non the less.

Edited June 13, 2009 by householddog

[An Fiach 10]

I mean it should change, either for the better or worse, when you look at it. As opposed to strafing it out of view. If there were more polys, there should be less fps, if there are less poly then more fps. As it is, there is no difference whatsoever, with a lot of buildings/objects.

If its rendering things behind the object that would explain why the FPS would not change.

Its not an entirely conclusive test, I agree, but interesting, non the less.

The OP was about one wall showing lower FPS than another, this is why I am confused by your statement.

[Dwarden 1124]

erm most modern drivers support 32bit Z-buffer (or 24+8) ... what was the point lower to 16,24 ?

[householddog 10]

erm most modern drivers support 32bit Z-buffer (or 24+8) ... what was the point lower to 16,24 ?

To test if it would lower my frame rate.

I didn't know it was opengl though. My mistake.

---------- Post added at 01:29 PM ---------- Previous post was at 12:41 PM ----------

Maybe its got something to do with the destructible landscape.

Edited June 14, 2009 by householddog

[Warmoer 1]

Well, not entirely what has been experienced here, but to the same effect. I played the OFP missions ported for ARMA 2, and during the Cleansweep I missions I saw this anomaly for the first time. My two teammates died quickly in the mission, and I sneaked around to get to them to loot them for ammo. The framrates were quite good troughout. I then reached the body of a dead teammate and dragged it out of the road to behind a fence. It is here that my problems started. I did not matter at which point I was in the village after that or how many buildings were between me and his body, once I moved my view so that he is within the limits of my screen (although he is not visible), my framerates would drop to a slideshow.

I tested it extensively and could identify it as the culprit. So after the "drag" command was executed on the body, things went downhill. I tried it deliberately with the second teammate as well, and the same effect. I experienced the same kind of slowdown during the second stock ARMA 2 SP mission (can't remember the name), but the squad of rebels that attacked the town. We killed the BMP (or whatever it was), and for the remainder of the mission, something in that area killed the framerates when my screen was oriented in that direction.

I am only guessing that there might be some effects/scripts that are acting up when you view in the direction of the object that is executing that command - whether they are in plain line of sight or behind a building(s).

[scruffy 21]

...

The problem here is the blood. If the first aid systems are used and a unit linked with them dies they bleed out and leave a growing pool of blood. When you pull them around you make things even worse as you now leave a trail of blood.

[Helmut_AUT 0]

The OP was about one wall showing lower FPS than another, this is why I am confused by your statement.

Not quite correct - my OP was about the difference it makes in FPS what lies behind a wall, when in fact everthing behind it could be culled from rendering - or maybe not, as some people here explained for other reasons.

But my test was not to show that two walls have different FPS - rather to show the engine is rendering stuff you can't see.

[Razorman 10]

The problem here is the blood. If the first aid systems are used and a unit linked with them dies they bleed out and leave a growing pool of blood. When you pull them around you make things even worse as you now leave a trail of blood.

Nice find! Let's hope the devs see this & implement a fix?

[An Fiach 10]

Not quite correct - my OP was about the difference it makes in FPS what lies behind a wall, when in fact everthing behind it could be culled from rendering - or maybe not, as some people here explained for other reasons.

But my test was not to show that two walls have different FPS - rather to show the engine is rendering stuff you can't see.

You are assuming it is what is behind the wall that is causing the difference given your orientation but if this is the case it will not just be that one specific wall where you will see the differences.

EDIT: I am not saying that you are incorrect, just that given the information you stated, a definitive conclusion cannot be drawn.

Edited June 15, 2009 by anfiach

[ECH 10]

Are we there yet?

Can we get reduced background culling when we objects block our view based on field of draw rendering (or whatever they call it)?