Sunday, January 23, 2011

Moving to A New Blog

I’ve registered a new domain, and I've moved to a new blog.
Future posts will be posted there.

Friday, January 7, 2011

Stardust 1.3 Released!

Stardust project homepage

Finally! Stardust version 1.3 is released!

I've updated all the examples, so they all work perfectly with the new particle handlers.

I'm currently working on the integration of Stardust and Minko, a new 3D engine that will support the Molehill APIs. Paq is working on the integration with Alternativa3D and Away3D, whilch will also support the Molehill APIs. I'm really looking forward to Stardust being used in Molehill-powered applications (especially games, of course), enriching the visual experience with 3D particles!.

Monday, January 3, 2011

Particle Handlers for Stardust 1.3

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 particlesAdded, particlesRemoved, and 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:

The stepBegin method is invoked at the beginning of each emitter step.
The stepEnd method is invoked at the end of each emitter step.
The particlesAdded method is invoked when a new particle is added to the emitter.
The particlesRemoved method is invoked when a dead particle is removed from the emitter.
The 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.