Well, what a pleasant hiatus that was. Almost 3 months. However, no more! I shall get back to blogging random useless technical details about various things. I know you missed me really.

So, what's happening next? Well, firstly, I'm temporarily turning to the Dark Side and getting a Nexus One. This shiny new toy should be in my sweaty paws within the week. I'm thoroughly looking forward to breaking it. I may even try some Flash programming on it, although I'm far more interested in the Android NDK at the moment. Since I have no creative bones, I want to see how well it lends itself to running Box2D (I know it's already been ported to NDK, but what's the point of Open Source if you can't rewrite the wheel every couple of weeks?).

After that, I may actually get around to finishing the shabby little accelerated computation engine thingy I was writing for PixelBender and Flash.

Maybe by mentioning these things somewhere, I'll actually get around to finishing them...

Firstly, however, I'll have to tinker with Eclipse. I really don't like white backgrounds and black text in a code editor. Plus, I like procrastinating and putting off actual productive work.

While you are waiting for all those terribly exciting projects to appear, why not go an learn guitar? You'll have time. Try http://justinguitar.com/ for nice course.

The CompactFlash association has just released a new specification for future CompactFlash cards. It involves big numbers. 144 petabytes big, to be specific. But how big is that really?

144 petabytes = 150,994,944 gigabytes.
Production quality 1080p video: 3 gigabits per second which equals 0.375 gigabytes per second.

So, using that:

150,994,944 / 0.375	= 402,653,184 seconds of video
	= 6,710,886.4 minutes of video
	= 111,848.106. hours of video
	= 4,660.337. days of video
	= 12.768 years of continuous video

Got that? 12 years of continuous 1080p video. Slap around 9 of those in a camera and you can continuously video almost anyone for their entire life. May as well be generous and use 10 - that should let you stick some low quality sound recording of their entire life on it too.

I suspect the future will see an increased number of murders due to screenings of family holiday videos...

Just a quick tip if you are having problems with Eclipse, FDT or other Eclipse based tool and writing to dot files cloned from a git repository.

If you are seeing messages about not have permission to write to ".project", ".as3_classpath" and so on, there's a reasonable chance that msysgit (or potentially TortoiseGit) automatically set the dot files to hidden to mimic what you see on a real^h^h^h^h 'nix based machine. While this is nice, for some reason Eclipse, or possibly the underlying Java file calls, can't write to hidden files on Windows so you get access denied messages.

Fortunately, the solution is very simple. Open up a git Bash prompt, and enter this:

git config --global core.hidedotfiles false

And that's it. With core.hidedotfiles set to false, msysgit will no longer set the hidden property on dot files, and Eclipse should be ready to rock.

Of course, this only affects newly fetched files, so if you want to clear the hidden flag on existing files, jump into a cmd prompt (or this may work from the git bash prompt) and type:

cd folder_containing_the_repository
attrib /s /d -H *

Pop quiz time!

What appears on stage with the following code:

public function newChild() :void
{
	addChild(new CircleSprite()).x += 50;
}

Wrong. This is what appears:

Of course, all you clever observant folks will have noticed that that the circle's x coordinate is being set using a compound operator, +=. That's the culprit in this unusual case.

Now, putting aside any crazy reasons for wanting to write code like that in the first place, what's actually going on here? Well, one way to find that out is by shrinking ourselves down and entering Inner (ABC) Space! (SPACE... SPAce... space...)

Yep, it's time to get roll up our sleeves and get oh, so dirty rooting around in the ActionScript Bytecode (herein known as ABC to spare my keyboard). It's not going to be pretty, and I'll probably misinterpret some of it but, just like a good orbital nuking, it's the only way to be sure. Also, like an orbital nuking, it's a little bit over the top, but I wanted an excuse to start becoming a little more au fait with ABC because, well, because I'm a geek and I like knowing how things work.

So, here are those lines once more, but in a format closer to what the Flash player VM sees:

function :CompoundOperatorsAndNew:::newChild()::void
maxStack:3 localCount:1 initScopeDepth:9 maxScopeDepth:10
    getlocal0
    pushscope
    findpropstrict	:addChild
    findpropstrict	:CircleSprite
    constructprop 	:CircleSprite (0)
    callproperty  	:addChild (1)
    findpropstrict	:addChild
    findpropstrict	:CircleSprite
    constructprop 	:CircleSprite (0)
    callproperty  	:addChild (1)
    getproperty   	:x
    pushbyte      	50
    add
    setproperty   	:x
    returnvoid
0 Extras
0 Traits Entries

Highlighted are the 2 groups of lines that cause the problem. 2 circle classes are being created with the lines "constructprop :CircleSprite (0)", and both are being added as children with "callproperty :addChild (1)".

Before we muse on why Flash compiled the ActionScript at the top of the article into this ABC, let's have a closer look at the bytecode and try and work out what it is doing.

In general bytecode, like assembler, is pretty straightforward. There's just an awful lot of it to trek through. So don't be intimidated.

One thing to be aware of however are the values on the stack. The stack is just a last in - first out list of items which operands (the word before the colon in the ABC listing) have access to. Different operands affect different numbers of items on the stack. The AVM 2 Overview document Adobe provide will tell you exactly how many, and what it'll do to them.

Ok, let's take them a line at a time. I'll stick in comments to the right of the lines showing the contents of the stack before and after the line is executed, like this: // [stack contents before line] => [stack contents after line].

function :CompoundOperatorsAndNew:::newChild()::void
maxStack:3 localCount:1 initScopeDepth:9 maxScopeDepth:10

Ok, we're going to ignore this bit. All it's doing is setting up the stack and a few other bits so the code in the function can start to execute in a sane fashion. The most important thing here is localCount which tells us how many arguments are in the registers having been passed to the function. You may notice there are no arguments, but localCount is 1. Well, that's because the instance of the object that the method was called on is always passed as the first argument. That's what the "this" keyword refers to. The compiler passes it for you automatically.

    getlocal0		// [empty] => this

Grabs the item in register 0 and puts it on the stack. As mentioned above, the "this" object is in register 0, so that is what is put on the stack.

    pushscope		// this => [empty]

Moves "this" onto the scope stack. The scope stack holds the objects to be searched when certain items and properties are requested. You can think of this little code flourish as what allows you to refer to a variable or method in the current instance of the class, more or less.

    findpropstrict	:addChild		// [empty] => this

This line searches the objects in the scope stack for a property called "addChild", and puts it on the stack. In this case, since the class we're in inherits from DisplayObjectContainer, it's instance is pushed onto the stack.

    findpropstrict	:CircleSprite	// this => this, class CircleSprite

Here the class definition for CircleSprite is being searched for.

    constructprop 	:CircleSprite (0)	// this, class CircleSprite => this, circle0

This grabs the class definition which was found for CircleSprite and constructs a new object from it and places it on the stack. I've numbered the instance, just so things are clearer later on. The number in brackets after the class name indicates how many arguments to pop off the stack and pass to the class constructor as arguments - in this case, there are none.

    callproperty  	:addChild (1)	// this, circle0 => circle0

Here, addChild is called on the object found by "findpropstrict :addChild" above. As you can see, the call has (1) argument - in this case the circle0 instance. circle0 appears on the stack afterwards because it is returned from addChild.

Just in case you are wondering, the number of arguments specified are popped off the stack and put into registers before the property, addChild is called. That's why addChild is called on "this" rather than circle0.

    findpropstrict	:addChild // circle0 => circle0, this

Behaves exactly as described earlier. Also, this is where the confusion starts.

    findpropstrict	:CircleSprite	// circle0, this => circle0, this, class CircleSprite

Again, the same as before.

    constructprop 	:CircleSprite (0)	// circle0, this, class CircleSprite => circle0, this, circle1

Ditto.

This is why we have 2 circles. Note, I've called this instance circle1 in order to differentiate it from the previously constructed instance. Internally, CircleSprite counts it's instances, so circle0 matches the circle marked 0 on the screen, and circle1 matches the circle marked 1.

    callproperty  	:addChild (1)	// circle0, this, circle1 => circle0, circle1

Looking familiar? Good! That means you're paying attention...

Remember, addChild returns what was passed to it, so that's why circle1 is back on the stack.

    getproperty   	:x	// circle0, circle1 => circle0, 0

This line is reading the value of x from circle1, which will be 0. It's shoved on to the stack.

    pushbyte      	50	// circle0, 0 => circle0, 0, 50

Pushes are pretty straightforward - it's pushing the literal value onto the stack. It's interesting to note here that this code is pushing a byte, rather than an int or a number - the compiler seems to choose the "narrowest" possible type for a literal.

    add				// circle0, 0, 50 => circle0, 50

Does exactly what it says on the tin, which is to add things. In this case, the two most recent items on the stack are added, and the result is pushed back onto the stack.

    setproperty   	:x	// circle0, 50 => [empty]

Here, x is set to the value which is popped from the stack, and it's set on the object that's popped next. So, in this case, circle0.x is set to 50 - hence the movie having circle 0 to the right of circle 1.

    returnvoid		// [empty] => [empty]

It, er, returns void...

So there you have it. Your first dive into ABC. *prod*. Are you still awake? Honestly, this stuff is interesting. Really.

One nice thing about looking at ABC is that you can see which idioms compile to more terse ABC code. As a very general rule of thumb, the terser the code, the faster it will run. This is not a law though - you still have to profile things. Unfortunately, Adobe don't provide any normalised speed of execution for each operand, so it is hard to get a good grasp of what operand sequence is fastest, except by experience.

Hopefully, I'll be taking a bit more of a look at what ABC is output by the flex compiler over the next few months. I may even get around comparing the quality of the output to that of Haxe. If I'm feeling particularly daring, I may even write some bytecode. I know, the party never stops around me...

[Those of you who actually make it this far may have noticed that I haven't actually answered the "why" of my initial problem. I've left that as an exercise for the reader. Or, more honestly, I'm still thinking about it...]

Ok, more real coding avoidance*. I hacked together a little SyntaxHighlighter Evolved colour scheme so that my eyes aren't offended when I post code in this blog. Here's an example with lines 5-7 highlighted:

package dt.particles
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.geom.Point;
	import flash.geom.Rectangle;

	/**
	 * Particle manager.
	 *
	 * @author David Wagner
	 *
	 */
	public class PMan extends Sprite
	{
		private var _emitters :Array;
		private var _bd :BitmapData;
		private var _b :Bitmap;
		private var _r :Rectangle;
		private var _zeroPoint :Point;

		/**
		 * Constructor.
		 *
		 * @param p_width Width of the particle area.
		 * @param p_height Height of the particle area.
		 *
		 */
		public function PMan( p_width :int, p_height :int )
		{
			super();

			_zeroPoint = new Point();

			_r = new Rectangle( 0, 0, p_width, p_height );
			_bd = new BitmapData(_r.width, _r.height, true, 0x000000);
			_b = new Bitmap(_bd, "never", false);

			addChild(_b);

			_emitters = [];
		}

		/**
		 * Adds a new particle emitter.
		 *
		 * @param p_particleCount Number of particles
		 * @param p_x Emitter X
		 * @param p_y Emitter Y
		 * @param p_colours Array of colours the particles are randomly chosen from
		 * @param p_bouncy Indicates if the particles should bouncy at the edge of the area, or die.
		 * @param p_boundingArea Indicates a constraining box the particles must appear in. If null, the full size of the area is used.
		 *
		 */
		public function addEmitter( p_particleCount :Number, p_x :Number, p_y :Number, p_colours :Array, p_bouncy :Boolean, p_boundingArea :Rectangle = null ) :void
		{
			if( p_boundingArea == null )
			{
				p_boundingArea = _r;
			}
			_emitters.push( new PEmitter( p_particleCount, p_x, p_y, _bd, p_boundingArea, p_colours, p_bouncy ) );
		}

		/**
		 * Updates each emitter.
		 *
		 * @param p_emitter
		 * @param p_index
		 * @param p_array
		 *
		 */
		private function forEach_updateEmitter( p_emitter :PEmitter, p_index :int, p_array :Array ) :void
		{
			p_emitter.update();
		}

		/**
		 * Updates all the emitters.
		 *
		 */
		public function update() :void
		{
			_bd.lock();
			_bd.fillRect(_r, 0x00ffffff);
			_emitters.forEach( forEach_updateEmitter );
			_bd.unlock();
		}
	}
}

You can grab the theme from, along with installation instructions:

• http://github.com/mnem/sh-zenburnish

Assuming I don't break anything when I move flat tomorrow, I may actually get around to finishing off the post on ActionScript bytecode that I've been fiddling with.

Ok, in order to avoid any real coding at the weekend, I set about messing with the colours and settings within FlashBuilder 4 to turn it into something a little less searing on the eyeballs. These are the results:

Certainly more soothing on my eyeballs anyway. You can grab the theme from:

• http://github.com/mnem/fb-zenburnish

There are instructions for installation in the README file, but for the sake of padding out an entry to make it seem like I wrote more, here they are in full:

1. Launch FlashBuilder.
2. Choose File → Export → Other.
3. Open General and select Preferences.
4. Click next, select "Export all" and "Browse…" to save a backup of your current preferences somewhere.
5. Keep that backup safe in case this all goes titsup.
6. Choose File → Import → Other.
7. Open General and select Preferences.
8. Browse to where you've downloaded fb-zenburnish.epf and select it. Make sure "Import all" is selected, ignore any warnings and hit "Finish".
9. Panic, as your colours look crazy-ass.
10. Choose File → Restart to reload Eclipse.
11. Exhale gently and let the sublime colours wash, soothingly, through your eyeballs, caressing your optic nerves, and then engaging in a group hug with your brain.

Well, I like it anyway. I don't hold with this modern nonsense of having a white background for everything. I'm a programmer, not a surface dweller.

In case you are interested, the original (and best, of course) zenburn for vim theme is here:

• http://slinky.imukuppi.org/zenburnpage/

P.S. I highly recommend downloading Inconsolata to use a programming font. It's beautiful, and practical. I generally use Anonymous Pro for texty programming stuff, but that doesn't seem to work very well in Eclipse. I may switch all my editors to Inconsolata though, now I know it exists.

[This entry was originally going to be a comment on Christopher Caleb's post, "Adobe's Mobile Strategy Fundamentally Flawed?", but I have an annoying habit of writing rather more than I have to, so I granted this corpulent comment a promotion to First Real Post.]

Flash on mobile devices. It's an interesting prospect. Of course, it's more than a prospect, it already exists to some extent. Adobe's dream is to create an engine which allows Flash content to be run on all major platforms, and it has set it's sights upon mobile devices because they offer the tantalising prospect of being a bit of a cash cow, one way or another.

Christopher's post is a partial response to Aral Balkan's post, so you may want to have a quick skim over them. They're quite interesting. I'll wait here for you. Go on. Just don't forget to come back, y'hear?

Read them? Good. Let us begin...

Flash Lite. Failure? Yes. Success? Yes.

Flash Lite failed in it's grand vision of providing a large, consistent, mobile platform on which to view Flash style content. Currently only a handful of phone models support the latest (backwardly not very compatible) version of Flash Lite, and even amongst those, horrible incompatibility pixies strut around presenting their fail feathers.

It succeeded, however, as a necessary first failure in order to work out what was probably for a successful cross platform, uh, platform. I'm sure within Adobe it spurred many people along paths that needed to trodden in order to move toward a reasonable version of Flash on mobile devices. It also succeeded in inspiring a small but remarkably dedicated segment of developers and designers, giving them a tantalising hint as to what could have been, or should have been possible for mobile app creation.

It's time to let it rest in peace though. Flash Lite, as it stands, is dead, or perhaps the living dead. Not only is it quite expensive to develop content for, there is very little chance you will recoup all of that investment. Distribution for developed applications remains a nightmare because it is modelled on the old, pre-Apple distribution mechanisms: carrier deals, random user stumbling and dusty website warehouses holding applications of unknown quality.

The next big failure looming for Adobe is their Flash web plugin for mobile devices. Why will it be a failure? Partially because even on my dual core, 64 bit laptop with 4GB of RAM and a ridiculously huge amount of memory bandwidth, the (mis)use of Flash causes a significant proportion of web pages to run far slower than they need to. This isn't necessarily the fault of the RIA/Flash game you came to look at, but when you add all the Flash adverts and other random elements into the mix, it is an unpleasant experience. Now try to imagine this on a mobile device which can't throw data around very fast, either in terms of memory bandwidth or network bandwidth. Then mix in a healthy dose of sucky and uncertain device input capabilities, developer assumptions over screen size and resolution and pour in some speed-of-development-over-engineering-worthiness-of-development and inhale the resulting heady scent of user disappointment. It's going to be a mess.

Traditionally, this is where advocates of mobile and desktop convergence drag out the old dying horse representing the Speed of Technological Advance. Alas, unless desktop technologies stand still (they won't), this argument is hobbling along on shaky hooves as it is. Coupled with cold hard physical facts to do with heat dispersion versus space, battery life versus cpu power and, finally, the harsh pointy stick of cost of manufacture, we can lead the old horse gently to the great big glue factory in the sky. Small handheld mobile devices will be playing catch up for the currently foreseeable future.

Adobe's last gasp for mobile success rests on other people doing Adobe's work for them, and providing nice hooks for a core Flash component on all mobile devices. This is likely to yield one or two high profile success stories, but will be followed by an awful lot of poorer stories.

Part of the reason is what commercial advantage do OEMs have for ensuring excellent compatibility for Adobe's Open Screen project?

Initially, there will be a significant marketing advantage for the first devices out to support Flash well. It will be a bullet point which will persuade many uncertain buyers to part with their cash. However, this will be a short lived advantage. If it is popular, a version will be quickly offered on other devices (apart from iPhone of course), summarily added to the marketing bullet point list, and then left to rot in good-enough feature hell. And lo, the mistakes of version fragmentation shall be repeated once more.

An alternative would be for Adobe to keep the versions for every platform in house and ensure the quality itself. However, it's very unlikely they have the resources to undertake such an enormous project, and they certainly won't have all the access they need to pre-market devices to ensure quality.

A brief diversion here over the responsibilities of OEMs. Many people blame OEMs for device fragmentation hurting 3rd party technologies. They are wrong. The pusher of the proclaimed cross platform product bears the majority of that burden. Said pusher (be it Adobe, be it Sun) is likely to benefit most from wide adoption, so they must accept most of the risk. OEMs have already invested a huge amount in the design, production and likely marketing of the device, so they have already brought enough to the table.

Where was I? Ah yes, version fragmentation. Version fragmentation is bad, however hardware fragmentation is worse. Version fragmentation can be reasonably dealt with, hardware fragmentation is almost impossible to deal with fully. Beyond some sort of certification program run by Adobe to ensure a minimum set of capabilities, there isn't a great deal Adobe can offer. This will result in the Flash Lite mistake of writing for the largest common feature set, which may not be the most enticing feature set.

The problems faced by Adobe here are not new. They were the same problems brought to light by Java Mobile (or whatever J2ME is called these days). Sun failed to solve them despite coming up with some cunning engineering solutions. Adobe so far seems to be hoping that user pressure from desire for Flash on mobile will solve some of these issues for them, rather than provide any solid technical solutions.

This is was a long, and somewhat Adobe negative entry. However, for the record, I like Flash. My job involves creating wonderful things with Flash. It is with vim and finesse Flash allows me to do this. Flash has changed the face of the Desktop Experience by allowing non computer science people into the geek ridden programming club, and it has changed it for the better, in my opinion.

However, I have to agree with Aral to a large extent. Adobe are drunk on success. This is very dangerous. The clear speed of development advantages offered by Flash are diminishing. JavaScript in browsers now provide enough scripting power to replace Flash in a great many RIA areas, and unlike Adobe's laughable claim that Flash is a de facto standard, JavaScript actually is a de facto standard. Flash still reigns supreme in the browser game arena, but even here it is under attack from the hugely impressive Unity3D framework. AIR has no clear challenger, but it also has no broad adoption either, despite it's excellent selling points for desktop application development. In a future where GoogleOS controls your life and your choice of applications, AIR may become irrelevant.

It's a tough future, but I hope Adobe sip some strong coffee, awaken from their reverie, and stride confidently through it. It's not too late for them… Yet.

Almost a new year, so that must make it time for a new blog. I'll see how well this one fares*.

[* Erm. Ok. I just notice that I had misspelled this word. That's a bit embarrassing.]