Improved Particle System for Starling

So finally here it is, the updated particle system for Starling, kindly sponsored by Colin Northway (Incredipede). It’s based on and compatible to the original.

Improved Particle System for Starling

For his upcoming game Deep Under the Sky Colin needed some additions to the previous version, especially batching of particles from the same atlas, animated textures, a particle pool, and support for unique filters. Additionally some things came up on the way.

Feature Overview:

  • particle pool
  • batching (less draw calls)
  • multi buffering (avoid stalling)
  • animated particles
  • random start frames
  • (ATF support)
  • filter support
  • optional custom sorting, code and variables
  • calculating bounds (optional)
  • spawnTime, fadeIn/fadeOut
  • emit angle alligned particle rotation
  • various performance improvements
  • some ease-of-use stuff



Reduce of function calls

I have done a lot to make the code as fast as possible. Especially function calls have been drastically reduced.

  • removed Math.sin()/cos() in favor of extremely great performing lookUp tables as described by Benjamin Guihaire
  • Math.random() has been replaced by a fast pseudo random number generator
  • no use of modulo operator
  • writing the VertexData directly to rawData
  • added [inline] to functions so you’ll have to use ASC 2.0 to compile your project and set the inline property, to get best performance


I added a modified version of the QuadBatch class to the code. So each particle system can be batched with each other. The rules of batching are basically the same.

Particle pooling

By calling the static init() function on the particle system you’ll create a particle pool and vertex buffers at once. This avoids frame drops formerly caused by instantiation and garbage collection. Furthermore start up time has been improved by parsing and storing the xml file data within a new class called SystemOptions beforehand. The SystemOptions can be reused, cloned and modified as you like.

Multi buffering

VertexData is uploaded to a static Vector of buffers. This can help to avoid stalling of the GPU caused by the rendering time. As already mentioned the size and number of vertex buffers is set once at start up by calling the particle system’s static init() function.

New features

Animated particles

If you provide the system with an texture atlas xml, the particle can set it’s subtexture according to it’s current age. The properties for this feature are firstFrame, lastFrame and the number of loops.

ATF support

That’s it. Now you can use ATF Textures. Hooray.
Edit: for about 2 years already … nevermind (^_^°)

Emit angle aligned particles

You are now able to chose whether the emit angle has influence on the particles rotation, like the lasers in the demo are, or not, like the UFOs.

Custom & sorting functions

If you need some extra processing for your particles you can do that by setting the customFunction property. The function will be called after calculating the standard properties and before (sorting,) writing to the vertexData.

The customFunction will recieve the complete Vector.<Particle> which you can loop over to do your own stuff. The second parameter is the number of active particles. To process extra properties you can use the customVariables of the Particle class. In the demo this is used for the UFOs. Furthermore this function will be necessary to achieve correct sorting.

Sorting is also an optional function that can be set if you need to. I used this for the smoke screen between the two buildings on the left. Otherwise the particles would jump sometimes and show a rather weird behavior, which can be experienced if you look closely to the burning car. While it is no problem for the fast moving fire it’s necessary to sort the slowly moving smoke whenever particles are added or removed. The second system I used this feature are the Starling birds, which are sorted according to their size.

filter support

The previous particle system couldn’t be used with FragmentFilters. That’s simply because the bounds were always 0. This version will report stage dimensions, or optionally the exact calculated bounds. However even though filters on screen size are expensive, the exact calculation is ment to enable clipping and not to be used with filters, since this would lead to regular texture allocations!

Exact bounds

Optionally you can get the correct bounds of the particle system. Actually this might be just overhead in most situations, especially if you’re batching systems. I don’t know. Let it disabled if you don’t need it.

Additional transition values

With this version come three new values to modify particles. spawnTime scales new born particles from zero to their actual size. fadeIn and fadeOut modify the alpha value at birth/death. All three values describe the timespan of the transition according to the particle lifespan as Number between 0 and 1.

Ease of use

Thanks to automaticJugglerManagement you don’t have to add and remove the system to the juggler manually. It’s activated by default but you can disable it for compatibility.

The blendmodes can be set within the pex file as String to make them better readable.

Live Demo

Well the demo sucks … a little … on purpose. But back to that later.

Start Demo

Layers and Commands:

This demo shows about 14 systems in the following order. You can check out how the systems get batched by disposing/recreating them.

Press the following keys to pause/resume the particle systems;
+ shift to dispose or reinitiate them;
+shift + ctrl to advance time.

Space = all

(— blend mode change —)
Q = left building (100)
W= smoke screen (100, custom sorting)
— blend mode change —
E = jets (5)
R = UFOs (8, custom function)
— blend mode change —
T = UFOs burning fx (100, only one reused system)
Y/Z = right building (100)
U = starling birds (500, animated — different texture! —)
I = burning car (100)
— blend mode change —
O = ash, far (1000)
P = ash, close (100)
— blend mode change —
A = sparks, burning car (200)
S = laser chaos (20)
D = dust (10)
(UFO hits, various systems)

What sucks? The demo starts up in 1:1 scale; system start one second delayed. Check it out in Adobe Scout, I get a AS execution time of about 2 ms. Nonetheless if you scale up the window you may see a massive performance drop caused by the rendering time. Especially the dust with all the alpha blending has serious impact due to it’s size, even though it’s only using 10 particles.


Quick Start:

So that’s it in a nutshell.

Have fun. Leave a comment. :)
… in the Starling forum, twitter, g+ or where ever ;)

2 Gedanken zu „Improved Particle System for Starling

  1. Pingback: Improved Particle System for Starling | Adobe F...

  2. Pingback: Improved Particle System for Starling | Flex Mo...

Kommentare sind geschlossen.