https://docs.google.com/spreadsheet/ccc?key=0As9k6GLAYjwpdDNGMFZFanRweXFlRV9mUGlPeVBNSVE

I will not be discussing the pros/cons of a Spark skin containing “awareness” of its host component’s properties.  That falls into a more in-depth “best practices” discussion to be discussed at a later time.

[note to self]

One way to propagate changes from the SkinnableComponent to the Skin and still leverage the Flex framework’s invalidation mechanisms is to simply update your property and then call invalidateDisplayList.  Override your updateDisplayList call in the Skin and fetch the needed values.  For this example the particular skin I was creating needed to create a mask whose width was based on a particular value.  Seeing as this logic was particular to the skin, I decided to move the logic into the skin rather than the component itself.

hostComponent code

public function set volume(value:Number):void
{
	if (value != _volume)
	{
		_volume = value;
		_volValue = _volume < 0 ? 0 : _volume > 1 ? 1 : _volume; //limit betw 0 & 1

		bVolumeChanged = true;

		invalidateProperties();

                if (skin)
                {
                            skin.invalidateProperties();
                            skin.invalidateDisplayList();
                }
	}
}

rather than:

var foo:Object = function ():Object
{
   var o:Object = {};
   o.id = "foo";
   o.data = Math.random();

   return o;
}; //will fail with a CTE cannot coerce function to object

you need only add this:

var foo:Object = function ():Object { .... }(); //will succeed  

What’s going on here? Well the first will fail giving you a CTE (compile-time error) stating that you are implicitly coercing a function to an object.  And that’s true, you have in no way actually called the anonymous function in the first example.  Rather you have DECLARED it.

The second bit of code is still declaring/defining the function however you are immediately calling said function afterward.

Not necessarily a best practice but a good trick to add to your bag o’ tricks.  Thanks to Nicola Bortignon (http://www.nicolabortignon.com/) for showing me this.

You can’t simply set the text of an MXML declared Spark Label like below and expect linebreak or carriage returns to work:

<s:Label text="this is where I desire my line break to be\nnow the second line begins....."
         maxDisplayedLine="2"/>

You now have to explicitly wrap the linebreak or carriage return in binding brackets and single quotes like so:

<s:Label text="this is where I desire my line break to be{'\n'}now the second line begins....."
         maxDisplayedLine="2" 
         lineBreak="explicit"/>

tell application "iTunes"
	quit
end tell

tell application "Finder"
	if (exists the disk "Mobile HD") then
		eject "Mobile HD"
	end if
end tell

history

Right now I am working on as3isolib.v2.r05 (yes that’s right revision number 5).  One thing I wanted to do in this revision was to totally strip the rendering logic of any unnecessary calculations.  r04 had something on the order of 600+ lines of code just to parse a single object.  While it was super fast, it still suffered from redundant calculations.  After much mulling around on the mathematics and formulas, I decide that that particular logic could be streamlined to about 100-150 lines of code.  But I wanted to do make sure I tested each formula so that I didn’t have to guess when a problem might popup.

in depth

So unit testing really doesn’t deal with visual testing so much as it deals with testing of data and logic.  For instance, does method foo return an expected response based on a certain input.  Well that is a rather simplistic example but you get the idea.  One thing I was really psyched to get into were the declarative APIs of the Hamcrest libs in FlexUnit.   The API is pretty darn simple:

var expected:Array = [ 0, 1, 2, 3 ];
var result:Array = [ 0, 1, 2, 3 ];
assertThat( result, equalTo( expected )); //pass  

Simple!

the problem

Hamcrest provides plenty of APIs for testing Arrays of simple objects to other Arrays of simple objects.  It also provides APIs for object comparison in some limited fashions.  What I didn’t see in the docs or examples was a way to compare a collection value objects against another collection of value objects:

//assume the following are a custom value object of type FooVO
var expected:Array = [ objA0, objB0, objC0 ];
//assume the following have the same values as the above (clones essentially)
var  results:Array = [ objA1, objB1, objC1 ];
assertThat( results, equalTo( expected ));  //didn't seem to work  

the pro tempore solution

So the work around I did was to implement a toString() method on the value objects:

public function toString():String
{
    var a:Array = [];
    a.push( "propA:" + propA );
    a.push( "propB:" + propB );
    a.push( ....... );

    return a.toString();
}

And then we need to get our collection of objects to spit out a long string to compare:

var data:Array = [ 0, 1, 2, 3 ];
var expected:String = "";
for each (var o:Object in data )
    expected += o.toString() + "\n";

var input:Array = [ 0, 1, 2, 3 ];
var result:String = "";
for each (o in input)
    result += o.toString() + "\n";

assertThat( result, equalTo( expected )); //pass  

So it works for me.  But if you have any suggestions or want to point out a hidden API in Hamcrest or FlexUnit, please let me know.  In the meantime I think this works in most cases where you have simple data objects to test against.

character selection

You have 4 characters (that I know of) to select from.   I’m not sure if this is the European influence or what but it reeks of political correctness.  Seriously! You get your typical 4 character types: An overall well rounded character (the ex-football Texan), the blades & martial arts expert (that looks more like a Japanese schoolgirl than a Hong Kong Cop), the disgruntled ex-military/ex-cop firearms expert (who is the most appealing from a character standpoint) and then lastly the melee/tank character (an ex-rapper from New Orleans with a down and out back story….yawn).  All the character stats suck.  All the character backstories suck.  I choose the ex-rapper simply because he was targeted to benefit most from smash-type weapons which based on what I heard was prevalent throughout the game

weapons, cash and mods

I haven’t gotten too far into the game, but the weapons modification system borrows directly from Capcom’s Dead Rising weapon system.  You find basic weapons and “ingredients”.  You then acquire via missions, blueprints for making custom weapons which must be assembled at tool benches around the island.  Out of the gate, the weapons are pretty fun.  I especially like the wooden paddles and the scythes.  It’s really fun to watch the weapons degrade after bashing them against zombie skulls, though I feel some life expectancy on metal based weapons are rather short (e.g. the Metal Pipe).  Modifying your weapons requires cash that is found ALL over, either on zombie corpses or abandoned luggage.  Money is required to modify your weapons and purchase mod recipe ingredients.

zombies

So far I have encountered only 3 types: the slow walkers that tend to overwhelm you in increasing numbers, the fast and freakishly violent 28 days later type infected and lastly the slow but all powerful thug.  I may be in the earlier stages of the game (only about 2-4 hours in) but I feel that the infected type should play a larger part in the main zombie combat.  That was what was so fun about Left 4 Dead was the “oh shit let’s get out of here” feeling when you saw and heard the crazed, fast infected hurling towards you.  The thug is hard to beat because he can flail his arms about and knock your character on his butt.  I only hope that there is a drastic increase in difficulty with the yet to be seen specialty classes.

combat

It’s mostly melee.  I haven’t encountered any firearms but from what I have read, they aren’t the highlight of the game.  Melee combat is pretty darn fun.  I especially like the way you can target limps and heads based on the type of weapon.  Limps are less affected by knives but more affected by shovels and paddles.  And you can break limbs or sever them completely.  My favorite thus far is a kick to the gut followed by swift decapitation with the scythe.  One annoying feature is that in certain “special” kills like the scythe decapitation, you get a bullettime effect that doesn’t seem to help you in out manuevering other zombies.  It’s just plain ol’ slow motion for the sake of gratuitous violence.  There is a rage mode as well that is unique to each character.  The rapper just dons his brass knuckles and beats the shit out of zombies.  yawn…..

game progression

So far, and I don’t see an end in sight, this game consists of mundane tasks of get this, go there, tell this person something, kill some zombies, get my necklace, grab some gas to burn some corpses, etc., etc., etc.  Pretty standard crap missions throughout.  I haven’t encountered any “boss” type missions thus far.  There other suckage comes in the fact that you can’t do things stealthily.  For instance, a task to turn on a gas pump generator would have been more fun, trying to sneak past a thug zombie.   But instead, you have to basically slug it out every time.

world

so far this island is huge and HIGHLY detailed. And there are SOME destructible aspects.  But after a while, it’s just a beach, rocks, trees, etc.  It’s a beach resort folks, so no ice zone or crazy stuff like that.  The character details are pretty slick however I do see some rendering artifacts when character dialogs kick in.  For instance, it seems that every bikini-clad chick looks like she partied hard not for the last week, but for the last decade.  I’m not one to get my kicks through female video characters, but I think that if you go to the effort to render characters in bikinis with ridiculously huge boobs to appeal to your majority-male audience, then why not go to the extra effort to make her face attractive?  I also dislike not being able to slay the living.  So far every NPC i have encountered who pisses me off, I cannot bash their skulls in with a shovel

in closing

I am SOOOOOOO glad I found this used at Game Stop.  I have 7 days to feel it out, but my first impressions are usually right and I have a feeling that this will be going back for a credit.

So use:

<s:State name="default"/>

Instead of:

<s:State name="normal"/>

…. unless for some reason you are extending a SparkSkin and see an explicitly defined state with the name “normal”.

I think I have settle on the following formats (of course this is subject to change):

public interface iFoo { ... } //interfaces
public class mFoo { ... } //implementations a.k.a. base classes
public class aFoo { ... } //abstract classes w/ function override enforcement via errors

[original]

I am currently on my 4th complete rewrite of the as3isolib.v2. It’s not that the previous drafts were not worthy, but rather through experimentation over time, the code has become quite cluttered and unmanageable. So rather than trying to clean up the existing code, it seems like a time to do a rewrite while things are relatively fresh on my mind.

One thing I have been struggling with in v2 is maintaining an easy-to-use APIs while not sacrificing performance. I spent 6+ months performance tweaking draft #3. There is a lot of function inlining, base class implementations, scratch objects, etc. This makes for blazing fast performance, squeezing everything possible out of the flash player, but it also makes maintaining an easy-to-use API very challenging.

Case in point: Interfaces vs Abstracts. While there is no officially supported Abstract class in as3, there are a few hacks here an there. Why would you choose an abstract implementation over an interface implementation? First I should discuss the performance implications of calling a function rather than accessing a simple instance variable. Interfaces mandate that defined APIs are done so either by true function calls or getters/setters.

package
{
public interface IFooBar
{
     function foo():void;
     function get bar():Object;
     function set bar( value:Object ):void;
}
}

you cannot however define an interface variable.

package
{
public interface IFooBar
{
     var myVar:Object; //does not compile.
}
}

But back to performance implementations.  Over at Jackson Dunstan’s blog (http://bit.ly/mXLmEX), he has done some performance testing of function calls over variable access.

• Beware of Getters & Setters - http://bit.ly/qP9aHE
• Inlining Math Functions - http://bit.ly/nlxJgD

Obviously we can’t get out of NOT calling functions, but when performance is key, Jackson shows that variable access is much more performant.  In as3isolib.v2, performance is a big deal.  So the alternative is to impose some sort of pseudo-abstract class implementation.  This would basically look like:

package
{
public class IFooBarImpl
{
     public function foo():void {}
     public function get bar():Object { return null; }
     public function set bar( value:Object ):void {}

     public var myVar:Object;
}
}

So the upside of this is a) we get both the functions demanded by the interface and the variable accesses provided by the implementation.  The downside is that in order to utilize this, it needs to be subclassed.  The other thing to note is the naming convention.  I think because this is a special case, it requires a special naming convention to denote a) the interface-ishness and b) the abstractness.  I’d suggest something like:

IClassImpl

The prefix “I” conforms to Adobe’s coding conventions for interfaces, you still get the intended purpose immediately following the prefix and the “Impl” suffix denotes that this is an actual implementation rather than a true interface.

So I will now present why I am seriously considering this for the as3isoilb.v2.  The v2 engine’s render process is something that gets called once every frame via Pushbutton Engine’s IAnimatedObject.  There are several core classes that get accessed on every render pass, including a collection of game objects that are looped through.  This means in the render pass’s loop, we are accessing simple values like x, y, z, and isInvalidated THOUSANDS of times.  So while in a normal situation where under the hood a getX() is getting called may be fine, for performance-intensive code, those performance hits for function calls add up considerable.  We are talking on the scope of 5-10 FPS lost per render pass and 10-20 ms per frame added.  This increases proportionately to the total number of entities rendered.  Having access to simple vars keeps the access penalty low, thus allowing more objects to be crunched.

Thoughts?  I’d love to hear them.

Anyway, I decided to update my resume since it hadn’t been updated since mid-2009.

I’d recommend visiting my resume page to see hw you can download in the format you need – resume page

OR

just take me to the current resume – link