A: You mean aside from the fact that they're cool and lots of fun to play with? I'll use fire as an example. To achieve realistic fire in a Flash movie, you would generally have two options: video or an image sequence. If you use video you have the usual problems of file size, frame rate, and the difficulty of finding good fire video clips with no background on them. If you use an image sequence you have similar problems; file size, and the joy of removing the background from several hundred images of a flame, which is semi-opaque and a real pain in the neck to remove the background from. Assuming you have the patience to edit the background out of a video or image sequence, you're still talking about, for example, a 10 second video clip, or 300 images of the fire (30 frames per second X 10 seconds = 300 images), either of which is going to kill your file size, and even if you can live with that, real fire never loops. That means that if you need the fire on the stage for 11 seconds instead of 10, you'll see a skip in the animation.

     With particles you have none of these problems. With the MX 2004 component file size is not an issue, because the component is under 10k, and if you are careful about how you compress your artwork you can have your fire particle for less than 2k. That's 10k-12k total for a fire animation that never loops, skips, or stops acting like fire, and never adds additional file size to your movie. In addition to that, if you need to use another particle system, either in the same scene or in a later one, the component is already loaded, so the only additional file size would be that of your new particle artwork (generally 1k-3k).

A: Yes. Flash 8 was mostly improvements to the development enviornment and a few new features like filters and the image object. These features, while very cool, don't really do anything for the performance of ElementalFX, and since the underlying language and player haven't changed, there simply isn't a good reason to update for the Flash 8 player. The next version of ElementalFX, version 3.0, will be released for the Flash 8.5 player, which includes some new APIs, a whole new player engine, and ActionScript 3.0.

In the mean time, ElementalFX 2 will continue to work under Flash 8 just like it did under Flash MX 2004, except that the Flash 8 player has a few performance improvements that are likely to make it run a bit smoother and faster. ElementalFX 3 will be written in ActionScript 3, and designed to take advantage of the new features and performance iprovements of the new player engine. I had already began writing it when Macromedia announced that they wouldn't be releasing the new player engine with Flash 8, but in my irritation with Macromedia, I failed to announce it.

The second problem is the Level setting. Level is actually misnamed, what it really sets is the starting depth (I'll probably change it to "Depth" in the next release). So in addition to overwriting the names (and therefore the objects), the emitter that starts later is also putting particles into the same depth as the other emitter, again overwriting whatever was in that depth. I used 1000 as the default because I figured that for most single-emitter uses, a starting depth of 1000 should keep it from conflicting with most other scripts and should keep it on top of most other artwork. I almost made 10,000 the default, but figured that I could explain how it worked in the docs and people could set up their own depths. The Level settings is also only the *starting* depth.

So if Prefix is set to "p" and Level is set to 1000, then the initial particle (the one being copied) is instantiated at a depth of 1000 and is named "p" (it is not visible and is moved off the edge of the stage), and each duplicate of that particle is named p+particle number (p0, p1, p2, etc) and is placed at a depth of Level+particle number+1 (1001, 1002, 1003, etc).

Originally, I was generating both the prefix and the depth automatically, but found that both of these settings were necessary for complex, multi-emitter effects. The problems came up when I had other scripts generating duplicates of a movie clip, so I needed to be able to specify the particle prefix, and when I needed to put the particles on top of or behind other movie clips for effect. I think I mentioned this in the docs, but a good thing to do is to figure out how many particles are being generated by an emitter so that you can place the particles at appropriate depths without having them spread out all over the place. So, for example, if an emitter is generating 1 particle per frame (Rate = 1) and each particle lives for 30 frames (Life = 30), then all that is being generated is the initial particle and 30 duplicates, so you only need 31 depths for that effect and the next emitter could actually have a Level setting of 1032 (assuming Level=1000 for the first emitter). So, as a rule of thumb, I usually set the prefixes and depths to "a", "b", "c", etc, and 100, 200, 300, etc (respectively), since I rarely have emitters create more than 100 particles.

A: More than 100 particles on the stage at a time is usually the point where Flash starts to slow down, depending mostly on the amount of transparency involved in the effect. Flash can't handle a lot of movie clips with gradient transparency moving around on top of one another, it just chokes. The other choke point for Flash is if you have too many particles being generated at once. You see, I calculate the complete life of the particle at birth (position, scale, tint, etc for each frame of its life, which is passed to the particle at birth as an object containing arrays of values), to save CPU cycles during the life of the particle for rendering and other scripts, so if you are generating 50 particles in each frame, all of that calculation is just too much for Flash (which is why the fireworks sample isn't as impressive as it could be, too many particles being generated at once). Calculating the particle's whole life at generation rules out real-time collision, but the math involved in real time colission is too heavy on the processor to be useful for more than simple examples anyway. At any rate, when I had the particles doing their own calculations in real time, I hit a brick wall at something like 50 concurrent particles, and that was with nothing else taking up any CPU time.

Something I'm considering for future a version is to build the whole thing in JSFL and do all of the particle math at design time, to eliminate *all* CPU load caused by calculating particle positions and stuff, which would allow a lot more flexibility, including collisions (design-time, not real-time), but would mean that all the particles are essentially just movie clips on the timeline, which could be moved, deleted, or have their properties overwritten. I'm still weighing the pros and cons of that approach, though.