Contents |
|
The Particle Manager
Now that we have
covered the technology behind an individual particle system, it's time to
create a manager class to control all of our various particle systems. A
manager class is in charge of creating, releasing, updating, and rendering
all of the systems. As such, one of the attributes in the manager class
must be an array of pointers to particle systems. I strongly recommend
that you build or use an array template, because this makes life easier.
The people who will work with the particle systems you create want
to add particle systems easily. They also don't want to keep track of all
the systems to see if all of the particles died so they can release them
from memory. That's what the manager class is for. The manager will
automatically update and render systems when needed, and remove dead
systems.
When using sporadic systems (systems which die after a
given time), it's useful to have a function that checks whether a system
has been removed yet (for example, if it still exists within the particle
manager). Imagine you create a system and store the pointer to this
particle system. You access the particle system every frame by using its
pointer. What happens if the system dies just before you use the pointer?
Crash. That's why we need to have a function which checks if the system is
still alive or has already been deleted by the particle manager. A list of
functions needed inside the particle manager class is shown in Table 3.
Table 3.
Particle manager class functions | |
Init | Initializes the particle manager. |
AddSystem | Adds a specified particle system to the manager. |
RemoveSystem | Removes a specified particle system. |
Update | Updates all active particles systems and removes all system which died after the update. |
Render | Renders all active and visible systems. |
Shutdown | Shuts down the manager (removes all allocated systems). |
DoesExist | Checks whether a given particle system will exists in the particle manager (if it has not been removed yet). |
![]() |
This was constructed
from sparks and a big real-time calculated flare explosion (not just
a texture). |
![]() |
This image is
hte same as the above one, but with some extra animated explosions
(animated textures) and shockwaves, which are admittedly very small
and may be difficult to see in this
image. |
The
AddSystem function will probably have just one parameter: the pointer to
the particle system which is of the type of our particle system base
class. This allows you to add a smoke or fire system easily depending on
your needs. Here is an example of how I add a new particle system in my
engine:
gParticleMgr->AddSystem( new
Smoke(nr
SmokeParticles, position, ...) );
During the world
update function, I call the particleMgr->Update() function, which
automatically updates all of the systems and releases the dead ones. The
Render function then renders all visible particle systems.
Since we
don't want to keep track of all particles across all of our systems every
frame to see whether all particles have died (so the system can be
removed), we'll use the Update function instead. If this function returns
TRUE, it means that the system is still alive; otherwise it is dead and
ready to be removed. The Update function of the particle manager is shown
in Listing
2.
In my own particle system, all particles with the same
textures and blend modes assigned to them will be rendered consecutively,
minimizing the number of texture switches and uploads. Thus, if there are
ten smoke systems visible on screen, only one texture switch and state
change will be performed.
![]() |
This electricity has
its own render function. A hierarchy tree was constructed to
represent the electricity flow using branches and sub-branches. It
is a thunderstorm lightning effect with the branches animated.
Particle shapes are being constructed for every part in the
electricity tree. |
![]() |
A rain effect,
using stretched shapes for the particles. The rain also splats on
the ground by calling the sparks system with adjusted settings and
texture. |
Design, Then Code
Designing a flexible,
fast, and extensible advanced particle system is not difficult, provided
you take time to consider how you will use it within your game, and you
carefully design your system architecture accordingly. Because the system
I discussed uses classes with inheritance, you can also put the individual
particle system types into .DLL files. This opens up the possibility of
creating some sort of plug-in system, which might be of interest to some
game developers.
You can also download the source code of my
particle system, which I have created for Oxygen3D, my latest engine. This
source is not a stand-alone compilable system, but it should help you if
you run into any troubles. If you still have any questions or remarks,
don't hesitate to send me an e-mail.
Discuss this article in Gamasutra's discussion forums