Categories
Uncategorized

How I got from 24 FPS to 264 FPS

I brought the FPS from 24 to 264 today. My optimizations started this morning when I bought DevPartner Studio and ran the performance analysis tool. Honestly, I’m not sure why people waste time writing their own versions in games because the cost is like a weeks’ salary and is 100X better than what you could […]

I brought the FPS from 24 to 264 today. My optimizations started this morning when I bought DevPartner Studio and ran the performance analysis tool. Honestly, I’m not sure why people waste time writing their own versions in games because the cost is like a weeks’ salary and is 100X better than what you could write yourself. It’s not cheap, but I actually got something useful for my money whereas with 90% of the people I hire I get nothing for the same price.

Anyway, the performance analysis tool pointed out some serious problems.

1. The keymapper, as per my prior post, was taking 28% of the total CPU
2. Per-tick Script calls were wasting 10%. I refactored them to support single calls on the first tick, which is usually what I use them for.
3. CEGUI does not optimize out duplicate calls to setAlpha or setting the image property. I was doing that per-tick assuming it would ignore unneeded updates. That got me another 5% or so.
4. A few other minor tweaks here and there.

Then on my own, I turned off exception handling. Doing this generated about 6000 warnings because Ogre and CEGUI both use exceptions. Bad design decision on their part, but whatever.

Also, all my shaders are customized for the specific situations they used in. You don’t get this at most game companies but since I’m doing both the programming and half the art too I have the opportunity for that. They are optimized down to individual lines of code present or not present for the situation. The reason I’m doing this is that my models and textures are super detailed, yet the ships are far away on the screen. So in order to really see what is going on you have to be able to run at very high resolution. This means the pixel shader has to be super fast, and if the vertex shader is also fast then so much the better. Also, as I’m setting up all the materials for the level I can pick intelligently so there’s no waste.

I have another 25% or so boost coming in the next few days. Once the server and client are split that’s one thread and a duplicate copy of the game code out.

6 replies on “How I got from 24 FPS to 264 FPS”

Game is looking good! I’m flipping through different graphics engines right now and can you tell me why you chose Ogre3d in the end over Irrlicht? Better exporters?

Correct me if I am wrong, but dev partner studio is not an interactive profiler, but instead you run a program through it and after that it generates graphs, shows you statistics, etc. Well, people rarely reimplement THIS.

Also, 24 fps to 264 fps is more than 10x increase – 28% + 10% + 5% is nowhere near 1000% – you forgot to write something 😉

Btw, my first post here, but I read your blog for a long time – it’s quite interesting and inspiring, keep it up!

Irrlicht is also good but Ogre has great support.

Dev Partner Studio is not truly interactive but in the current version you can clear the sampled data and continue sampling. So it’s good enough.

I didn’t profile exception handling in particular. However, I read an article from the developers of Halo 2 that said this gave them a 5% overall performance boost.

Non-interactive profilers (and I agree with Zeux – nobody re-implements these) are fine for most CPU/GPU profiling but sometimes you need to find that interactive spike that occurs when an model / textures blows the framerate from 60 to 20fps.

PIX is amazing for GPU profiling. Haven’t found the OpenGL profilers as useful.

Yeah toss exception handling + RTTI. Changing the floating precision + exception settings might have an effect. NaNs / INF / etc. can be expensive for CPUs to process

Leave a Reply to Nelson Cancel reply

Your email address will not be published. Required fields are marked *