Accelerated Particle Effects

Not (yet) a tutorial this time, just the demonstration of a GPU-based particle system and a glimpse at the advantages of hardware acceleration.

The power of being given access to GPU acceleration for graphics isn’t just in getting images to be drawn really fast. If we use vertex shaders to make things move around the world then we can offload a significant amount of per-frame calculations over to the graphics card, which frees up the CPU for more interesting tasks like AI and physics.

As an example of the CPU time saved by using graphics hardware, here is virtually the same program embedded twice. The first version attempts to use your graphics hardware while the second is forced to use the fall-back software implementation. If you’re viewing this on a device that isn’t currently supported by Flash’s hardware acceleration then both versions will be using software rendering. You will of course need Flash Player 11 to see the demo.

Get Adobe Flash player

Get Adobe Flash player

If your results are anything like mine then the difference in performance even with this relatively small scale example will be dramatic. That said I’ve got to take a moment to say how impressed I am by the performance of the software implementation. It multi-threads and spreads itself across my CPU cores beautifully, and most importantly produces output which is so far as I can tell completely identical to that coming out of the graphics hardware version.

Perhaps more interesting than the raw increase in speed is the difference in CPU use. For me the hardware accelerated version’s main loop is measured at taking 0ms, and as you would expect the software version’s is much higher at around 20ms. Not only is the hardware accelerated version pumping out frames faster but it’s barely touching the CPU, which is left free for running the rest of the game.


Writing the shader for these particles was good fun. If stripped of comments the final code is 54 lines (of a maximum 200 allowed) of virtually indecipherable opcodes and registers, but the process it represents is simple enough.

The classic way to handle moving objects in game programming is to adjust their position each update cycle by adding on a value representing their velocity. This technique doesn’t work for objects that are to be handled entirely through AGAL shaders as there is simply no place where their position could be updated by the shader and stored between frames.

Instead the shader needs to be able to produce the particle’s position when provided with the current time. So the process of writing the shader starts with finding an equation in terms of time¬†that gives position¬†(or rotation, colour, scale, or any other property of your particles that you want to have change). If the particles are moving at a constant velocity this is simple enough:

position = startPosition + startVelocity * time

The variables like startPosition and startVelocity will be passed into the shader through the vertex buffer (as they will be different for each particle), while time will be passed in through the shader constants as it is the same for all particles being drawn that frame. If you want the particles to undergo acceleration (such as due to gravity) then you can just add on a new term to account for that.

position = startPosition + startVelocity * time
           + 0.5 * constantAcceleration * time^2

Effects like the particles bouncing once when reaching a certain y-value are a little more complex but it still all comes down to making an equation that gives the position of the particle in terms of time.

Bonus Content!

Not particularly related to particle systems, but I decided to reproduce an old example of normal mapping I made back when Pixel Bender was the closest to hardware acceleration Flash had available. This version is of course running entirely on the GPU.

Get Adobe Flash player

4 comments on “Accelerated Particle Effects

  1. Nice.
    I was wondering, have you seen Christer Kaitila’s ( his blog ) new book?
    I just got it yesterday, and it’s pretty good for someone (like me) who can’t figure this out on their own!

    Especially the AGAL coding… It’s hard for me to figure out…
    I understand how the code works.
    I’m just not used to where values are places, and where to place them.

    I just decided to post this while I was checking your AGAL post. XD

  2. I’ve not seen the actual book, but I have peeked around his blog a few times. Looks like good stuff!

    I posted another theory-heavy tutorial today about dealing with registers, which are pretty central to writing shaders.

    I suspect that what’s most useful are more practical tutorials, but if I try to write those I end up feeling I should explain everything I bring up. I don’t like to leave anything as “Just trust me, you need this magic code for it to work.”

    Hopefully I’ve now got enough AGAL-theory stuff up that I can just link back to it for future posts.

  3. RiaanWest on said:

    Excellent work man! I’m in the midst of my first major stage3D project, and need some help… Any chance I can look at your source code?

  4. I can see how you can use a the GPU to model and render the particle position from the equation -

    position = startPosition + startVelocity * time
    + 0.5 * constantAcceleration * time^2

    It looks like you would use a couple of vector scales and additions prior to applying perspective.

    I’m more interested in your statement alluding to conditional jumps in AGAL -

    “effects like bouncing once when reaching a certain y-value are a little more complex but it still all comes down to making an equation that gives the position of the particle in terms of time.”

    My equations for simulating bounce to a projectile – involve multiplying by e^(-b*time) and sin(a*time) – with no conditions for flooring.
    eg something like 4 * abs( sin( time * 6 /2) * e^(-time * 0.5) will give you some kind of particle bounce effect – without conditions (other than an abs function)

    Can AGAL support or build the exp function?

    I’m itching to see your shader!

    Thanks for the great Blog!


Leave a Reply

Your email address will not be published.

16,852 Spam Comments Blocked so far by Spam Free Wordpress

HTML tags are not allowed.