Using Arrays instead of Lists
=============================
Currently my particles are added to a list and the list is iterated through to draw them, and when they fade away of go off-screen they are destroyed (removed from the list so the GC can clean them up).
Sounds fine and is easy to manage, but people have said before that I should be using a particle pool i.e. a pre-made array. I presume this is for two reasons:
1) Iterating through an array is quicker than a list because you simply access the next slow instead of having to read list links which is slower due to the extra steps. I assume this would make more difference if there were a large number of particles.
Problems I see with this: If I create 1000 particles which disappear at different times, when I get to say 100 particles left, my list will iterate nice and quickly but with an array I'd still have to loop 1000 times and check each slot to see if the particle is still "active" - that could be slower than the list iteration! I could shuffle up the particles when one was deleted but that would be really slow and impractical I'm sure.
2) The TParticle objects can be pre-made and associated with each array slot so that instead of having to create a new TParticle object to add to a list (slow due to mem allocation), you simply set (overwrite) the parameters of the existing TParticle at the current array slot and make it "active".
Problems I see with this: If my Particle type has many different fields that do different things I couldn't just set the few fields that I'm using this time, I'd need to clear all the fields to default values and then set the values that I wanted to actually use. This could be slow.
So am I missing something more obvious about why particle pooling in an array is better than using a TList? Perhaps even with the problems I've listed above, using an array is still quicker?
"Normal" Flag?
==============
On a related topic, my Logic() and Draw() methods for TParticle are quite complex due to all the different things the particles can do (lots of If statements). Perhaps I could optimise these by having a "normal" flag which when =1 I just draw a particle nice and simply and bypass all the If statements? At the moment the normal particle is drawn last after a ton of If statements which slows down the majority of particles.
Polymorphism
============
Of course it would probably be better OOP to have different particle classes starting with a really basic one and going up to more advanced ones and then I can use polymorphism so that when iterating through the list (or array) or particles, Logic() and Draw() are called for the correct particle class. This would keep the simple particles fast.
However, what if I have say particle type B which handles scaling and particle type C which handles rotation. How can I make a particle type D which handles both without some blatant copy/pasting from B and C (because the scaling and rotation code is not in the base class A)? Is this what multiple-inheritism is for?
If anyone has any insights, I'd be very glad to discuss them. Thanks!
=============================
Currently my particles are added to a list and the list is iterated through to draw them, and when they fade away of go off-screen they are destroyed (removed from the list so the GC can clean them up).
Sounds fine and is easy to manage, but people have said before that I should be using a particle pool i.e. a pre-made array. I presume this is for two reasons:
1) Iterating through an array is quicker than a list because you simply access the next slow instead of having to read list links which is slower due to the extra steps. I assume this would make more difference if there were a large number of particles.
Problems I see with this: If I create 1000 particles which disappear at different times, when I get to say 100 particles left, my list will iterate nice and quickly but with an array I'd still have to loop 1000 times and check each slot to see if the particle is still "active" - that could be slower than the list iteration! I could shuffle up the particles when one was deleted but that would be really slow and impractical I'm sure.
2) The TParticle objects can be pre-made and associated with each array slot so that instead of having to create a new TParticle object to add to a list (slow due to mem allocation), you simply set (overwrite) the parameters of the existing TParticle at the current array slot and make it "active".
Problems I see with this: If my Particle type has many different fields that do different things I couldn't just set the few fields that I'm using this time, I'd need to clear all the fields to default values and then set the values that I wanted to actually use. This could be slow.
So am I missing something more obvious about why particle pooling in an array is better than using a TList? Perhaps even with the problems I've listed above, using an array is still quicker?
"Normal" Flag?
==============
On a related topic, my Logic() and Draw() methods for TParticle are quite complex due to all the different things the particles can do (lots of If statements). Perhaps I could optimise these by having a "normal" flag which when =1 I just draw a particle nice and simply and bypass all the If statements? At the moment the normal particle is drawn last after a ton of If statements which slows down the majority of particles.
Polymorphism
============
Of course it would probably be better OOP to have different particle classes starting with a really basic one and going up to more advanced ones and then I can use polymorphism so that when iterating through the list (or array) or particles, Logic() and Draw() are called for the correct particle class. This would keep the simple particles fast.
However, what if I have say particle type B which handles scaling and particle type C which handles rotation. How can I make a particle type D which handles both without some blatant copy/pasting from B and C (because the scaling and rotation code is not in the base class A)? Is this what multiple-inheritism is for?
If anyone has any insights, I'd be very glad to discuss them. Thanks!