While I was looking for some more advanced Math functionality in AGAL, I stumbled upon this neat library on Google Code called ASGL (available via SVN here). It’s actually more than a supplement of convenient Math formulas for AGAL – from what I can observe it is a great foundation (if not a complete 3D rendering engine) to get started on creating your very own 3D worlds in Flash.

File Formats

Support for many common 3D models file formats exists:

  • ASE
  • 3DS
  • DirectX
  • MD2
  • MD5
  • OBJ

Post Processing Effects

Don’t need to worry about creating your own Quad and use render-to-texture techniques to achieve your screen blurs or blooms. A few effects have already been made ready for you:

  • Blur
  • Bloom
  • Depth-of-Field
  • Edge Detection
  • Motion Blur

And much more…

There’s much more available in this library. I suggest you take a look at it. Here’s a light preview of ASGL’s folder structure:

ASGL's folder structure.


Hmm functionality-wise… I can’t say anything. I’m sure it runs as intended. What I was most interested in when I explored this library was the way AGAL was written in comparison to EasyAGAL, or XAGAL (I rolled my own, see here for more info).

Sure, ASGL has a lot of tricks up it’s sleeve. However, I can’t say that I’m a fan of it’s implementation of AGAL. One word: Concatenation (or overconcatenation  even). So much of it! You will see plenty of static public methods flooded with:

var code:String = '';

code += AGALBase.div(dest+'.y', number, const1000);
code += ...
code += ...
code += AGALBase.mul(dest+'.z', dest+'.z', tmp+'.x');

return code;

My complaint is not so much that it’s messy, but each lines are much longer when compared to writing it in EasyAGAL. Also, the numerous String concatenations like ‘.x’ , ‘.y’ , ‘.z’ , ‘.w’  or any swizzle  combinations thereof doesn’t make it encouraging to write your own shaders. But, I must say… the number of built-in methods (some of which are so sophisticated I may never use) overshadows this concatenation issue. Besides, most shaders will be compiled much earlier during initialization of your application (or game levels), and not per frames and/or game loops. So yeah, performance might be negligible… but still… yuck!

At this point, I haven’t tried to compile any projects using this library yet, but I do intend to write a tutorial about it later. I may need to get in touch with the Google Code project Members first to get some clarification on how to implement it and where to begin.

Until then, enjoy AGAL’ing!