/Word stream

Something occurred to me one of these days. There’s something I’ve been doing for quite a while, but I’ve never discussed it with anybody else. I’m sure it all makes sense, somehow, or that there’s some better way to describe it – perhaps it has some fancy design pattern name – but for the sake of clarity and future linking, I decided to write about it. I also haven’t been talking about actual code for a while, so here it goes. It’s a big long-winded.

When creating custom objects with ActionScript, it’s pretty common to add some state variables to their classes. For example, suppose we have a FancyButton class, and we want to give developers the ability to disable or enable the button. Normally, we’d create the interface like this:

// Enables the button
myFancyButton.enabled = true;

// Disables the button
myFancyButton.enabled = false;

Then, inside the class, we’d just have a property, something like this:

class FancyButton extends Sprite {

	public var enabled:Boolean;

	function FancyButton() {
		enabled = true; // Enabled by default
	}

	(...other code...)

}

Then, when needed, the code inside the button would check for the value of enabled, and react accordingly – say, allowing the user to click it or not.

Of course, when we’re feeling fancy, we might as well transform it into a getter/setter property, and add functionality to when the property is changed. Like so:

class FancyButton extends Sprite {

	protected var _enabled:Boolean; // Actual value

	function FancyButton() {
		enabled = true; // Enabled by default
	}

	(...other code...)

	public function get enabled(): Boolean {
		return _enabled;
	}

	public function set enabled(__value:Boolean): void {
		_enabled = __value;
		alpha = _enabled ? 1 : 0.5;
	}

}

This allows the class to run whatever code we want once the value is changed – like maybe making the button semi-transparent when disabled, or fully visible otherwise (this is what the code above is doing). This is nothing fancy, basic ActionScript/OOP coding, but sets the context of my post.

Let me open another topic here first. I’ve always played a first-person shooter game called QuakeWorld, a multiplayer-only version of the classical game Quake. QuakeWorld is known for having many options you can change with the console, making the game pretty customizable, at least when compared to most first-person shooters. For example: when playing the game, you view your own weapon on screen, but if you want, you can make it invisible with the console command r_drawviewmodel 0 (so you get more screen space). Setting it to 1 will make it visible, as default. This value is a boolean, represented by a number.

Some years ago, I started using FuhQuake as my main QuakeWorld client (there are several different QuakeWorld clients). It turns out that in FuhQuake, many of the “boolean” console configuration variables (cvars) can be represented as numbers, instead of booleans. This means that, for r_drawviewmodel, 0 is still invisible, and 1 is still visible, but 0.5 means 50% opacity.

At the time, the idea struck me as pretty odd but quite ingenious – after all, I actually prefer to have my weapon on screen (so I could know which weapon was selected) but I also wanted to see what was beneath it, as the weapons tend to occupy some pretty large portion of the screen. As such, I use a r_drawviewmodel value of 0.3 on my QuakeWorld config file.

Almost without thinking, I adopted this same idea in most of the code I write. This means that, instead of my FancyButton have an enabled property which is a Boolean, it’s actually a Number that can go from 0 to 1 – 0 meaning disabled, 1 meaning enabled, and all values in between meaning whatever I want them to mean – say, disabled. The functionality, internally, looks the same.

class FancyButton extends Sprite {

	protected var _enabled:Number; // Actual value

	function FancyButton() {
		enabled = 1; // Enabled by default
	}

	(...other code...)

	public function get enabled(): Number {
		return _enabled;
	}

	public function set enabled(__value:Number): void {
		_enabled = __value;
		alpha = _enabled == 1 ? 1 : 0;
	}

}

What changes the most is when the Class code checks for whether the button’s enabled or not – and, of course, references to the enabled property of the instance would be slightly different, like so:

// Enables the button
myFancyButton.enabled = 1;

// Disables the button
myFancyButton.enabled = 0;

Well, why bother with this change then? It turns out that when I need to work with Flash, it’s pretty common that I have to smoothly change the state of an object – like enabling and disabling a button. With a numeric property, I can make the state value be the transition, and then have more control over a button state – either changing it with an animation, or changing it immediately when needed. For example, to make sure the enabled property changes the visible state of my button smoothly, the correct class’ property’s set function would be something like this:

class FancyButton extends Sprite {

	(...)

	public function set enabled(__value:Number): void {
		_enabled = __value;
		// Alpha goes from 0.5 to 1 as _enabled goes from 0 to 1
		alpha = 0.5 + _enabled * 0.5;
	}

}

(This is not something that would be used every time, of course. In many cases, having have a hard, Boolean property is fine, then you can do the animation transition inside the set function as necessary, and actually avoid the Class user’s the hassle of tweening anything. But this is an specific case that applies to the enabled state of a button – which is just a simpler example I used to illustrate my point – so please bear with me while I continue).

As it turns out, there are a number of advantages in using numbers to control the state of an object, instead of using Booleans.

Take, for instance, the rollover state of a button. Consider a simple, semi-transparent button, that becomes fully visible during rollover. It’s quite common that such functionality will look like this:

class FancyButton extends Sprite {

	function FancyButton() {
		addEventListener(MouseEvent.ROLL_OVER, onRollOver);
		addEventListener(MouseEvent.ROLL_OUT, onRollOut);
		alpha = 0.5;
	}

	public function onRollOver(e:MouseEvent): void {
		alpha = 1;
	}

	public function onRollOut(e:MouseEvent): void {
		alpha = 0.5;
	}

}

Or, of course, you can use some tween for that, so it’ll have a nifty animation when rolled over (some pseudo-code):

import com.somepackage.SomeTweenEngine;

class FancyButton extends Sprite {

	function FancyButton() {
		addEventListener(MouseEvent.ROLL_OVER, onRollOver);
		addEventListener(MouseEvent.ROLL_OUT, onRollOut);
		alpha = 0.5;
	}

	public function onRollOver(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {alpha:1, time:0.4});
	}

	public function onRollOut(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {alpha:0.5, time:0.4});
	}

}

All fine and dandy. Suppose, however, you want to add more features to your button. Say, for instance, your non-focused button will be a bit blurred, and have a little glow when rolled over. It could look like this:

import com.somepackage.SomeTweenEngine;

class FancyButton extends Sprite {

	function FancyButton() {
		addEventListener(MouseEvent.ROLL_OVER, onRollOver);
		addEventListener(MouseEvent.ROLL_OUT, onRollOut);
		alpha = 0.5;
	}

	public function onRollOver(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {alpha:1, time:0.4});
		SomeTweenEngine.doTween(this, {glow:3, color:0xff0000, time:0.4});
		SomeTweenEngine.doTween(this, {blur:0, time:0.4});
	}

	public function onRollOut(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {alpha:0.5, time:0.4});
		SomeTweenEngine.doTween(this, {glow:0, color:0xff0000, time:0.4});
		SomeTweenEngine.doTween(this, {blur:4, time:0.4});
	}

}

That is, considering your tweening engine already supports “shortcuts” for filter tweening, and that they’re initialized (if needed).

Still, this code poses a problem. How do you set the initial state of the Button as unfocused? You’d either need to duplicate the tweenings functionality, call onRollOut (it would animate the object to the desired state however), or create a function that moves the object between states with a customizable time. This is something I’ve been doing previously, and it looks like so:

import com.somepackage.SomeTweenEngine;

class FancyButton extends Sprite {

	function FancyButton() {
		addEventListener(MouseEvent.ROLL_OVER, onRollOver);
		addEventListener(MouseEvent.ROLL_OUT, onRollOut);
		setStateNormal();
	}

	public function get onRollOver(e:MouseEvent): void {
		setStateFocused(0.4);
	}

	public function set onRollOut(e:MouseEvent): void {
		setStateNormal(0.4);
	}

	protected function setStateNormal(__time:Number = 0): void {
		SomeTweenEngine.doTween(this, {alpha:0.5, time:__time});
		SomeTweenEngine.doTween(this, {glow:0, color:0xff0000, time:__time});
		SomeTweenEngine.doTween(this, {blur:4, time:__time});
	}

	protected function setStateFocused(__time:Number = 0): void {
		SomeTweenEngine.doTween(this, {alpha:1, time:__time});
		SomeTweenEngine.doTween(this, {glow:3, color:0xff0000, time:__time});
		SomeTweenEngine.doTween(this, {blur:0, time:__time});
	}
}

This works great. However, there are two questions still raised – what if I want to control my state from outside, and what if I want to do something that isn’t normally supported by the tweening engine? The former would require all my external code to “know” what properties are changed, or for the setState* methods to be public; the latter would get me stuck.

Enter state variables. With state variables, you can control the tween the actual state the button is, and then just apply the state to the object. The above class would work like so:

class FancyButton extends Sprite {

	protected var _mouseFocused:Number; // Actual value

	function FancyButton() {
		addEventListener(MouseEvent.ROLL_OVER, onRollOver);
		addEventListener(MouseEvent.ROLL_OUT, onRollOut);
		mouseFocused = 0; // Normal by default
	}

	public function onRollOver(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {mouseFocused:1, time:0.4});
	}

	public function onRollOut(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {mouseFocused:0, time:0.4});
	}

	// Getter/setters

	public function get mouseFocused(): Number {
		return _mouseFocused;
	}

	public function set mouseFocused(__value:Number): void {
		_mouseFocused = __value;
		// Applies the focus value
		alpha = 0.5 + _mouseFocused* 0.5;
		filters = [
			new BlurFilter((1-_mouseFocused) * 4, (1-_mouseFocused) * 4),
			new GlowFilter(0xff0000, 1, _mouseFocused * 3, _mouseFocused * 3)
		];
	}

}

“But Zeh”, I can hear people say, “this looks a lot more complicated. Why would I even want to use this crap?”

If you just said or thought so, then you’re right that it looks more complicated. However, I personally like to think that this approach is the cleanest in the sense that it allows me to set the state of an object to be whatever I want it to be, from the class itself or from outside of it, without having to deal with the actual property values; I don’t need the tweening class to actually support anything other than basic tweening, or to learn a new “shortcut” API in addition to standard DisplayObject features like filters, avoiding redundancy; and additionally, one of the most important aspects of this approach is that you can stack state properties and make the object react accordingly. Suppose, for example, that our FancyButton can also be disabled in addition to being focused; this would cut its opacity in half. Doing this with normal alpha tweening would be a big problem, because you’d need to check all the Boolean states of an object before determining what the target value should be. With numeric states, this would look like so:

class FancyButton extends Sprite {

	protected var _mouseFocused:Number;
	protected var _enabled:Number;

	function FancyButton() {
		addEventListener(MouseEvent.ROLL_OVER, onRollOver);
		addEventListener(MouseEvent.ROLL_OUT, onRollOut);
		mouseFocused = 0;
		enabled = 1;
	}

	// State redrawing

	public function redrawState(): void {
		// Applies the focus value
		alpha = ((0.5 + _mouseFocused * 0.5) + (0.5 + _enabled * 0.5))/2;
		filters = [
			new BlurFilter((1-_mouseFocused) * 4, (1-_mouseFocused) * 4),
			new GlowFilter(0xff0000, 1, _mouseFocused * 3, _mouseFocused * 3)
		];
	}

	// Events

	public function onRollOver(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {mouseFocused:1, time:0.4});
	}

	public function onRollOut(e:MouseEvent): void {
		SomeTweenEngine.doTween(this, {mouseFocused:0, time:0.4});
	}

	// Getter/setters

	public function get mouseFocused(): Number {
		return _mouseFocused;
	}

	public function set mouseFocused(__value:Number): void {
		_mouseFocused = __value;
		redrawState();
	}

	public function get enabled(): Number {
		return _enabled;
	}

	public function set enabled(__value:Number): void {
		_enabled = __value;
		redrawState();
	}

}

In the above code, the alpha of a fully focused and enabled button would be 1; a focused but not enabled button, as well as an enabled but not focused button, would have an alpha of 0.75; and a button that’s neither enabled nor focused would have an alpha of 0.5. That’s because they’re stacking – if I was simply changing the values themselves depending on the change of a property, I’d risk overwriting one animation with another, or ending up with the wrong value.

This may not sound like much, because, again, the focused/enabled button is a simple example. But if you take the idea and apply it to some of the most common visible objects you have to create in Flash, I believe you’ll find it quite useful. Or, well, at least I do.

Here’s another example that may illustrate why state control is better than direct property control. Suppose you have a box that you want to go from the left side of the screen to the right side of the screen in 3 seconds. Something like this:

myBox.x =  0;
SomeTweenEngine.doTween(myBox, {x:stage.stageWidth, time:0.6});

This will work. However, suppose the screen is resized during the animation, and you’re using a stage scaleMode of NO_SCALE (variable width). What to do?

Most people will say the normal solution is to interrupt the tween, setting a new goal. Or, maybe, if your tweening solution allows tweening references, you could just save the reference and change the target value. Something like this, in pseudo-code:

myBox.x =  0;
myTween = SomeTweenEngine.doTween(myBox, {x:stage.stageWidth, time:0.6});
stage.addEventListener(Event.RESIZE, onResizeScreen);

public function onResizeScreen(e:Event): void {
	if (Boolean(myTween) && myTween.isActive) {
		myTween.x = stage.stageWidth;
	}
}

This may work, but creating an exception to that opens up a big can of worms – every kind of animation that depends on a value that can change depending on the screen size will need a similar event. And that’s even considering you can save tweening references and change them later. For engines that don’t allow that – my own Tweener, for example, doesn’t unless yo hack its code – actually stopping and recreating tweenings is a much worse solution.

This (nice) animation is a good real-world example of that problem. It employs no resize detection during tweening – if you click to go to the next or previous slide, and resize your browser during the tweening, the final state won’t make a lot of sense – the slide will have the wrong position and scale, instead of being fully centered.

In cases like this, a solution would be to add an state property to the object – in the previous box example, an alignment property would probably make some sense, if you consider -1 to be full left alignment, and 1, full right alignment. The interface could work like this:

myBox.alignment = -1;
SomeTweenEngine.doTween(myBox, {alignment:1, time:0.6});

Then the code for myBox – which would render the x property useless, unless you extend and overwrite it to have some additional functionality – would look like this:

class MyFancyBox extends Sprite {

	protected var _alignment:Number = 0; // Default is centered

	(...class code...)
	// Getter/setters

	public function get alignment(): Number {
		return _alignment;
	}
	public function set alignment(__value:Number): Void {
		_alignment = __value;
		x = ((_alignment + 1)/2) * stage.stageWidth;
	}

}

Obviously, that’s some pseudo-code, with just the basic idea – to move the object to a new position but always based on the stage width. A final class could be properly constructed to, say, take the object’s width in consideration, allow x to work as an offset value (in addition to alignment), etc. The basic point, however, is that by adding a state property via a getter/setter, you don’t have to worry about exceptional behavior – like a window resize – anymore. Instead, you just take them into consideration when applying the state to the object.

And while I do use the focus/enabled functionality quite often, here’s a real, more useful example. I was creating an animation that should contain some text. This text must come into view with a fancy vertical blur effect (like a motion blur), and go away in the same way. I could have done it like this:

// Show
SomeTweenEngine.doTween(myText, {blurX:4, time:1});
SomeTweenEngine.doTween(myText, {alpha:1, time:1, onStart:function() { this.visible = true; }});

// Hide
SomeTweenEngine.doTween(myText, {blurX:0, time:1});
SomeTweenEngine.doTween(myText, {alpha:0, time:1, onComplete:function() { this.visible = false; }});

(And, of course, I could also employ some autoAlpha functionality, if the engine supported it, to automatically make it invisible)

Sure, it looks and works fine, but what if I want to use that on several different places, and what if I want to change the amount of blur it’s applied later? I need to hunt down everywhere I have the tweening start and change the code, or create a function to show and hide this object.

The solution I’ve chosen, instead, is to have a visibility property that applies directly to how I want my object to show and hide every time. Its interface works like so:

// Show
SomeTweenEngine.doTween(myText, {visibility:1, time:1});

// Hide
SomeTweenEngine.doTween(myText, {visibility:0, time:1});

And then, inside the code, of course, I have the appropriate getter/setter code, and state update function:

(...class code...)

// State redrawing

private function redraw(): Void {
	if (visibility > 0) {
		_alpha = _visibility;
		_visible = true;
		filters = _visibility == 1 ? [] : [new BlurFilter((1-_visibility) * 64, 1-_visibility, 2)];
	} else {
		_visible = false;
		filters = [];
	}
}

// Getter/setters

public function get visibility(): Number {
	return _visibility;
}

public function set visibility(__value:Number): Void {
	if (_visibility != __value) {
		_visibility = __value;
		redraw();
	}
}

(...class code...)

This is actual code used on some recent work I’ve done. And again, this might looks like more code, but I like to believe it’s actually less – you only write the functionality once, inside your class, then reuse when needed. You can then work on the object’s state whenever you please, and not worry about tweening support.

This may sound sort of crazy since I’ve gone out of my way to add a lot of (optional) shortcuts to Tweener. But the truth is, I haven’t been using those for a long, long time. While they may make your life easier when you need some quick functionality – say, autoAlpha and such – trying to use a tweening extension to control way too many features (specially features that are not directly available as a direct property) is a recipe for disaster. Nowadays, I like having a cleaner, tweening-independent solution, and honestly it has been working very well for even the most complex cases.

Finally, the above alternative is not a silver bullet, as it adds a few problems by itself – on the previous FancyButton class example, trying to tween both enabled and mouseFocused at the same time would cause redrawState() to be called twice per frame (see this for an explanation on the solution). But still, I think the advantages far outweight the disadvantages.

Last year I finally delved head-first into the wonderful world of Processing. It was one of those (many) times I could college as an excuse that allowed me to spend some more serious time with something that wasn’t directly related to what I do on my day-to-day work. I used the time to create some small experiments to learn the platform, and to help some colleagues with their Processing-based graduation projects – that is, never creating something final, or by myself, other than random experiments.

That’s why when the São Paulo-based band Omega Code started their open poster contest I knew that, instead of using normal illustration editors, I wanted create an entry using Processing. Additionally, my previous experiments were all based in video or real-time functionality, so creating a poster – static, high-res – would be great for a change.

The first idea that popped in my mind when I thought about what I wanted to build was that I didn’t want to use any kind of external asset; so no image composition or anything, I’d do it all with typography.

I did have to use one image, however. I created a black&white version of their template document, which contains the band logo, to serve as a guide of sorts for my poster.

Omega Code poster template

Basically, this logo is used as a map for where I want to have different colors.

The second idea was what to use. Now, I’m an atheist, but I know from Xenogears Fallout 3 that the whole “Omega” thing comes from The Book of Revelations, and I figured the text of that chapter of The New Testament would fit the poster (and the overall concept of the contest) well.

I went to look for the Biblical text and, thankfully, there’s no shortage of Bible-based content on the web. More precisely, I found this website which contains the full text of all chapters from the Christian Bible, including the one I wanted, the Book of Revelations. And what’s best – in its original language.

The one I wanted was written in Greek, however. That poses a problem, since most fonts – including general use fonts like Arial – do not include the glyphs needed for proper Greek rendering. So it was with a big surprise that I found Gentium, a font made specially for Greek rendering – and with a free license to boot – that I could use for the poster. It looks beautiful, too.

With the ingredients ready, I went on to create the poster by writing Processing code.

As strange as this sounds, the most difficult part was actually getting the text rendering to work.

I created a text file containing the entire Book of Revelations, and created a quick sketch that could read random words from it and render those to the sketch area. The problem wasn’t in reading this text file, or getting UTF-8 based strings to read and write properly. The real problem was with getting them to render correctly at the sizes I wanted. This is because processing renders text as images, as is the norm with platforms that are meant for realtime graphics. That is to say, you have to generate raster image “tables” from true type files, posing a problem with quality: too big of a text, and it’d be blurred; too small, and it’d look awful.

Of course, I could generate different font files, one of each size of the funt, but since I wanted to use all kinds of text from size 5 to 300, this wasn’t entirely feasible.

The first thing I tried was to find some Processing library that used text as vector data – meaning it could work like, say, Flash, where you can scale text to your heart’s content without worries about quality. This proved a big problem, however, as the two such libraries I tested had problems of their own – incompatibilities with the Processing version I was using, I suppose.

In the end, I gave up on trying to use different libraries and went back to Processing’s original font support. I ended up doing something absolutely awful – regenerating the font table to memory every time the font size changes. Since this was all meant for a high resolution, non-realtime poster, it served its purpose well, but it was really slow. I started caching the fonts for each size after a while (at the expense of a lot of memory) and restricted the available font sizes to 50 variants, and this made things faster, but still this wouldn’t be possible for realtime text rendering.

With all set on the text rendering features, I went on to creating the actual poster. The first thing I did was write the start of the chapter on the background, as some simple, running text. This was meant to give some texture to the poster’s background.

Then I made the sketch read random points from the “template” map (the one in black and white). If the result was a black point, it’d paint a random word on that same position on the final image. The result was as such:

This worked, but it wasn’t really what I wanted yet. I wanted something a bit more random, to give it more texture, even if always type-based. I made it randomize the size of the text as well too, and made it so that if the source background was white, the stamped text would be a very transparent black instead of simply ignoring that point. This was the result:

Still not quite what I wanted, I made the algorithm check the template image to find the brightest color from the entire square that the new word would occupy (instead of just the center point). Now, I’m the first to admit this was done in a very dumb way – it runs the entire perimeter of the text bounding box, checking for the color of each pixel – but it served its purpose well, and heck, this was for a non-realtime sketch, I could afford to be optimization-challenged.

After implementing the box color checking feature, this was the result:

After solving a few problems that would get the random font sizes to get stuck in the same size forever, I decided to add some more features to the background. For a first pass, instead of being fully white, the further from the band symbol’s center the new word was, the darker it would become – this would give the impression of a white glow around the band’s symbol. After running the sketch for a long time – it added a few words every frame – this was the result:

Despite having way too much solid gray, that was almost the result I wanted. Next, I added some better pattern to the background, by making the text color actually vary depending on its angle from the symbol’s center, creating the impression of rays coming out of the symbol. This was the result, still in grayscale:

Finally I added some color to it. I didn’t really want to make it too colorful, and after testing with the above image in Photoshop for a while, I came up with a combination that gave it the impression I wanted, of some sort of thing that’s coming out of an old book or printed on an old paper.

The above image also shows a slightly different color detetion algorithm, as I made the text color detection a bit erratic (by using a smaller color selection rectangle). This was meant to make the logo look tighter, even at the expense of the precision of its forms. This is subtle, but I think it looks a lot better.

The final step was generating the image to be used. This image was supposed to be pretty big; thankfully, I build the sketch in way that it’s based on a global scale variable, so while the tests above were ran on a smaller version, I could simply change the scale and let it run to create the final image.

Like I said, the sketch generates the final poster by adding new words to it on every frame. The sketch adds 5 new words on every frame rendered, and runs the sketch for 20,000 frames (because I found the ideal result with 100,000 words randomly placed). But since it’s manipulating a image with dimensions of 2953 x 4185 pixels, it’s a rather slow process – the final image took almost 3 hours to be generated (see this video to understand how it works).

And heck, there’s even a Twitter log with more test images if you want to see them, as I was posting to it while I was working on the final poster.

The final result is pretty simple, visually speaking, but I think it solves the concept well. And while it uses an image as its base, it’s still entirely based around typography, as even the background patterns are created by adding a lot of text with low opacity, so I think it responds well to this self-imposed restriction too.

For more information about the poster, see all fan-made entries to Omega Code’s poster contest, including the above one. The contest goes until March 31, and everybody can send their entries. You can also see the original posters, made by several renowned designers.

This entire post was made because I wanted to explain what the poster contains, and specially because I wanted to make the Processing source code available: download it here. It includes all assets used (font file, image map, and source text file). You’ll obviously need Processing to run it.

Caveat: the above is exactly what I used, and I did try a lot of different things during the development process, so it’s a very non-optimized, non-cleaned up code. There’s a lot of strange things there, like old lines and functions that are commented out, some rather confusing equations, it only uses one class, and all that kind of stuff that a coder does when he’s writing for himself. But it works: press space to hide/show the final result, or S to save the image. It also saves the image automatically every 1,000 frames (or 5,000 words). And feel free to make new entries to Omega Code’s contest based on it if you so want, or of course, create entirely new submissions.

Interesting link for people interested in interpolation and tweening, with Flash/ActionScript or otherwise: Interpolation Tricks by Jari Komppa. An award-winning Demo coder, he explains concepts related to programmatic animation from a different perspective – he never mentions Robert Penner’s easing equations, but at the same time he’s talking about the same thing, even if using different equations. And, of course, it’s nice to find someone explain the beauty of the 0..1 range so didactically, so I think it’s some great reading.

Adobe has finally updated their Flash Player Version Penetration statistics page with details for December 2008, and things are looking good. Just how good? Well, basically, Flash 10 has enjoyed the fastest adoption rate of Flash since it has been introduced, having now a 55.9% penetration on mature markets roughly two months after it has been released.

I’m actually quite surprised that my own prediction of 90% penetration in 6 months for Flash 10 – previously it would take one year for Flash to reach that mark – seems more realistic now. That, coupled with other recently announced numbers like 100 million Adobe AIR installations and a reported 80% market share on online videos, make the future look pretty bright for the Flash platform.

And let’s not forget the fact that, even with current penetration numbers aside, the adoption rate of a certain competing technology is vastly inferior to Flash’s (click on “Line” to see how each different version of each platform has been performing, then compare Flash 10 and SilverLight 2); while SilverLight is obviously gaining some penetration, it seems sponsoring certain exclusive online video offerings isn’t doing as much to the platform as one would think it would.

Finally, strangely enough, Flash Player 9.0.115 (the first to include h.264 video support and some other features like hardware scaling of fullscreen content) is not featured on the official penetration statistics anymore, and even the old numbers have been removed from the tables. I guess that’ll become irrelevant pretty fast – it already was at 90% on september – but historically, it’d make sense to still list them there.

Notes: the above graphic was created with data gathered from past updates of the Flash penetration statistics pages. You can access the full data set here (or click the image) – it also includes a chronological graphic. Some version lines start with a penetration rate higher than 0% at month 0 because it has been released the same month the statistical data was gathered. Due to this, consider some error margin translation of around 15 days (left or right) for each line.

FlashTerm, Peter Nitsch’s ActionScript Telnet client, has just gone live. It works with a sample BBS, and it’s a great example of what’s possible with AS3ANSI, his AS3-based ANSI parsing library. Read Peter’s blog for more information.

This week I’ll be working from Campus Party, so for the curious, I’ll be doing small twitter updates (mostly in Brazilian Portuguese) from there. I won’t do any kind of live coverage or public reporting or anything, since I’ll be there mostly to see friends (in the Games area) though, but if anyone else is also attending: see you there.

When I went back to college, 4 years ago, most of my peers thought the decision was commendable but kind of crazy – I had already been working for 11 years in the interface development field, and people who hired me couldn’t care less if I had a degree or not; not that it wouldn’t be a good thing to have, but that my experience with the technologies used more than made up for it. When I told people I was going to college, their response wasn’t “Nice!” or “Congratulations!”, but “Why?”.

At this point it may sound like I’m going to say “they thought wrong!”. Not really. They were right, it was a bit crazy to do it.

Still, going to college and successfully getting a degree was something I’ve always wanted to do, and I guess that desire was heightened by the fact that I never had the resources – both money and time – to do it, and when I finally managed to save enough money and make a flexible schedule possible for me, I embraced it and went to get a bachelor in Digital Interface Design.

I started without a lot of expectations; maybe gathering some theoretical knowledge, getting a diploma at the end, and having the confidence that I could stand something for a long time if I focused myself on it (I had started college before, but stopped halfway through it).

What I ended up with was so much more, however.

What was interesting, I guess, is having different lines of thought, or different situations, to put yourself into. My work is highly technical, and I like to believe I do my work well, but once I was in college, I had to put myself into tasks that weren’t really the tasks I was used to, like research and analysis of knowledge not directly related to my work. I went there sort of expecting to know it all, but was taken aback by the amount of interesting new stuff I had to deal with – even if they weren’t exactly new.

That also included technologies that aren’t, again, directly related to my work – if I hadn’t gone to college, I probably wouldn’t have yet learned of Max/MSP/Jitter and vvvv, and wouldn’t be hypnotized by the easiness with which their visual programming approach allows anyone to create rich interactive graphics. It’s no surprise I was so inspired by those programs that I even built a similar environment for my thesis project, and that alone would be reason enough to say that going to college was worth it.

And in the sense of doing different stuff, going to college also gave me the chance to go and teach some classes (Flash, Flash Lite, and Processing), something I was quite sure I would never do in my life. As all the rest, it was an amazing learning experience and something I’ll hopefully repeat in the feature.

And there were the people.

Now,  I don’t consider myself a recluse in any way. I like to believe I work well with groups of people, both in the workplace or otherwise. But going back to college was a kind of a surreal experience. My colleagues were on average 10 years younger than me, something that may not sound like a lot but that makes a huge difference when you’re talking about people still on their teenage years, so we had some differences to work with; I had to refrain myself from not saying “in my time…” too often, as some of the differences were enormous – no Internet when I was a kid! Phone lines were a lot more expensive! No cellphones or digital cameras! – but still, dealing with them, and watching them grow as people, was nothing short of extraordinary. I’ve seen people complaining that young people nowadays have everything at their feet but still are lazy as fuck, and I’ve done my share of bitching, but in all honesty, comparing some of my fellow students with the mindset I had when I was their age, they’re far ahead and bound for a bright future. Working with them was nothing short of a lesson about people and even about myself; I believe I’m a much person now than I was 4 years ago. I miss them already.

Truth is, going back to college so late for me was a bless in disguise. Going there with a lot of practical knowledge, even if with a lot more still left to learn, gave me the ability to understand so much better what teachers had to say. It was often that I would leave class with the perception that I had realized something extremely important about the world, or something that I had to read a lot more about; and yet, not all of my colleagues shared the same feeling. Not because they were stupid in any way, but because many times they lacked the contextual knowledge needed to properly understand what was being said.

I’ve always been of the opinion that going to college isn’t something of ultimate importance (that’s a sort of a big discussion around here) and, in some ways, I’m still like that; you can learn a lot, specially gather a lot more practical skills, doing real work instead of sitting somewhere with someone babbling over your ears, and I certainly would never have a problem hiring someone without a college degree. However, going to college at some point in time is something I now see as extremely positive, and something I strongly recommend to anyone – but only if you allow yourself to bask in its mind-shifting soup. It’s too easy to just go there and get a grade that’s good enough to carry you on to the next semester, I suppose, but then you’ll be going there just for a diploma.

With that stage bittersweetly out of the way, I can finally move on. That’s not to say I’ll be allowed to slack so soon – as I mentioned earlier, I’m working for Firstborn, and now that college obligations are over, I’ll be moving to NY to work with them. This means I have to spend holidays writing documents for the visa process – which is cool, though, as they’ve always been specially patient with me, and I’m really glad of the work I’ve done for them for the past year or so. So, thanks Francis, Dan, Michael, Luba, Avery, Wes, Will, Izaías, Joon, Jennifer, Maria, Ryan, Eric, Lauren, Takahashi, and Max, and everybody else, Firstborners and former Firstborners; it’s over now, and I’ll hopefully see you guys soon.

Also, while I’m at it, many thanks to the fine people at Grafikonstruct and Gringo, as this college plan wouldn’t have been possible (or would have been a lot more difficult) without their partnership and support.

Looking for a change of pace, living in one the craziest cities in the world with some extremely creative people who drink a lot and like to swear like drunk scotsmen? Or maybe you already fit into that description and you’re just waiting for the authorization to enter the building? Here’s your chance, Gringo is now looking for a senior Flash/Actionscript developer and they mention relocation is OK. Find more information about the ideal candidate here.

Top-level Brazilian agency Gringo is looking for a SilverLight developer. Gringo is located in São Paulo, Brazil, and this is for an on-site role. Details follow (in Brazilian Portuguese).

Enfim, a Gringo precisa de um profissional SilverLight pra se juntar à sua equipe supercompetente de desenvolvedores. O candidato ideal irá trampar a princípio de agora até março na Gringo, desenvolvendo um projeto bem bacana. Valores são negociáveis, e é imprescindível que o profissional cumpra prazos e toque o projeto sem maiores surpresas.

Quem estiver interessado, favor contactar Mylena Mandolesi no email mylena (arroba) gringo.nu.

Acho que não preciso nem falar nisso, mas a Gringo é uma agência que mais do que recomendo a qualquer um. Pra quem curte SilverLight, esta é uma puta oportunidade de trabalhar com uma equipe extremamente criativa e competente.

For what’s it worth: I’ll be giving an (online) talk about ActionScript development in Brazil December 18 (next thursday), at 22hs local time, courtesy of the Adobe User Group for Rio Grande do Sul (AUGRS). This talk will be in Brazilian Portuguese only, and it’s aimed at people who want to know more about the Actionscript development field; I’ll be talking about my experience in the area, as well as how I see it working for other people. It’s not overly technical, but I’ll be talking a bit about the tools developers have available; it’s not overly personal, but I’ll be showing some of my work to illustrate my points and talking a bit about my experience to put things into context. Find more information about the event (including link to the presentation room) here.

The presentation will also be recorded and available later, as well as all material involved.

Update: the starting time has changed, and it’s now set as 22hs instead of 21hs. Sorry for that.

Update (2): the talk was recorded and is now available online. It lasts for around 1 hour for the main presentation, and another 45 minutes for questions. Thanks to everybody who attended! The turnout and the result was better than I expected.