I thought all went well, every class is encapsulated, a pretty perfect design, clear idea on how the classes interact, drawn out each class, their methods and attributes etc... then, somehow you manage to make a P4 lag playing a cut-short version of R-Type (ROFL). I think my problem lies at how I manage my particles. I have a about 100 particles popping everytime the ship explodes. The problem is I made each particle an object with attributes, which I thought was a good idea because then I can manage how each of them interact with the environment. I'm kinda stuck to the mentality that my approach is correct (hitting the big brick wall), any ideas how to go around this problem? thanks for your help in advance.

What do the particles do? Do they just burst and then fade out or do they interact with things? You said they interact with the enviroment...are they colliding with things? Also how many particles are there at once?

Also whats this written in? ie is it windows GDI or what?

I found that with particles you get a HUGE slowdown if you're creating a new particle each time you need one, then deleting it when done. Instead of this, look into a pooling system which preallocates a chunk of particles in advance, lets you obtain one via an Alloc() method and return to the pool with a Free() method. You could probably use a std::vector for this, provided you presize it ready.

Also for particles, make them as dumb as possible so that as little calculation is needed when you update them. If you need to do a bunch of complex math per particle on each update, your game will grind to a halt. You might also want to revise your rendering method for the particles; ensure that you're only trying to draw what's on screen (the same might also apply to updating - only create/update what you can see plus a 'buffer' area). Look into pointsprites instead of quads or triangles and finally, even look into some of the cool new GPU-only rendering and update methods for particles.

This sounds like a good task for boost::pool.

I agree with Revolutional.
But it seems to me that std::list is faster than std::vector because with std::vector you address each element of the list whereas with std::list it's the whole list.

If the STL is too slow Takaloy you should consider of designing your own linked-list mechanisms :-)

it's a pretty simple particle, just some calculation to determine the speed, and direction of the particle, then it has a life-span in which it will respawn etc.. and a boolean counter to show if it's active.

I'm using c# & openGL.

The problem is each particle is an object, while I've never literally create/destroy, I simply 'hide' the particles.

So I have 10 monster ships, waiting to explode -> this is where it lags for 2-3 seconds. each of the monster ships store 100 particles of explosive.

even if I collect them into the pool, it doesn't reduce the amount of 'objects' I display on the GUI.

Each particle being an object is going to slow down performance. This is how I started out with my simple particle test program, and then switched to use a manager class and particle system class. The system class used (hate to admit it) my own linked list class to manage a fixed set of particles, but I am re-writing to use std::deque(in my defense I did tune my linked list to be almost as fast as std::list - I found std::deque to be the fastest though). It does what Evolutional recommends and preallocates the particles and I simple use a bool to control whether the system is active or not. Changing the model gave me a 3x increase in frame rate. Whilst frame rate is not a true measure of the performance, a three fold increase was certainly an indicator of something getting better :-) I would recommend you redesign it.

I used this artcile by John van der Burg as a guide to designing my particle system.

hth
F451

edit: this is only to emphasise the performance gains I saw when switching to std:: containers over homegrown routines. The bigger gain you should get is from switching off having each particle an object and using a container of particles in a system class.

here were my debug timings for allocating and deallocating 500 particles from that test program

Linked List test : 500 items-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-defining my ps3 class object (STL deque)setting up objects for ps3class list  setup3 took 0.0293895 CPU secondsdestroying nodes and list  delete3 took 0.0318766 CPU seconds. Total CPU time = 0.0612662defining my ps class object (STL list)setting up objects for psclass list  setup1 took 0.0882187 CPU secondsdestroying nodes and list  delete1 took 0.109705 CPU seconds. Total CPU time = 0.197924defining my ps class 2 object (Home Brew)setting up objects for psclass2 list  setup2 took 0.088168 CPU secondsdestroying nodes and list  delete2 took 0.100711 CPU seconds. Total CPU time = 0.188879

[Edited by - Fahrenheit451 on January 19, 2006 11:34:55 AM]

You can use the erase-remove idiom to sweep out all "dead" particles from the list in one pass. With a vector, this should work quite efficiently because the vector's reserved capacity will not be altered by this process (if you know the max number of particles, you could just use an array, but there really isn't a benefit there).

Beyond that, I'd have to see some code to help. (You're not by any chance doing any *logging* of the particle births/deaths? That would be horrendously slow.)