Optimising Particles - Pooling etc.

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

Grey Alien

Glad to see this topic has enlivened.

This should never happen. They should have a constant lifetime, and should always be in a regular cycle

At the moment I kill them off from my list when they are invisible but with the array I wouldn't kill them off, just set a flag on them as inactive. Therefore I was saying you'd still have to loop through 1000 but often for a large number of them you'd be checking the active flag and then ignoring them (not updating them). I wondered if that was less efficient than have a list which was smaller due to particles actually being removed from it.

I would imagine. When it comes time to actually draw the beast

Agreed but every little helps especially on slower machines. Yes that particle editor is by Jake L. and he has already kindly given me the optimised drawing code.

I have not really done over 2000 or so particles, but in a casual game do you really use much more than that at any given time

I'm hoping to use quite a few particles. Some effects like fire or magical lines of fire, or magical dust can use a ton of particles and so I want the engine efficient for that.

I'm using lists as well. 2 actually. One for the active particles and one for the pool which has a logic within to reduce the pool size over the time

Interesting idea, so this helps to remove the slow memory allocation for creating and destroying types over and over.

Just by optimizing your calculations and adding/removing if-then-else structures where useful you get a good boost

Agreed. Hence my question about polymorphic particle types which no one seems to have commented on.

@ImaginaryHuman:

One thing you can try is what I call a `auto-defragmenting array`

This is a good idea, it address my issue of having holes in the array. Of course there's a small overhead in filling the holes but then time is saved not looping the whole array and checking for active flags. Yes normally the draw order is not important but I wonder if it would look odd if one particle moved in front of another? It might be OK as what tends to happen is you set off a load which all die at the same time and whilst they are active you probably set off some more somewhere else. Also they are often drawn with light blend so it won't matter too much on overlap.

I would definitely avoid ANY kind of memory allocation or deallocation at any time during the normal running of your game loop with regards to particles

Yeah this is what I'm think I should avoid too.

You'd have several arrays, in parallel, storing one field per array for each object

Yes I realise this would be faster having coded like this in the past, it just seems so Old Skool and inflexible now...It still doesn't solve my issue of different particle types unless I have several different arrays: one for scaling particles, one for rotating ones, one that does both etc. Just seems messy in a non-OOP way. A I see you've suggested "I also recommend you try using function pointers." That's a good idea. I use function pointers for other things (user-defined functions added to a process) so I could use them for this too.

There is a slight overhead to that, where you have to now read through an array in order to call functions

If the array of functions has the same index as the particle arrays then a separate loop is not needed because you already know the index of the current particle that's being processed.

I'm not doing collision detection.

Also ideally you'd want to get your particle data into some format uploaded like vertex arrays so the graphics card can render faster

Yes I don't know much about this at all, just the idea in principle. It's something I'd like to find out more about as speeding up drawing would be great. Perhaps some of Jake L.'s code does this, I'll have to check again...

Thanks for the ideas.

impixi: Wow that's some comprehensive tests, nice one. I'll check them out. Interesting isn't much difference. How much % between the fastest and slowest? I assume that the list-based on with real time creation/deletion is slowest (my current method)

If you are doing particles on the GPU you will want these properties to be in arrays so they can be uploaded

Is there some kind of batch move of memory command for GPUs? So I could upload an array all in one go? Or do you just suggest arrays for quick uploading manually (via a loop) to the GPU?

Great discussion all!