Hxcpp 0.4, NME 0.9, Neash 0.9 Released!

What the flash?

What is Hxcpp? Hxcpp is the c++ backend for haxe. This means you can compile haxe code to c++ code, and then compile this to a native executable, for Windows, Linux or Mac.

What is NME? NME is the “Neko Media” library that wraps SDL, providing gaming interfaces for neko, and now native compiled haxe code.

What is Neash? Neash is a compatability layer that presents the flash API to haxe code running on other systems, such as js, neko or c++ native code.

Together these allows you to write code to target flash SWF files, and also cross compile to native code for Windows, Linux or Mac.

Hxcpp on haxelib

I have finally packaged up a bunch of changes into offical haxelib releases. Hxcpp is now on haxelib, which means you can get it with “haxelib install hxcpp”. This effectively creates a whole separate install of haxe, which can be run side-by-side so you can test it out without risk.

The cpp backend now supports Mac(intel) and Linux as well as the original Windows platform.

The main change to hxcpp is the packaging – moving towards a the final installation form. Currently there are a whole bunch of files distibuted in this release that should become redundant once the c++ backend is merged into the main branch. Also, the library coverage has been expanded a bit, but it is still not complete.


Firstly, you will need to run “haxecpp” instead of “haxe”. This executable is found in the appropriate bin subdirectory. I’m not sure if the “executable” flag will survive the compression, so you may need to “chmod a+x” the file.

It is probably best to place the appropriate bin directory in your executable path. On windows, this will also solve the problem finding the dynamic link library, hxcpp.dll. And on all systems, this will allow you to use the “make\_cpp” command from the hxml files. On Linux systems, you will have to allow the executable to find the hxcpp.dso. This is most easily done by setting LD\_LIBRARY\_PATH to the bin/Linux directory, or copying this file into an existing library path. Similarly on Mac, you should set DYLD\_LIBRARY\_PATH.

To build haxe code, use “haxecpp” inplace of “haxe”, with a target specified by “-cpp directory”.
This will place source code and a makefile in the given directory. Then you need to do a “make” on linux/Mac, or “nmake” on Windows to build the executable. You may need to set the environment variable “HXCPP” to point the the directory that contains this file. On windows, this will be something like: c:\Progra~1\Motion-Twin\haxe\lib\hxcpp\0,4\

As a shortcut, if you are using a hxml file, you can use “-cmd make_cpp” which will do the build for you assuming you used the “-cpp cpp” directory.


The big changes for NME is that it now supports Linux and Mac(intel) for neko ac c++ targets. There have been a few bug fixes as well as a few new features:

  • Bitmap class
  • Expanded and optimised TileRenderer for render scaled and rotated sub-rects from a surface
  • A few smarts for finding fonts, if no ttf is supplied
  • Some blend modes have been added
  • Added scale9Rect
  • Added drawTriangles, with perspective correct textures


There is still plenty to do, including, but not limited to:


  • Proper coverage of all APIs.
  • Resolve the order-of-operation problem: In c++ f(x++,x++) is ambiguous as to what order the increments are performed. Or perhaps agree to live with it.


  • Add all blend modes
  • Add all filters
  • Discuss with experts the merits of static vs dynamic linking Mac and Linux.


  • Sound is a big ommision
  • Loader code
  • Unit testing of supported APIs.

Despite these issues, I think there is a useful core of functionality here.

Let me know what you think.

Neash/NME first release


I am pleased to announce the initial version of neash 0.1, that works with the latest version on NME, 0.3.2.
Neash allows the same code to be compiled for both the flash virtual machine and the neko virtual machine. NME provides the advanced vector rendering routines to emulate the flash9 API. You can download each of these packages using “haxelib install nme” and “haxelib install neash”.

The image here shows the same code running the the flash player, as well as a native win32 window. The code is in the samples area, and is as follows:

import neash.display.Sprite;
import neash.display.Shape;
import neash.geom.Matrix;

import neash.Timer;

class Clock extends Sprite
   var mCx:Float;
   var mCy:Float;
   var mRad:Float;

   var mMinuteHand:Shape;
   var mSecondHand:Shape;
   var mHourHand:Shape;

   public function new(inCx:Float, inCy:Float, inRad:Float)


      mCx = inCx;
      mCy = inCy;
      mRad = inRad;

      var gfx = graphics;
      for(i in 0...12)
          var theta = i * Math.PI * 2.0 / 12.0;
          var cos1 = Math.cos(theta-0.01);
          var sin1 = Math.sin(theta-0.01);
          var cos2 = Math.cos(theta+0.01);
          var sin2 = Math.sin(theta+0.01);

          gfx.moveTo( mCx + cos1*mRad,     mCy + sin1*mRad );
          gfx.lineTo( mCx + cos2*mRad,     mCy + sin2*mRad );
          gfx.lineTo( mCx + cos2*mRad*1.1, mCy + sin2*mRad*1.1 );
          gfx.lineTo( mCx + cos1*mRad*1.1, mCy + sin1*mRad*1.1 );
          gfx.lineTo( mCx + cos1*mRad,     mCy + sin1*mRad );

      mSecondHand = CreateHand(mRad*0.02,mRad);
      mMinuteHand = CreateHand(mRad*0.05,mRad*0.75);
      mHourHand = CreateHand(mRad*0.1,mRad*0.5);

      var timer = new Timer(1000);
      var me = this;
      timer.run = function() { me.SetHandPositions(); }

   function SetHandPositions()
      var date = Date.now();

      var hour = date.getHours() % 12;
      var minute = date.getMinutes();
      var seconds = date.getSeconds();

      mSecondHand.rotation = seconds *360/60;
      mMinuteHand.rotation = (minute + seconds/60.0)  * 360/60;
      mHourHand.rotation =   (hour + minute/60.0 + seconds/3600.0) * 360/12;

   function CreateHand(inWidth:Float, inLength:Float) : Shape
      var result = new Shape();

      var gfx = result.graphics;


      result.x = mCx;
      result.y = mCy;

      return result;

   static public function main()

      new Clock(320,240,200);


Porting this from a pure flash program involves:

1. Changing the “import” commands to replace “flash” with “neash”
2. Also changing from the “haxe.Timer” to the “neash.Timer”, which supports additional options.
3. The “main” routine must call “neash.Lib.Init( )” very early and at some point must call “neash.Lib.Run()”.
4. That’s it!

I’m looking at ways to remove point 1 using some compiler options, but this may not happen. Also note that the command-line for compiling requires “-lib neash” and, on the native platform, also requires “-lib nme”.

The clock example is really just to show timers working. NME runs the game loop as fast as it can at the moment, so timers are a bit pointless to some extent. This may change in the future.

The flash9 api coverage is a little thin at the moment. I have concentrated on flash.display.Graphics, including linear and radial gradients, bitmaps and line styles. However, some supporting things such as events and TextFields, are not well covered. Also note that some things (so far using a colour-alpha as a 32-bit int, eg #ffffffff) are not supported under neko.

Neash is currently only for flash9/neko compiling. Flash8 and JavaScript will only be supported if there is big need for it (basically if someone else wants to do it).

Neash does not have a binary component, so it works on platforms currently supported by NME. Namely windows and linux. Mac support will follow when NME is ported.

Neash was designed initally for games, and so is quite graphics-oriented. Here is an example showing the neash port of the “plotex” haxe module (you can get it with “haxelib install plotex”) running on windows.
I’m not sure if this necessarily useful, but it is fun in a dorky sort of a way. One of the porting problems was due to the fact that plotex already supports 3 out of the 4 haxe platforms, so it contains conditional compiles. As a rule of thumb, use neash where you would use flash9. So “#if flash9” becomes “#if (flash9||neko)”. Another issue was parameters passed from the html to the swf object. These are emulated in neash using command-line arguements.
The source code changes can be found here. Note:copyright retained by original author, see [plotex website](http://code.google.com/p/plotex/) for more details.

Porting NME to linux

Linux Port
So, I decided to try porting NME to Linux. The first thing you do is find an empty hard drive, download an ISO, and off you go, right? Wrong. I did this – but I wanted to keep my windows partition, without risk of rooting it over, so I didn’t over write my MBR. Then, I could not actually boot my linux partition. Eventually I got around this by booting from a rescue CD (I do not, and never will again, own a working floppy driver) and specifying my /dev/sd partition in a bit of a round about sort of way. Anyhow, I got Linux booting (with a little bit of pain per boot – but I could live with this), but then the wireless network did not work. This I could not live with, so I though about resurrecting some crappy old hardware I have lying around, but in the end I sought, and found, an infinitely better solution.

The answer is virtualization! I can’t overstate how much easier this was than actually getting the hardware together. First, I downloaded the free version of [vmware’s “player” product](http://vmware.com/products/player/), and then the Ubuntu 7.1 virtual machine, that included a dev environment [http://jars.de/linux/ubuntu-710-vmware-image-download-english](http://jars.de/linux/ubuntu-710-vmware-image-download-english). The reference to “jars” seems to be a java reference, but we wont hold that against them. It “just worked”. I edited the xorg.conf file to change the keyboard to US, (so I could use the ‘|’ key), and that was about it. With only mimimal clicking, the network was fully working, *and* I could switch to my windows emails etc. This was what I wanted – much better than dual boot. Compiling NME was just a matter of adding the “dev” version of packages (vim, subversion, SDL, SDL\_miver, SDL\_image, TTF) with the GUI “Synaptic Package Manager”, which also “just worked”.

The download from code.google, via svn, worked easily once I added the “subversion” package.

Then a little [makefile](http://nekonme.googlecode.com/svn/trunk/project/makefile) to bring it all together. I had to make some code hacks. I don’t know if this is a gcc “bug” or “feature”, but when I tried to call a class member function, that was templated on an int, eg:

int x = Class.Member<4>(10);

the gcc compiler thought I was using “operator<", which is a bit of a shame. I also had a quick go at static linking, via the ".a"s, rather than the ".so"s, but the linker told me I needed a "version section" for one of the SDL symbols, so I gave up. The image you see is in the top left is of a window, on my windows desktop, running a virtual machine, running ubuntu, running the neko virtual machine, running a neko script linking to the Linux version of NME. And running it very well, I might add. The only problems at the moment, are text, when a font is not supplied, the "mod" music in the "blox" demo, and OpenGL on my setup. The PNG, JPG, WAV and OGGs stuff all worked first time. I think I might be able to get the music going, if I get the right plugin dso. Also, I'm not sure about what ".so" files need to be distributed with the program to resolve all the dependencies. Any SDL linux guru have any comments on this?

Compile NME.ndll From Source.

Neko NME now compiles into a single, statically linked ndll (actually, it still uses plugins for mp3 and tiff). This means you can’t use the standard development distributions for building it, so I’ve made some libraries to use. You can download them from [nme-dev-0.3.tgz](/wp-content/uploads/2007/12/nme-dev-0.3.tgz).

To compile, first checkout the svn version as described below, then extract these to create a “thirdparty” directory next to the nekonme-read-only directory. The “NME.sln” project should then refere to the libraries and includes in this thirdparty directory.

This has been build with Visual Studio Express 2005. Currently, this is a windows-only version.

Neko NME updates.

I have had a bit of a think about where some of this cross-platform code should sit, and I’ve partnered with Lee McColl-Sylvester at [DesignRealm](http://www.designrealm.co.uk/html/) to add the functionality to the existing “Neko Media Engine” (NME) project.
This idea here is to provide the flash drawing API to the neko runtime using opengl or software – which ever is fastest at the time.

There have been some big changed to NME recently, and it’s pretty easy for a haxe developer to checkout the “bleeding edge” and have a look at the samples, if they have svn installed. First install the existing NME project using the haxelib tool, ie:

haxelib install nme

Now, at the time of writing, it is 0.2.0, which is now a bit old. To use the new stuff (this works on most haxelib modules), checkout the latest stuff from [code.google.com](http://code.google.com/p/nekonme/). First make a directory – it’s a matter of taste where – to hold the code. For simplicity, I’m using one directory to hold all the google code checkouts, and I’m calling it “C:/code.google/”. From a shell in this directory, follow the instructions on project page about how to checkout the svn version:

svn checkout http://nekonme.googlecode.com/svn/trunk/ nekonme-read-only

(You can actually call the last bit of the directory anything you want). This will give you a whole lot of files, called something like “c:/code.google/nekonme-read-only/nme/Manager.hx” etc. Now you can point your neko at this new code using the haxelib command:

haxelib dev nme c:/code.google/nekonme-read-only



This should give you access to both the new “.hx” class files, and the new “Windows/nme.ndll” binary file.
Then you can look at the samples by building them with “haxe Compile.hxml”, and running them with “neko *.n”.

There are examples showing the use of sound, a complete game and where things are going with the new flash-drawing api (not yet complete). The images here show circles, lines and text (solid and transparent backgrounds) and 2d-transformations, using both software and opengl rendering (no bilinear-sampling on software version yet).