Game Design, Programming and running a one-man games business…

Performance stats for GSB

cliffski

In drawing a typical frame of a biggish battle, the following time is used up:

47% Drawing the ships and their attached particle stuff and effects

12.7% Drawing the debris, and updating debris that is not on-screen

8.3% Drawing missiles and associated effects (it was a missile-heavy fleet, to be fair)

7% Drawing drifting hulks of destroyed ships, and their attached emitters

5.9% Processing gameplay stuff for ships, including target-selection AI

4.3% Post-processing shader stuff

3.18% Drawing the backdrop map.

2.49% Drawing GUI

It seems clear to me that the background map and the missile stuff is slower than it should be, so time to do some digging and stroking of chin, and some speedups…

The tricky thing with all this is making sure that you minimize the amount of work a video card will do, ebcause some people cards may be less capable than mine (GeForce 8800 GTS), but at the same time I don’t want to ‘over-batch’ things, because ideally there is some concurrency betweent he CPU and the GPU. (In other words, the GPU is given things to do while the CPU gets on with non-graphcis stuff, as opposed to the two chips basically taking turns.

There are tools to examine all this stuff, like PerfHUD and Pix. They can be very very complicated to wade through though. I’ll try and gather up some more interesting stats one xactly how its all looking from a performance POV.

6 thoughts on Performance stats for GSB

  1. Just make sure you get it to work perfectly with embedded Intel video chipsets. (I’m joking, I’m joking!)

  2. Keep up the good work!
    Although my Rig won’t have a problem running the game it’s always good to optimise.

  4. Yay! I’ve got an 8800 GTS too, so it’s almost as if youre optimising it personally for my system! How very considerate of you.

    Out of interest, what percentage of the ship drawing time is plonking down the large hull bitmaps and what percentage is doing the extra fiddly bits? Seems to me that a bit of optimisation here (47% of the work) is worth much more than a similar level of optimisation on drawing the backdrop (3% of the work). But then if you suspect something is taking longer than it should it makes sense to investigate there first i guess.

  5. its deceptive because a huge chunk of that 47% is the engine trails, the flashing lights, the explosion particle effects and the layers of damage texture. The actual blapping of a big single quad for the ship itself is very quick.

    As it goes, the speedups are done for this bit, and were not too hard to find. The map drawing was mainly the star field, and some insanely bad code where each star had a rotation, and thus some cos/sin stuff was being called, which is clearly overkill :D
    I also replaced my particle and debris cos() and sin() with table lookups which proved much faster, and I got another speed-up by optimising out a sqrt() call in the physics applied to debris particles. Its pretty rare to actually NEED sqrt, as opposed to just working with squared number instead.

  6. Pingback: NightFlyer Games » Positech Games does not release Gratuitous Space Battles

Comments are currently closed.