Confusion

Hi,

I don't really have anything new to show, I've been refactoring a lot of the source code, so even if a lot has changed under the hood, the state of the game itself is pretty much the same. But hopefully, the complex changes I'm working on will make the development easier in the future.

However, something is slowing me down.
What is it?
Well... it's something called confusion!

I tried running the game on my office computer... and it was slow, too slow to be playable!

There is no reason why my office computer shouldn't be able to handle the game. If anything, I was expecting it to be faster than on my home computer.

Let's see a quick comparison of the two machines:

1) Home computer:

• CPU: i5-3570K with 4 cores at 3.8 GHz (no overclocking I know, I know...)
• GPU: GTX 460 (x2 with SLI!)
• RAM: 12 GB

2) Office computer:

• CPU: Xeon W3670 with 6 cores and 12 threads at 3.2 GHz
• GPU1: Quadro 600
• GPU2: Tesla C2070
• RAM: 24 GB

As you can see, the office computer should be able to handle a little game like Castle Defender!

So what is going on?
Well, it seems that the slow down is to blame on the particle system.

At the beginning, the game runs on a decent framerate, but as objects start exploding, scattering cubes all over the place, the framerate drastically falls, rendering the game unplayable.

So I tried to see what was causing the particle system to slow down:

• By displaying particles as points (instead of cubes) I got back to a good framerate. So that must mean that the display of the cubes is what slows down the system, right? But how to optimise the display of lots of cubes, that's something we will have to discuss another time.
• By displaying the cubes as normal, but disabling the part of the code that makes old cubes sink into the ground and disappear, I got back to a good framerate, although that means displaying a lot more cubes than usual! So that must mean that my method to delete old particles (a simple call to std::vector erase) is what slows down the system, right?

I think you see were I'm going, different tests showed me different causes of the slow down.

I wasn't sure how to optimise the display, so instead I chose to focus on the second point. I rewrote my particle system to use a new structure based around a std::vector and a mask, so that particles are not created/deleted dynamically. Instead particles are all created at the beginning of the program, and the mask is used to set them as active/inactive without doing memory allocation/deallocation.

I was quite happy with my new memory structure, but sadly it didn't solve the problem. Instead I ran into new weird behaviour that I still don't fully comprehend. (like the game running fine until the particle buffer is full and than slows down drastically). What's even weirder is that I can't see any of these effects on my home computer.

I now wonder how important memory fragmentation is for an efficient algorithm?

Anyway, I then tried to use profilers like gprof to have a better understanding of where the program is spending its time.
But it just confused me even more!
For instance, it was showing that the program was spending about 50% of its time in the display of the GUI (the players and castle health bars). That seemed strange, so I disabled it in the code to see if it actually had an impact on the performance. But nope, only a minimal impact!

I wonder now how good gprof is at profiling OpenGL applications?

Well... that's all for today!
Basically, I spent a good amount of time trying to optimise stuff, and I ended up with a program still as slow as before! The only difference is that I'm now more confused than I was at the start!

If anyone has any advice, please leave a comment.

Nick.

PS: Oh, and also I spent my weekend trying to compile the game for Windows, but no success, I couldn't even get a window open. What a waste of time! It looks like if people want to play the game, they will have to install linux! At least it's free ;)