Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Petru Soroaga, posted on October 24, 2001

Image Description, by Petru Soroaga

I just finished writing a new particle system. I just wnat to know what you guys think about it's design. The concept is as follows: There is a component that handles creation and destruction of individual particles using some heaps of used and unused particles to avoid new and delete opertators to be called to often. Then there are some components called emitters that emits particles in different ways: point emitters, box emitters, etc. Then to handle particle updates, there is an interface that can overritten and that is called by the first component for each active particle active in the system. The interface for update gets an pointer to the particle and a time slice. This way you can write what updaters you need.

The demo can be downloaded from
It requires DX8, but the concept can be ported to OGL also. Thanks,

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

October 24, 2001, 01:26 PM

Snow, I like snow

Nai Tandu

October 24, 2001, 01:29 PM

Nice! I like your snow (or is it rain?) particle-effect.

System-Design sounds like "Building an Advanced Particle System"
by John van der Burg, publiched in the game developers magazine.

cya all, nai tandu

William Dahlberg

October 24, 2001, 01:30 PM

Particle systems are neat!
Are you going to use this in an upcoming game?


October 24, 2001, 01:31 PM

Linxorz arez fuxx0rz


October 24, 2001, 01:33 PM

Really good work !
The image is soft and pretty neat :)
I'm going to download the demo, i'll make you know how it runs on my PC.
Btw, i'm trying to do something similar, here you can find some informations.



October 24, 2001, 01:41 PM

Very pretty. Although the snow could use another texture for the particles instead of the plane old circle. ;P You design sounds pretty good as well.


October 24, 2001, 01:42 PM

DOH, plane should've been plain of course. Sigh, when is edit post coming? ;)

Kurt Miller

October 24, 2001, 01:46 PM

">>Sigh, when is edit post coming? ;)"


Kurt Miller

October 24, 2001, 01:47 PM

Oops, I meant "Never!" Damn forums need editing capabilities.


October 24, 2001, 01:48 PM

Hmm, sound similar to my project too..
I put more emphasis on being able to write new types of effects quickly as plug-ins. Also the rendering is not hardcoded, so instead of having just points or billboarded textures, you can have 3DS models and iso-surfaces for instance.

Do you have collision detection/response? I would like to know how your performance is. My project is pure OGL, I can render ~5000 particles with collision detection on without a frame rate hit.
I have not optimised my code at all though, and I fell into the C++ operator overloading trap.
all my additions etc are in the form

Vector3D add(Vector3D& src1, Vector3D& src1);

where I would have gained a lot using

void addVector(Vector3D& src1, Vector3D& src1, Vector3D& dst);


October 24, 2001, 01:50 PM



October 24, 2001, 02:09 PM

void addVector(Vector3D& src1, Vector3D& src1, Vector3D& dst);

Is that equilivent to

dst = src1 + src1;

but requires no extra temprorary copy for the addition of src1 and src1?


October 24, 2001, 02:44 PM



October 24, 2001, 02:44 PM

Very pretty, esp. the snow!

Spooyk, coz I have just put together my first-attempt framework classes for particle systems, today!


October 24, 2001, 03:00 PM


The link isn't working !!! Could you give us an updated link ! Please :)



October 24, 2001, 03:15 PM

I am about to write a particle system for a game that i am currently writing. You gave me an idea when you said it was bad to constantly be creating & removing particles. I assume you meant allocating or freeing memory when the *particles die. But how do you decide which particles are unused without checking them all untill you find one.

Alex Herz

October 24, 2001, 03:29 PM

it looks pretty nice!
but is the thingy software rendered?
if not and if you are using any 3d accelerator you should think bout the design again..
cause 5k tris pers sek is not acceptable.



October 24, 2001, 03:35 PM

I just noticed that has a trafic limitation about 1 MB / hour. Aslo, it doesn't support resume on downloads. So, i have just updated the links to some other free servers. You can check again on and get the zip file again.


October 24, 2001, 03:47 PM

I think the snow, while it's falling, looks amazing. It looks a little weird on the ground (it glows heh) but it looks really cool when it's in the air. Good job!



October 24, 2001, 03:56 PM

Are you stupid or something?


October 24, 2001, 03:59 PM

Sorry about that, but free servers??


October 24, 2001, 03:59 PM rocks as a free web host! Despite the (a bit) annoying popup/advertisement on each of your pages and sub-pages. It has no file size limit to single files (however the maximum size of your folder is around 50MB or so) or traffic limit and their servers are pretty fast (most of the time). I am in hurry now, so sorry for typos or grammatical mistakes!


October 24, 2001, 04:08 PM

Yeah, the creation of the temp variable to add the values kills my performance...


October 24, 2001, 04:17 PM

You could stick with user friendly overloading but only supply overloaded +=, -=, *= etc. member functions. This way you're forced to consider what you're doing (no temporary variables are hidden from you). I suppose you could make a simple vector class that only has these simple member functions, and derive a more sophisticated class that includes the less efficient functions. You could then limit your 'inner loop' functions to using the first class.


October 24, 2001, 04:31 PM

Actually a large part of the problem with your link Petru is geocities is mispelled, you have citities. I like the look and concept, any cahnce of a better description of the way you recycle your particles?

Hiro Protagonist

October 24, 2001, 04:51 PM

Well, you assign each particle a life span and a flag to say whether it is alive or dead. When the given lifespan of a particle is up, release your reference to it and throw it back in the pool.
The idea behind using a heap or pool is not to avoid checking each particle, but to avoid the operational overhead of creating and destroying those objects.


October 24, 2001, 05:02 PM

I feel like I am being laughed at :(.

I vastly prefer the look of the overloaded operators... but I don't know how much performance gain you get by getting rid of the constructor call. I rewrote a vector class for a N-particle gravity sim I wrote, first with all the methods looking like this, the "exremely slow" way

vector3 vector3::operator + (const vector3& rhs) {
vector3 sum;
sum.x = x + rhs.x;
sum.y = y + rhs.y;
sum.z = z + rhs.z;
return sum;

After changing the code (and all other similair functions) to
vector3 vector3::operator + (const vector3& rhs) {
return vector3(x + rhs.x, y + rhs.y, z + rhs.z);

I got a neglible performance increase, which leads me to believe that getting rid of the constructor call is really insignificant.


October 24, 2001, 05:04 PM

Your project seem nice, do you plan adding "mesh" particle?.. I mean the ability to spwan a whole lot of "rocks" and stuff. Maybe look for vertex programs also, maybe you can do this entirely in hardware...

Alex Hertz: Actually it's more like 10k tri, because you need 2 triangle for one particle, except if they are triangular, but this will suck...well unless you can fit your texture in the triangle...


October 24, 2001, 05:18 PM

The thing that's "extremely slow" is the return type, not the way the method is implemented. I would expect any decent optimizing compiler to produce the same speedy code for the body of both methods... But since you're returning a vector3, it forces the creation of a temporary object each time you add two vectors together. Consider this:

// method one
vector3 a, b, c, d;
a = b + c + d;

// method two
vector3 a, b, c, d;
a = b;
a += c;
a += d;

In the first method, (c+d) would be evaluated and stored in a temporary vector3. Then (a+temp) would be evaluated and stored in another temporary vector3 (perhaps the same one of the compiler is smart about it). Finally, the assignment to a from temp2 would occur.

In the second method, no temporary vector3 objects are needed.


October 24, 2001, 05:41 PM

Two words... PopUp Killer

This thread contains 73 messages.
First Previous ( To view more messages, select a page: 0 1 2 ... out of 2) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.