Stardust project homepage
As a quick notice, Paq has joined the Stardust development team. He'll be working on plugins for Alternativa3D and Away3D, and Japanese localization. Horray!!
I'm currently working on the most important new features of Stardust 1.3, switching from renderers to particle handlers.
Previously, the particle data in Stardust are read and visually presented by the
Renderer class, whose
render methods take in
ParticleCollection objects as parameters, and traverse them to retrieve particle data, resulting in almost twice the processing overhead for particle traversal.
I've found this extra traversal effort quite unnecessary. Since a complete traversal of the internal particle collection of each emitter is already done in each emitter step, so why not "embed" the rendering process into the emitter step? This is how I came up with the idea for particle handlers.
The skeleton of the
ParticleHandler class looks like this:
stepBegin method is invoked at the beginning of each emitter step.
stepEnd method is invoked at the end of each emitter step.
particlesAdded method is invoked when a new particle is added to the emitter.
particlesRemoved method is invoked when a dead particle is removed from the emitter.
readParticle method is invoked when a particle is fully updated by all actions.
You may override these methods to create your own handlers. The concept is quite similar to that of the renderers, only that particle handlers do not require extra (and unnecessary) particle collection traversal. Everything is done in one single traversal.
A particle handler is assigned to an emitter through the
Emitter.particleHandler property, which is quite straightforward:
You may find the similarity between the code above and the use of its renderer counterpart:
Not until I finished the
ParticleHandler class did I realize how easy it is to implement a polling station as a particle handler, favoring those developers preferring polling over events.
For your information, a polling station is like a passive database. You access the data only when you need to, which is the opposite to an event system. An event system, as most Flash developers are already familiar with, is an active database, "pushing" data to you whenever there is new data available.
Some framework is designed to better work with polling stations rather than event systems. Thus, I've written a
PollingStation class that works as a polling station, recording all the relevant particles in each emitter step, and exposing an interface for data polling.