To squeeze all the juice out of Flash I employed a couple tricks. The first was the particles themselves–they’re blitted to a single bitmap which is used as the source image for grabbing collision data from. The particles are also drawn with the raster engine in Flash (multiple setPixel32() ops to give the illusion of a line… a choppy one anyway) instead of the vector renderer (lineTo()). The second trick was to only grab a Vector of pixels from the regions we cared about (within sprite boundaries) every so often, then to loop through the Vector and test it against our desired conditions. Also, since the particle bitmap is more sparse than our sprites as far as opaque pixels go, we test the particle bitmap first, resulting in a lot fewer passes on the first round of conditional statements.

So my poor man’s method of making lines is done by interpolating the position of a particle from the previous to the current frame, for a total of 3 setPixel32() operations per iteration. (We can use setPixel() for a solid performance gain, but at a different kind of cost that I’ll explain later.) To give the particles a long tail we simply decrease the alpha of the particle bitmap a little bit every frame, making older particles fade more as time goes by. This means we can skip fillRect() to clear the bitmap every frame, but I’m wondering if that’s faster or slower than ColorTransform. Haven’t tested, for shame.

I’ll admit that I haven’t tried this method with bitmap-based particles but those would work just as well, in theory (using blitted rendering). One of my current projects demands those trailing things so I didn’t look into it. If you try it, please comment on this post below with your findings
Click on the right-side arrow to unroll this block of code.

particleMap.lock();
for (i = 0; i < _numParticles; ++i) {
	p = particles[i];
	// get our velocity from the perlin noise map
	vel = noiseMap.getPixel(p.x>>3, p.y>>3); // because noiseMap is 1/9 the size of particleMap
	var brightness:Number = vel / 0xFFFFFF;
	var speed:Number = 0.1 + brightness * p.speed;
	var angle:Number = 360 * (brightness * p.wander) * 0.0175; // roughly PI / 180 to convert to radians
	p.vx = Math.cos(angle) * speed;
	p.vy = Math.sin(angle) * speed;
	// absolute value for velocity calculations
	var pvx:Number = p.vx < 0 ? -p.vx : p.vx; // use bitwise sign flippage
	var pvy:Number = p.vy < 0 ? -p.vy : p.vy;
	// poor man's lineTo ENGAGED
	var nx:Number = p.x + (p.vx >> 1); // where we are now + half the distance to where we will be
	var ny:Number = p.y + (p.vy >> 1);
	var mx:Number = nx - p.x; // then half THAT distance for a third position...
	var my:Number = ny - p.y;
	// actually apply velocity to pixel
	p.x += p.vx;
	p.y += p.vy;
	// bounds-check
	if (p.y < 0) p.y = h - 1;
	else if (p.y > h) p.y = 1;
	if (p.x < 0) p.x = w - 1;
	else if (p.x > w) p.x = 1;
	// pick our color based on speed
	speed *= 60;
	if (speed > 255) speed = 255;
	color = 255 << 24 | speed << 16 | speed << 8 | speed;
	// render the particle three times, each in different places to get a line-ish thing going
	particleMap.setPixel32(p.x, p.y, color);
	particleMap.setPixel32(mx, my, color);
	particleMap.setPixel32(nx, ny, color);
}
// and we're done. release the pixels!
particleMap.unlock(_r);

So that gives us some spotty-but-close-enough trails to help with our collision detection. It works like this: We create a single bitmap to use as a canvas for our particles. We render those particles using setPixel32() as mentioned above. Sprites will use this bitmap as a source for collision data. Every other frame or so (more on this later) the sprites will grab a section of pixels from the particle bitmap using something like getVector() (>= Flash 10) or getPixels() (< Flash 10), using their own position and dimensions for the sourceRect parameter.

133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158

shipVec = buffer.getVector(_rc); // get an array of pixels from the whole sprite
_rc.x = int(this.x); // change rect to particleBMD's coordinate space
_rc.y = int(this.y);
pixVec = _particlebmd.getVector(_rc); // grab an array of the same area of pixels that our sprite is occupying
var a:uint;
var i:int = 0;
buffer.lock();
for (i; i < _l; ++i) {
	_pval = pixVec[int(i)]; // first look at the particle's image for opaque pixels
	a = _pval >> 24;
	if (a < 100) continue;
	// it found an opaque-ish pixel, so let's see if there's an opaque pixel in the ship there too
	_sval = shipVec[int(i)];
	a = _sval >> 24;
	if (a < 100) continue;
	/* if we get this far then we have a collision because one
	 * of the ship's pixels is overlapping a particle's pixel.
	 * we're only going to collide with red-colored particles though */
	_pval = _pval >> 16 & 0xFF; // red channel extraction
	if (_pval > 100) {
		var px:int = int(i % w); // translate 1d array coordinate to 2d grid coordinates
		var py:int = int(i / h);
		buffer.setPixel32(px,py,0xFF4e88c9); // colliding pixels are painted on the top of our sprite in a cold blue-ish color
	}
}
buffer.unlock();

As you can see on line 133 and 136, each sprite has a block of pixels ready to examine on each tick. The sprite loops through that block and compares every pixel of its own with the pixels in the Vector it got. If there's a match (eg both pixels are opaque) then look at the particle's pixel in detail to see if it's the droid one we're looking for and record its findings.

So you can alter line 151 so that the sprites check for specific colors in the particle bitmap, like anything brighter than dark grey (which I did here, or anything with an alpha greater than 0.1 or... use your imagination I guess?).

Because grabbing a new Vector from the particle bitmap can be so expensive (depending on the size of the sprite), you can time limit the collection so it only samples the particle bitmap once in a short while. In the demo SWF above I sample it once every 100 milliseconds or so, which comes out to about 24 samples a second (given 25 milliseconds per frame at 60 FPS)... as opposed to 2400 samples a second. The casual human eye can't tell the difference but it yields a significant increase in performance. Most performance tricks I've learned are based are smoke and mirror stuff like this.

You can use setPixel() (no alpha) but you'll have to test for color--obviously for a color that isn't what the background of the particle bitmap is, so it's a little more tricky. It's also totally possible to use other sprites as particles as long as you blit them (using copyPixels() or setVector()) to a single bitmap that can be checked by other sprites that collide with them. If you don't know what blitting is, 8bitRocket has a good rundown (it's where I first learned about it actually).

And that's pretty much it. You can download the example files/source below.

I started by converting the thumbnail to a Vector array of Bitmaps. I planned on using TweenLite to shuffle each bitmapped pixel off the screen, and hoped I could do some fancy stuff with the Bitmaps like scale them for interesting effects. I did this by dumping the uint values of the bitmap into a ByteArray using getPixels(), then creating a new Bitmap for each value in the ByteArray using readUnsighnedInt() in a while loop. Each new Bitmap (representing a pixel of the original image) was added to that Vector array I mentioned:

var pixels:ByteArray = srcBMD.getPixels(srcBMD.rect);
pixels.position = 0; // make sure we start reading from the beginning
var newx:int = src.x;
var newy:int = src.y;
while (pixels.bytesAvailable) {
	var splodeParticle:Bitmap = new Bitmap(new BitmapData(1, 1, false, pixels.readUnsignedInt()), PixelSnapping.ALWAYS);
	splodeParticle.x = newx;
	splodeParticle.y = newy;
	++newx;
	if (newx > src.x + src.width) {
		++newy;
		newx = src.x;
	}
	container.addChild(splodeParticle);
	pixArray.push(splodeParticle);
}

I’d then loop through each item in the Vector to tween them off stage, revealing the loaded content below them.

Turns out this was a pretty dumb idea. The performance was extraordinarily sluggish during the while and for loops (naturally) and I wasn’t able to get a smooth tween because of this. Also, the ByteArray did not recreate the original image correctly — it came out rather distorted:

I’m still not sure why, as this is my first time dealing with the ByteArray class, but I figured I’d cut my losses and try a different approach.

Since I was getting great results with blitting in other experiments, I figured I should try holding a Vector array of Points that represented the pixels I wanted to move around. The actual “moving” simply ran setPixel() on a Bitmap for each Point in the array after I ran some translation calculations to get shit moving all nice-like. Points have a lot of extra baggage that I didn’t want though, so I just used a custom class that simply stored some dimensional variables and called it good.

I based my classes off of Andre Michelle’s Bitmap Particle experiment — he knows more math than I ever will and came up with a fucking brilliant effect there that I can only dream of achieving, so mad props to that bloke.

Anyway, as you can see this worked out pretty damn well. I could spend a whole week on this experiment, playing with the variables (especially the ignite var) to get different transitional effects, as well as adding more filters… but I’ll just leave this basic example for you to play with. Just be sure to show me anything particularly cool you come up with!

The particle trails you see are actually all on one bitmap that I draw to after updating each particle in sequence, per frame tick. The particles themselves are a simple class that keeps track of a few variables such as velocity and position. The class doesn’t extend anything, instead the Main class of the swf draws a line from where the particle was in the previous frame to where it is in the current frame.

To make them fade over time I simply did a colorTransform on the whole bitmap at the begining of the tick method. I didn’t alter any hues obviously, I just subtracted the alpha value of the bitmap a little. So the longer the pixel has been in the bitmap, the lower it’s opacity. I wish I can claim that cleverness but I actually got the idea from somewhere else… probably 8bitRocket.

This method of graphics manipulation, called blitting, is the way to get a metric fuck-ton more performance out of Flash than is possible with mere Sprites. You can see there’s 600 “particles” in the demo — had I simply extended the Sprite class and used that to render the scene, I probably would have only been allowed a few hundred sprites while keeping the framerate at around 30.

If you want to see some great examples of blitting, check out 8bitRocket’s posts on the subject. You can even find a blitting engine called PixelBlitz — check out this badass schmup demo of his!

A quick google didn’t yield anything relevant, so I was left to my own devices. I remembered being able to draw pixels to a BitmapData object while writing my game in order to improve performance, so I figured I’d see if I could just copy the pixels from the text field and “bake” it into a bitmap.

Turns out you can. In fact, Adobe had already done this in the help files and it’s actually extremely easy. Check it out:

var tf:TextField = new TextField();
tf.text = "bitmap text";
var myBitmapData:BitmapData = new BitmapData(80, 20);
myBitmapData.draw(tf);
var bmp:Bitmap = new Bitmap(myBitmapData);
this.addChild(bmp);

No sweat right? Anyway, since I didn’t find any help on this anywhere else (granted, I didn’t look very hard), I thought I’d share this little adventure of mine. Hope it’s helpful.