Tutorial 1 – Haxe Setup

If you are not interested in building the Genome2D library yourself or using Haxe at all you can skip this tutorial and just download the official SWC build at Github

So now if you want to build Genome2D yourself or you are going to use Haxe for your projects you need to know what are the building blocks of Genome2D library. Each of these have their own Github repository.

Genome2D Core
This is the high level part of the library which is platform independent.
Github repository: sources

Genome2D Context Common
Common abstract base for low level context part of the Genome2D library.
Github repository: sources

Genome2D Context Flash
Flash low level context used for Flash target.
Github repository: sources

Genome2D Context HTML
Flash low level context used for HTML target
Github repository: sources

Additionally you may experiment with Genome2D Examples but they are not needed to build Genome2D projects or the library itself.

Genome2D Examples
Genome2D Examples
Github repository: sources

You are pretty much free how you want to setup your build paths as its pretty flexible using Haxe compiler independently of the IDE. I am using IntelliJ IDEA with Haxe plugin and compilation using custom hxml files. This is how my sources are setup.

I have all the contexts grouped in a single context directory where each of them has its own directory where the complete Github repository for that context is cloned. Keep in mind that if you are only going to target Flash you don’t need HTML context at all. Additionally there is the cloned Genome2D Core github directory and Examples which again are not mandatory for Genome2D compilation.

There is a global build.hxml file which is used as the hxml file used for compilation which then refers to the build file depending on our target. This is how build.hxml looks like:

# Examples JavaScript Target

# Examples Flash Target

# Flash Complete Library

# is used as a comment prefix in hxml files so currently the hxml file is set to compile the swc.hxml file in our core repository. Since the build.hxml is the build file passed to Haxe compiler all the paths defined in the referred hxml files will be relative to the build.hxml file even if the hxmls are not in the same directory.

Lets look at the swc.hxml:

# Include sources
-cp core/src
-cp context/flash/src
-cp context/common/src

# Include libraries
-lib msignal
-lib actuate
-swf-lib context/flash/lib/AGAL.swc

# Haxe flags
-dce no

# Genome2D flags
-D stage3Donly

# Flash Swc flags
-swf-version 12
--macro include('com')
-swf ../out/Genome2Dhx.swc

First we include source paths for the core, flash (since we are targeting flash with swc) and we also need common context base. Again we are using paths relative to the main hxml file.

Next we include libraries msignal and actuate which are free opensource haxe libraries for signal handling and tweening. If you don’t have them installed you can do it using haxelib.

haxelib install msignal
haxelib install actuate

Next are Haxe specific flags -dce no means there will be no dead code elimination which is crucial for library compilation since we want all the code to compile.

Genome2D specific flags -D stage3Donly means that it will compile without IContext interface but typedef it directly to GStage3DContext which gets rid of an abstract implementation layer and increases performance but discards the custom software fallback GBitmapContext implementation. You should always use this flag if you are sure that your swf is going to end up run on the GPU which is almost every case except on sites that don’t include direct wmode in their html wrapper.

NOTE: GBitmapContext implementation doesn’t support all the Genome2D features due to the CPU limitations

At last we specify Flash specific flags such as version, our output file and the macro tells the compiler to include all the classes in the com package.

Finally there is one more step needed if you are compiling Genome2D, unfortunately this step needs to be done post compilation. Haxe doesn’t include external swc dependencies in the final swc. Which means since we used external AGAL swc its definitions are not included in the final swc. The good thing is that AGAL swc contains just single class which is AGALMiniAssembler so now we need to add definition of this class to the final swc catalog.

To get to the swc catalog rename the swc to zip open it up extract the catalog.xml now edit it and add this definition among the other script definitions: