1. Why try?
2. The tools
   1. Protectors
   2. Decompilers
3. The SWF files
4. Amayeta SWF Encrypt
   1. Interface
   2. Effectiveness
   3. Overall
5. DComSoft SWF Protector
   1. Interface
   2. Effectiveness
   3. Overall
6. Kindisoft secureSWF
   1. Interface
   2. Effectiveness
   3. Overall
7. Ambiera irrFuscator
   1. Interface
   2. Effectiveness
   3. Overall
8. Conclusion

The one (and only) counter-argument I’ve heard against SWF protection goes something like this:

It doesn’t matter what you do, thieves will always be able to steal your work, so don’t bother with SWF protection.

This is a textbook example of the “perfect solution” fallacy. Thieves will always be able to crack safes, so why bother storing your money and valuables in them? And of course encryption can always be cracked, so why bother using it when transferring valuable information? Why not just release all your work and hard-earned assets out to the wild for anyone to plunder, since apparently it will be plundered regardless of whatever you do to protect it?

Why try?

Obviously we use safes and encryption &c to minimize the chances of bad things happening to our precious stuff. It’s just the same for people like me who make money with SWF files–I don’t want anyone stealing my Intellectual Property and posting it elsewhere, claiming it as their own, so I do everything I can to make the process of stealing my SWF files as difficult as possible. The more difficult a thing is to steal, the less chance there is of it being stolen–and less often.

The tools

Right now there are several tools, some even free, that allow you to decompile a SWF file to take a look at everything it contains. This is usually pretty easy because the SWF format is an open specification. This means there’s no way to fully protect anything contained in the file, such as code, graphics, sounds, or videos. However, there are applications that take precautions against decompiling using a variety of methods.

Protectors

I’ll review the biggest names in that market today:

• Amayeta SWF Encrypt 6.0.8
• DComSoft SWF Protector 3.0.1 (on twitter)
• Kindisoft secureSWF 3.5 (on twitter)
• Ambiera irrFuscator 2.1.2 (on twitter)

Decompilers

I’ll be using a combination of SWF Decrypt 1.2 and Eltima’s Decompiler v4.1 to test the effectiveness of these applications. (Side note: Eltima’s Decompiler and Sothink’s are freakishly similar.) SWF Decrypt really upset the industry when Magus (the author who wishes to remain anonymous) released it completely for free. It apparently decompiles any SWF file “protected” by Amayeta’s and DComSoft’s applications. He’s very loud about it too, calling them out on their “tricks”, such as their latest releases (which I’m reviewing here). You’ll notice he left Kindisoft and Ambiera alone, and he claims that’s because they offer real protection schemes, such as renaming functions and variables in the code. But the others claim they also use renaming, so we’ll see who’s right.

The SWF files

I’m a Flash game developer so that’s all I’m going to focus on here–single SWF files containing AS3 code compiled to run on Flash Player 9 and 10+. The files contain references to the Stage object, multiple event listeners, very high frame rates (60fps usually), and numerous computationally expensive operations such as pixel-level manipulations and heavy math functions. Here are the files I’ll be using:

• FlxCollisions
• Mode
• My pixel-level collision demo

These are free with source code available so that I can alter it if the protector requires it. The first two use Flixel (an old and new version), but if you have any (or know where to find some) non-Flixel open sourced Flash games then I’ll try that too. The third is a demo I wrote a while ago that has some heavy computation and sensitive optimizations that could trip up the protectors. Now, let’s get into the apps and see how they perform.

Amayeta SWF Encrypt

Amayeta is a subsidiary focused solely on the Flash platform. It used to have a single product, SWF Encrypt, but now also provides a SWF compression utility. Magus, author of SWF Decrypt, provides a deeper look at their history and he isn’t kind about it.

The problem I have with Amayeta right off the bat is that its flagship product’s name is completely misleading since it’s not possible to encrypt a SWF. I mean you can, but then the Flash Player wouldn’t be able to run it because the player doesn’t have a way to decrypt it at runtime–that’s just not how the player was engineered. So they are being deceitful.

Interface

SWF Encrypt has two main areas in the window: on the left is a file explorer where you pick your SWFs to protect, and on the right is the main area where you check the ones to protect (again) and view their properties.

It has an “encryption” setting with the values of “high”, “recommended”, “low”, and “custom”. If custom is selected you only have the option to set the “minimum data length”, which apparently just lets you put in a number that represents the level of “encryption” to use, with lower values being more protection.

Effectiveness

First using the recommended settings, the SWFs worked fine, no performance hit that I could tell. When I tried to open them up in Trillix, I could get to all the assets, but when I tried to access the scripts, it gave me an “out of memory” error. I tried to put it through SWF Decrypt but then the SWF wouldn’t play at all. I told Magus about this and he’s going to release a new version of Decrypt next week that should break Amayeta’s latest patch. It appears that the junk code Amayeta put into the SWFs actually worked this time.

SWF Encrypt has the options to “encrypt names” which I think is their way of saying they rename indentifiers like variables and functions. But because I couldn’t look into the scripts, post-protection, I could not verify this. I have conflicting reports about whether or not they truly obfuscate code, so I’m going to wait to see if Magus can break their patch, then revisit them again later.

Overall

It appears this latest version actually keeps Trillix from being able to look through it. However, I can’t check to see if there’s any actual renaming going on. Without true indentifier renaming, your SWFs will never be guaranteed to stay safe since the arms race between decompilers and protectors escalates endlessly. So for now, I can’t say one way or another if SWF Encrypt is solid. I can say that the level of control provided by the app is extremely limited, so even if they did do renaming, the user can’t fix a problem if the protection is too aggressive. An option to comb through your SWF and control protection on a per-object basis (ideally, per-variable and -function basis) is needed.

DComSoft SWF Protector

DComSoft has a much bigger catalog than Amayeta, all focused on Flash. Better, but the company history doesn’t appear very legitimate. According to research done by this dude and this dude, DComSoft is the same company as Eltima, a company that creates a SWF decompiler (one that I’m using for these reviews actually). That, my friends, is called “bad business practice”, if true. Besides that though, what the hell is up with the logo? If anyone has any idea what a tire has to do with Flash file protection, please let me know.

Interface

Protector has two modes: Simple and Advanced. Switch between modes using the tabs at the top of the application window. In Simple mode you can batch protect files but there are zero options. In Advanced mode though you can only protect one file at a time, but you can comb through each object and variable and check the boxes next to them, which are “Obfuscate” and “Protect”.

According to the help file:

Obfuscate renames variables, features etc. in a definite way. It doesn’t prevent from decompilation, but makes the subsequent compilation impossible.

And “protect” means

Protect modifies ActionScript in such a way that a SWF file can be played, but it is impossible to decompile it.

Right, we’ll see about that.

Effectiveness

The protected SWFs ran normally with no noticeable framerate drop. When I loaded it into Trillix though, everything appeared just fine with ZERO obfuscation–no renaming except for what Flash does automatically, no junk code/characters that would trip up the decompiler, nothing. All scripts I opened were very readable. I’d like to note however that I’m using an old version of Trillix (4.1), because the newest version would just crash if I tried to open the scripts (well, sometimes it’d work, but most of the time not). Anyway, really nothing else I can say here, just “epic fail”.

Overall

The interface is clean but offers very few options. If it actually worked I’d be ok with that, but maybe they need to add more granular controls so we can pick what we want obfuscated and by how much. It would also help if they added real obfuscation. Regardless, SWF Protector has a few licensing options. The Personal license ($40) doesn’t allow any of the SWFs protected by it to make money, while the Business license ($60) does. There’s other types for companies and OEMs too, but who cares–the software doesn’t work, end of story.

Kindisoft secureSWF

Kindisoft doesn’t mess around. When I emailed them about reviewing their app, they sent back this:

While I definitely love to hear your opinion of secureSWF, we’re not interested to see a comparison with SWF Encrypt and SWF Protector. We think of secureSWF as a professional level ActionScript obfuscator while SWF Encrypt and SWF Protector as single purpose tools that might prevent some decompilers from working for a while.

Ok then. So we start out on a completely different footing with Kindisoft than the others already. But while Kindisoft doesn’t have dirt on it like Amayeta and DComSoft do, it’s still a niche-based company providing only one product. Although that should mean they make a really great product, right?

I’d like to note that the free web-based version of secureSWF that is available to developers who put their games up at FlashGameLicense.com is apparently a different product. When I tried to add its protection to my first game, it broke it. When I brought this up with Kindisoft, they replied saying:

secureSWF is a completely different solution than FGL encryption feature. We built this complementary encryption feature for FGL community to help avoid more thief incidents. It does not use the same technology or techniques as secureSWF.

I just hope their software is better than their grammar.

Interface

SecureSWF is a bit more complicated but makes up for it in options. There are 5 tabs:

The fifth one is just a summary of what it did after you hit the big “Protect SWF Files” button. The GUI is pretty much self-explanatory and gives you a fine level of control. Hovering your mouse over any option will bring up a tooltip that further explains what the option does. So far, looks great.

Effectiveness

The real meat of the app is in the renaming, since eventually all SWF files can be cracked open to reveal their code. SecureSWF does a great job in this area. By default it will leave alone most public functions, probably because they’re usually used by other classes, so renaming them inconsistently would break the SWF.

When I protected the SWF files with the default settings, I was able to play my collision demo and Mode (which uses the old version of Flixel). I could not run FlxCollisions though, instead I got back this error: ReferenceError: Error #1056: Cannot create property D on _-9l._-68. Obviously the renaming was set a little too aggressively for it to work (and the “strength” was only at 20% with most advanced options turned off). When I tried to open the working SWFs with the decompiler, I got an access violation and the program crashed.

Overall

secureSWF only offers variable renaming in their Standard and Professional editions ($200 and $400 respectively), leaving it out in the Personal edition ($100). Considering the functionality SWF protectors provide (and how difficult they are to produce) these prices seem too high to me. The Pro edition (the version I’m using) does provide some nice additional features though, such as removing unused code (it happens), literal string encryption, and solid domain locking controls).

SecureSWF provides users with a lot of options and it would take me all day to go through them all. But the point is that secureSWF utilizes true obfuscation by renaming variables, encrypting literal strings (which Flash Player can deal with), and inserting illegal characters that will trip up decompilers… and sometimes the Flash Player too. So it takes some effort to get working, but the point is that it works. But is it good enough to justify the price? Let’s see what irrFuscator provides for its price to compare.

Ambiera irrFuscator

Ambiera comes out of the gate with significant reputation points for having developed irrLicht and related creation tools–quality open source tools for the indie game developer. Ambiera got into the Flash scene when they decided to extend their game tools to the web via the Flash platform with their own 3D engine and creation apps. They figured developers will want to protect their games and, as the irrFuscator author told me via email, the current offerings in that market “sucked”, so he built his own. With this excellent history of software already under their collective belt, I had high hopes for irrFuscator.

Interface

A quick glance at irrFuscator’s interface will bring a sigh a relief, since the layout is dead simple but all the options are there and well-explained.

If you still have trouble figuring out what’s what, the online docs are helpful and there’s even an active forum for it at Ambiera if you’re still having trouble. Very nice.

Effectiveness

irrFuscator sets itself apart by allowing you to rename all variables BEFORE you compile your project, so you can see exactly what it did and, if it messed up somewhere, you can go in and manually fix it before compiling again. This is the best method of obfuscation since you know it works, you know what it does, and you know you can fix it easily with your debugger. ALL classes and variables can be renamed, plus it removes whitespaces–even Vectors were retyped to the renamed classes, and all packages were also renamed (Flash built-ins as well). The resulting code was impossible to read.

I did run into a few problems though. I tried obfuscating my game, which references an SWC, but when I added it to the list, I got an error saying it couldn’t open it. I just removed it and it continued fine. Also, while it does encrypt literal strings (it replaces them with a function call to irrcrpt() to decrypt at runtime, which will impact performance a bit) it can’t encrypt them when they’re inside an Array or similar data structure. Not a big deal, but I was thrown off by that. The other thing is just a small UI annoyance, which is that it uses Windows’ “browse folders” dialog to pick out your SWF (in “SWF File” mode). This dialog doesn’t remember where you last looked and it always starts you back at your computers root, so it takes me a while to drill down to the proper folder, which wastes a lot of time. Those are the only issues I found though, which is saying a lot.

Using the SWF File mode is nice, but it didn’t work for me; I got back this error when trying to run the protected version of FlxCollisions (again): VerifyError: Error #1053: Illegal override of _iq39 in org.flixel.FlxEmitter. Since this also happened with Kindisoft’s secureSWF, there’s something going on in the latest version of Flixel (v2.35) that gives them grief. Both packages give you ways to work around them though with their fine-grained controls. For irrFuscator, you just have to use the Flex Project option. In secureSWF you can just uncheck that file… if you knew which file that was, but there’s no way to find that out. irrFuscator wins that one.

Overall

irrFuscator has Standard and Professional editions (~$100 and ~$200 respectively–original prices are in Euros). The difference is that the Pro edition has comment directives, which means you can be extremely precise in telling the app which portions of your code NOT to obfuscate using specially formated comments. This is because code obfuscation sometimes results in worse performance or breaks it completely, depending on the code, so this is a great feature. You decide whether or not the comment directives are worth $100 for your projects. Still, these prices are far more reasonable than Kindisoft’s–you get everything secureSWF does at a quarter of the price. Not bad.

Conclusion

I’m bummed that I couldn’t determine how effective Amayeta was, but maybe some of you will think the fact that it can’t be decompiled yet is good enough. Not for me though, because SWFs will eventually be cracked–we need better protection than that. What I did determine though is that Kindisoft’s secureSWF and Ambiera’s irrFuscator offer true obfuscation for sure and therefore true protection of your code. Assets cannot be encrypted and can always be wrestled out of a SWF, unfortunately, so obfuscation is really a Flash developer’s best weapon.

Overall I’d say irrFuscator takes the cake for being reasonably-priced and offering that Flex Project option which makes it very powerful, yet it still retains simplicity of use through an easy user experience, plus the program itself was fast to load and responsive. The others were written in Java or were otherwise slow to start, so they were a bit sluggish.

That’s it for now, but I will be updating this article later if/when we can determine if Amayeta’s obfuscation methods are valid. Thanks for reading

1. Aesthetics
2. Gameplay mechanics
3. Technology
4. Deployment and Marketing

I first released this game through Newgrounds, those poor souls, but for some strange reason it got a much more positive reception than I anticipated. They also made a lot of great suggestions that I have since incorporated into the game.

In this final update I added a storyline intro of sorts. Also added were satallites that can easily cause a ruckus by bouncing off the asteroids, making the field more dynamic (and shows off the billiard-ball-style physics I put into Flixel). I also added space storms that will cause a static overlay to appear, making things more difficult to see (if you run through them). So be sure to avoid those, even though they don’t damage your ship. So click the damn image below to play it already

Or read on if you already have and wish to know how I made TLE and why I decided on certain mechanics and concepts. I’ll start with the obvious–art direction.

Aesthetics

No one–and I mean NO ONE–knew about or even noticed the unique style I used. They thought it was nice-looking, sure, but they did not notice that, unlike other Flixel games, I did NOT scale up the graphics for that pixelated look. I got the pixelation by putting them through a filter in Photoshop. I then manually drew a heavy pixel border around every solid asset (backgrounds/effects/etc do not have any). Lastly I added a heavy drop shadow for everything, giving it all a flat “fake depth”, as if everything was made out of cardboard and kind of laying on top of everything else. I didn’t achieve this effect as well as I wanted–too subtle.

No one else guessed that I actually modeled each asset (again, except for the backgrounds and effects which I painted in Photoshop) in 3d using Luxology’s modo 401. I didn’t use any lighting, just global illumination with a white background and rendered those out to be abused in Photoshop for the process I outlined above. To prove it, here are some “HD” renders of the assets before any alterations:

Notice the little “arms” on the “chest” of the alien–that’s how they pilot their ships and got high technology in the first place

I modeled the aliens but not the dudes you see in the intro though. I modeled these things because I’m better and faster with 3D than 2D, by far. You’ll see some of my real 3D work around here in the future (that MP5 model is over 2 years old, I just wanted to see if I could make money off it). The stuff I modeled for TLE is actually semi-low-poly and extremely coarse. This is because I knew it was going to be heavily pixelated and therefore a lot of the forms I created will be destroyed. No point in modeling more than basic geometry if that’s all the player would see anyway. (It actually took me a lot of self-control to keep from adding too much detail and, in some cases–like the alien ship there–I failed.)

Gameplay mechanics

What I wanted was a fast game with very tight controls and high torque so you feel empowered by simply driving the ship around–you’ll notice it can turn really fast and accelerate to max speed in a split second. Controls are everything in a game, so I made them as solid as possible. Naturally a lot of people bitched about it being too difficult to control, but most people still enjoyed this decision. Although I did end up adding the ability to go backwards (which I never found useful but whatever, they liked it).

Secondly, I needed true interaction with other game objects. I had huge plans for the asteroids, including “composite” asteroids that would take up half the screen but be hollow in places so that you could navigate through them. I didn’t have time to build the system for this, unfortunately.

While playing with the prototype, I found just bouncing around the asteroids to be tremendous fun, but ultimately it would have introduced too many technical issues to be worth it, especially considering how much time I had to complete the game (at that point I had about 2 days left). A couple of the problems were that the physics would get wonky with too many collisions; it would also be harder to kill the player since all I could use were the aliens, and I didn’t have time to make more types of aliens.

I wanted a huge variety of objects but did not have the time. Another object that never made it into the game were black holes. Basically they were gravity wells that destroyed your ship and passing asteroids if they got too close.

Technology

I initially wanted pixel-perfect collision detection, but I could not get the billiard-ball physics to play nicely with it. So I settled with radius-based detection, and it ended up being fun nonetheless. I now know of a better, simpler reaction technique that will allow for a similar feel that ball physics provide but still work with my collision detection method. I hope to use it in future projects.

The ship travels in “real” space, while the backgrounds are adjusted in realtime after they fall off the screen. All objects are recycled, so that’s why there’s a huge pause when you hit “start”–it’s building all the object pools, and there are a LOT of object pools.

Really, that’s about it for tech–this game had nothing new or interesting since it was my first public game. I focused on polish instead. In the future I hope to apply a similar level of finish to all my games.

Deployment and Marketing

I made the game for a Newgrounds contest, so I quickly “finished” a working version of the game and posted it up just in time for the original deadline. This was accidental but ended up being a really good way to get a lot of quick feedback to bring back into the game.

Looking at my revenue using the NG ads, it is fairly obvious that ads are not the way to go. Ever. My future games will be “freemium” (microtransactions) and I’ll be shopping for sponsorships at Flash Game License. Which API to use though… that will be difficult to determine, or even if I should just use one. Here’s a classic post of the financial aspect of Flash games, so read that if you’re a dev.

For future games I’m going to follow a structured flow for deployment (trailers, sneak-peeks of unfinished assets, etc.) to build up recognition, then deploy to a lot of different portals at once (unless I get a licensing agreement that dictates otherwise). I’ll also submit my future games for review on various editorial sites. I really dodn’t think TLE was even worth the effort–it was just practice. Next time though!

Thanks for reading (and playing).

Play it at Newgrounds.

I had been prototyping 4 or 5 game designs over the past several months and during that time I hacked out the core code blocks that eventually made it into TLE. The game itself took me about two weeks of off-on work, with the last few days being pretty intense to meet the deadline. I built it using the Flixel framework.

There is absolutely nothing original about this game. It is not going to win awards, though if I won that contest I would be super-stoked. I mean, you fly a rocket ship and dodge asteroids and alien gunfire. That’s it. Remember SkiFree for Windows 3.1? It’s like that, but in space. I didn’t mean for that to happen, it just did. Coincidently, I hated SkiFree as much as I hate TLE.

NOTE: I am aware of the slowdowns. I upgraded Flixel to the latest version at the last minute due to some unforeseen requirements and it’s been bad since then. I’ll look into it when I’ve had more sleep.

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.

1. Best resources for beginners
2. Syntax overview
3. More performance tips
4. Realtime use of Pixel Bender
   1. Asynchronous mode
   2. Synchronous mode
5. Conclusion

When I set out to write a very simple Pixel Bender (PB) kernel/script thingy, I expected it to be relatively straight-forward, mostly because Adobe has been so good writing quality documentation for its products and/or there is a wealth of info on their products produced by their users. Unfortunately I didn’t find the dev guide in the Help menu and I missed some key AS3 bits from the links I’ll post below, but even so I still had a lot of trouble finding some info that really should already have been out on the interwebs. So this post is to fill in the gaps when going from AS3 to Pixel Bender.
Hope it helps

Best resources for beginners

Here’s the best tutorials and explanations I’ve found so far:

• The official guide and reference. Slap that F1 key! Also, don’t forget the Help menu in the toolkit like I did (there’s the PB-specific language spec and dev guide there).
• Using PB as a calculator. Completes the official tutorial.
• Great in-depth article with general+performance tips.
• Very straight-forward examples + comedy. Can’t go wrong there.
• Nice user article on optimizations and some speed tests (turns out, for input bitmapData beats ByteArray beats Vector.)

Syntax overview

As a casual programmer of high-level languages and no mid- to low-level ones, I was thrown off by PB’s awkward syntax. It’s strongly typed, which is fine, except I’m not familiar with low-level languages like C or any previous shader language (PB is based on GLSL from what I hear). Here’s a basic difference:

AS3: var i:Number = 12;
…in PB is: float i = 12.0;
The decimal in 12.0 tells PB it’s a floating point number. If it was just 12 PB would think it’s an int.

When dealing with “vectors” (which are arrays, as in Flash 10’s odd use of the word “vector”) it’s float2 i = float2(12.0, 2.0). Notice there’s no brackets or anything suggesting any type of array present. It’s simply the type + how big the array is, eg float3. It goes up to 4, for the 4 channels in images: Red, Green, Blue, Alpha). Then, as you can see, intializing the array is a simple matter of putting in the numbers you said would be there. So float4(1.0, 24.2, 0.1, 3.4) is valid whereas float2(1.0, 24.2, 2) is not, because there’s an extra number in there and it’s an int (adding insult to injury).

An important thing to keep in mind is that Pixel Bender sees channels in the order described above (RGBA). This little detail cost me a bit of time because I’m used to AS3’s order of ARGB–the alpha channel is first in AS3 while it’s last in PB.

To use any of the built-in functions you simply call them as they appear in the reference doc: all(x); atan(x,y); etc., no Math calls like we have to do in Flash (this through me for a loop, lemme tell ya).

For those of you who use the shortcut operations like var i:int = foo < bar ? foo : bar;, then you'll be pleased to hear they're supported in PB too. Just about the only thing "Hydra" (formally the codename for Pixel Bender, now--I guess--the name of the PB Flash implementation) does not support is loops of any kind and their related break/continue statements. That last bit is bad because there are times when I want to stop the filter if a certain condition is met. You just have to design your logic to take this into account from the start.

That's the basics but take special note that shader.data is actually an array, so you can do some naughty stuff like iterate through some kinky data and set the input as shader.data['whatever'+i].input = kinky[i]. Also note that in order to set the input for a shader in AS3 you must set it to shader.data.vdipb.INPUT = inputImage where vdipb is the variable name you declared in the PB shader itself.

More performance tips

Turns out that after I converted my kernel from using boolean methods (like boolean4() etc.) to if statements, it consistently executed faster. I also got some fractional FPS increases by using the age-old optimization of putting real values (eg 1.2) in the evaluation statement instead of references (eg pixel.r). See the last blog I linked above for some other obvious and not-so-obvious performance tips.

PB math is much faster than straight AS3 math but it's slightly brighter (I wouldn't say it shines per se...) when it runs in asynchronous mode, which is enabled by using ShaderJob. You use addEventListener(Event:ShaderEvent...) and then run start(false) to put it in asynchronous mode (the param is waitForCompletion and it's already false by default). See Ryan's post for a great example of how the ShaderJob has to be setup (Squize's post, linked above, is an even clearer example).

Realtime use of Pixel Bender

Asynchronous mode

Reading the above linked performance tips for PB you, like me, might be thinking "OH MAN I can rule the universe with ShaderJob doing bitchwork like heavy collision solving" and you'd be totally wrong. You only have to set the input for a shader once, but you do have to create a new ShaderJob per computation of the filter every frame/tick. This is the depressing because ShaderJob takes a LONG time to start up and it, unlike the job itself, does use CPU from Flash's main thread--you do not get the asynchronous hotness until the actual job is started. And it is sloooooowwwww. Unless you're doing some serious number crunching or temporary special effect, you will not see a huge benefit from using PB in your game.

To be clear, ShaderJob works well enough for realtime usage but my experiments have shown that it's not fast enough to be executed every frame (unless you're SWF is running at 20 FPS or so). I tried to get it to fulfill my game's collision detection system by processing the entire map, but PB just couldn't handle the job. Still, I do recommend you try it (using Squize's recursive implementation) and see if it works for you. Just keep your hopes down

Synchronous mode

You can set ShaderJob.start(true) but if you're going the synchronous route, I suggest applying your Pixel Bender kernel by using the filter method. It starts up much faster than ShaderJob and doesn't have to be restarted every time you want to update the input. You do have to wait for it to finish processing before it will move to the next line in your code though, but as I mentioned above, PB math is a lot faster than AS3's Math library. So if you're doing something intense(r) like severe image distortion then PB is definitely worth a shot, but if it's just conditionals then you're probably better off in pure AS3 land.

Conclusion

Besides doing complex calculations, another place where PB would really help though is processing large (like 600 or 10000 pixels wide or bigger) images. It loops through each pixel faster than AS3 does. But remember that in AS3 you can do loops, so easily skipping pixels (using the continue statement) can result in some significant performance gains if you're not processing all the pixels in the input data (eg skipping transparent pixels). There's a lot of pro/cons so experimenting is, as always, the way to go (if you can afford it).

So there it is, all the info I wish was out there when I started learning PB (I can't stop thinking of Peanut Butter!). Hope some of it was helpful and of course I could be wrong about something (except about declaring input once, I've heard otherwise but in practice it worked fine) so please don't hesitate to correct me if so. Good luck and have fun

I’ve been working on a couple game concepts and want to prototype a few more before committing to one to build out. I’ve been hacking the hell out of Flixel, which I’ve decided to use for a most of the games. There’s a screenshot of game3 on the right there. Weird, eh? Also fugly, but it’s placeholder art so there. I have a new collision detection system for it that I’ll be posting about eventually (at least, I’ve never heard of it before).

The microtransaction (MTX) dilemma

I’m really excited about all the new services that have been released to allow Flash developers to monetize their games through microtransactions. I fucking hate ads, plus the ROI of them in Flash games is usually shit. Many many years ago I knew microtransactions (MTX) were the future of digital content and I’m pleased to see the idea coming to the mainstream (in America at least, Asia was quicker on it as usual).

The problem I’m seeing with MTX is that Flash developers need to try a lot harder by making much bigger games in order to really reap the rewards. Before, you could make a pretty simple, fun and addictive game and monetize it easily with ads. But with MTX, you can’t do that as easily since you need to build more content for players to buy into. For example, to me, putting premium content in a Tower Defense game isn’t viable–the game concept is so small that I doubt anyone is going to pay anything for more turrets or maps (for example). There just isn’t enough game there.

So in order to realistically bring MTX into our games I think we’re going to have to build much bigger games, and that kind of sucks because that makes it much harder for indie devs to make good on their work. Hell, this might actually decrease the quality of Flash games due to the higher gate devs will need to jump to get in. Well, let’s just see how it goes but I for one am having to take a lot more time building a game worthy of MTX-enabled content

By the by, below is my current list of MTX-enabling services currently available. If you know of any others, please leave a comment

• GamerSafe – Seems to be the best choice so far. Adds achievements, microtransactions, save games, leaderboards, etc in a unified, web-wide accessible account.
• Nonoba – Like GamerSafe, but also has a multiplayer network… but you must have a nonoba account to keep multiplayer stats/items etc (but guests can still play, just not save). Anyone used their multiplayer API yet?
• MochiCoins – MTX only. Can’t use with other systems so I’m completely ignoring this one.
• HeyZap – Also MTX only.

It’s best to include as many options for your players as possible, so given this list, you would allow premium content to be purchased with GamerSafe, Nonoba and HeyZap.

New additions to C³

I’ve made a significant number of changes to the site itself. Besides the better layout (960gs ftw) I added this awesome Wordpress plugin that does an excellent job highlighting AS3 code (see previous posts with code)… except it’s fat and makes the site load slower, but whatever. I can fix that with another plugin (I <3 WP).

Also you can socialize my posts now, using Sociable; you’ll also see new blog posts updating my Twitter status (I mainly wrote this post to test that actually). I still have a bit to do for the site aesthetically though… but I kinda like tweaking themes, and now that IE is growing up (sort of) web design has been a little easier. I still can’t wait for Google’s bitch-slap to MS though. That’s so baller.

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.