Performance debugging

My game I’m writing currently gets around 21-25 FPS in a basic world (20x20 tiles, using RigidBodyCombiner), with no units or structures yet loaded.

I used PStats.
The “Flip” portion of “Wait” takes up a lot of time (about 5 times more than anything else).

The “Begin” section of Flip takes up about 90-95% of this time. Is there anything I can do to minimize this?

(Running a dual monitor setup for the first time, is that related to this?)
[size=75]
Edited to rephrase my explanation.[/size]

I have a similar issue, I too would like to know the answer. I use 6 textures on my terrain, reducing that number helped reduce the begin flip time.

The only reason dual monitors will hinder performance would be if the panda window was larger than before (ie, fills both monitors).

Ah, ok.

I only use 1 texture per tile (3 texture types), barring a few instances of 2 textures per tile for roads.

Here’s a pic:

“flip” is the time spent waiting for your graphics card to finish drawing. There are three reasons it might be big: (a) you still have sync-video enabled (it is enabled by default), so your graphics card is waiting for the next vertical retrace, or (b) you have too much pixel-fill in your scene, or © there is something about your graphics driver that takes a long time to paint the window.

If (b) is the case, then reducing the number of textures on your geometry, or the complexity of your shaders, will help. Reducing the depth complexity of your scene (the number of pixels occluded behind other polygons) can also help. On some older cards, avoiding using shaders altogether will help a lot. Also, reducing the size of the window will help.

© can be the case in a dual-monitor setup. There is one “primary” monitor and one “secondary” monitor. In some cases, rendering to a window on the “secondary” monitor is much slower than rendering to one on the “primary” monitor, because of the way the driver works internally. You can try moving your window back and forth between the monitors to see if that makes a difference.

David

Oh good to know! Being a city builder there is a lot of time looking down ont he terrain, so there is a lot of pixel fill!

Hmm, it would probably be (b). I’m still running the application on my primary monitor, and my V-Sync rate is somewhere in the 60 FPS range I thought… I’ll give that a try though.

I wonder if adding very close fog and culling distance would help with the pixel problem at all?

Bringing the far plane in might help, if lots of geometry ends up being clipped behind it. Bringing fog in by itself won’t help, unless you also bring in the far plane when you do so.

David

Yes, that is what I meant. The fog is just to sort of hide the fact that the far plane is close by.

I’ll attempt that here shortly.

I was going to say that your problem is tiles. Because using lots of tiles without combining them into a single geom is bad because it wastes draw batches. But it looks like you already using rigid body combiner - but maybe its not working because you are using many textures? What is your geom count in pstats? If you get more then 300 geoms then thats your problem.

I think pixel fill will be great on top down game. Pixel fill is how many pixels are “stacked” or “appear behind each other”. In SimCity like game all you see is buildings and ground 2-3 pixel fill max. You would get much more in a hallway shooter where there could be tons of rooms behind the wall.

Pixel fill is really bad with many transparent layers like trees or explosions.

Hmm, only hitting about 27 geoms it says. (With far plane + fog at a distance of 100)

There are no transparent layers as far as I know.