• 10
• 12
• 12
• 14
• 18

# When you know your program is horrible. LOL

This topic is 4476 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites
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?

##### Share on other sites
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.

##### Share on other sites
This sounds like a good task for boost::pool.

##### Share on other sites
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 :-)

##### Share on other sites
Quote:
 Original post by HolyGrailI 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 :-)

that doesnt sound right

the STL list will probably be much faster than a hand made one, not to mention less bug-riddled. i'd also guess that it certainly won't be any slower.

a vector should do fine, because this sentence
Quote:
 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.

is meaningless to me.

##### Share on other sites
A vector is faster than a list, because std::vector has an accessing time of O(1), where list has an average accessing time of O(N).

Std::vector becomes very slow if you constantly exceed the allocated amount(std::vector is nothing but a dynamic array that's resized when it's too small), but with a proper setup, that shouldn't happen.

When it comes to deleting, list and vector should have similar performance. List will have O(N) jumps to find the item where vector will have O(N) movements after deleting an item.

Toolmaker

##### Share on other sites
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.

##### Share on other sites
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]