Use Away 3D man …

… or at least give it a try!

Working on Aviary I had the plesure to meet Alexander and Fabrice, the creator and one of the actual maintainers of Away 3D engine.

As you might known, we are using Away 3D for Hummingbird, and I had the plesure (yes, another :P) to give a look at the code an work in touch with the developers. I have to admit that Away 3D is really good!

I’m far to be the best person to suggest one framework over the others, but what I can do is tell you why I think Away 3D is (at least) worth a try, even if you are already working with Papervision 3D or the other engines. The first thing to know is that both the projects comes from the same branch – they have been splitted a few years ago (maybe just an year but I’m not sure) and then they followed two different paths. During my quick and basic experience with Away 3D I see that it has a real clean and powerful API (you have animation for instance or really good materials), good documentation and tutorials (see Fabrice‘s blog for a bunch of them!), more precise a quick rendering. And part of the new Papervision 3D 2.0 code is inspired by that library.

The various libraries outta there are for different purposes, and probably are taking (or will take) different directions (ie: see Alternativa 3D for instance, which seems well suited for games). But trying many of them instead focusing only on the most famous one is a really good thing – many users comes from PV3D for instance and are really happy about Away!

Don’t take my assumptions as gold: this is what I think after just a bit of playing 😉

Top Down or Bottom Up for Expression Evaluation ?

Last time I wrote about Top Down parsing, a technique for parsing that can be easilly implemented manually using function recursion.

Today it is time to talk about one of the other ways of parsing, called Bottom Up parsing. This technique try to find the most important units first and then, based on a language grammar and a set of rules, try to infer higher order structures starting from them. Bottom Up parsers are the common output of Parser Generators (you can find a good comparison of parser generators here) as they are easier to generate automatically then recursive parser because they can be implemented using sets of tables and simple state based machines.

Writing down manually a bottom up parser is quite a tedious task and require quite a lot of time; moreover, this kind of parsers are difficult to maintain and are usually not really expandable or portable. This is why for my tests I decided to port bYacc (a parser generator that usually generates C code) and edit it so it generates ActionScript code starting from Yacc-compatible input grammars. Having this kind of tool makes things a lot easier, because maintaining a grammar (that usually is composed by a few lines) is less time expensive than working with the generated code (that usually is many lines long).
I will not release today the port because actually I had not time to make sure it is bugfree and I’ve only a working version for Mac, but I plan to release it shortly if you will ever need it for your own tasks. My goal for today was to compare the speed of the parser I wrote with an automatically generated bottom up parser, to see which is the faster approach.

I created a bottom up parser which is able to execute the same expressions accepted by the expression evaluator I wrote last time. There are anyways some differences that – as you will probably and hopefully understand in the future – that make those parsers really different. Some will be disussed shortly here.

To do that I created a Yacc grammar and some support classes.
The parser grammar is really simple and really readable:
%{
%}
%token NUMBER SYMBOL
%left '+' '-'
%left '*' '/'
%left NEG
%%
program
: expr { Vars.result = $1; }
;
expr
: expr '+' expr { $$ = $1 + $3; }
| expr '-' expr { $$ = $1 - $3; }
| expr '*' expr { $$ = $1 * $3; }
| expr '/' expr { $$ = $1 / $3; }
| '-' expr %prec NEG { $$ = -$2; }
| '(' expr ')' { $$ = $2; }
| SYMBOL '(' expr ')' {
if( Vars.SYMBOL_TABLE[ $1 ] )
{
$$ = Vars.SYMBOL_TABLE[ $1 ]( $3 );
} else
{
trace( "can't find function" );
}
}
| SYMBOL {
if( Vars.SYMBOL_TABLE[ $1 ] )
{
$$ = Vars.SYMBOL_TABLE[ $1 ];
} else
{
trace( "can't find symbol" );
}
}
| NUMBER { $$ = yyval; }
;
%%

Continue reading the extended entry to see the results. Continue reading

Finally a code coverage tool for AS3!

Today is really a good day.

I was waiting for this kind of tool since a lot of time, and thanks to Joe we can finally do Code Coverage of our Actionscript code.

The project is hosted on Google Code, and can be obviously downloaded for free; the project is born after some tests of the author, that edited the Flex compiler to include additional informations that are used to generate a code coverage log that then can be read by softwares that display the output in a more user friendly and fashion way.

For anyone who doesn’t know, Code Coverage is a good practice used most in software testing, that is applied to understand how much source code is touched by our tests. This way a developer knows if a test covers all the source code (or the required portions) and can tune his tests if they don’t.

This project is probably one of the first born after the public release of the Flex SDK source code, and we are pretty sure that there are much more projects coming in the near future.

Finally we can do a little bit of Code Coverage in Aviary 🙂