The latest version of NME adds a new feature to the tool, “Three Letter Compiler” (TLC). This feature is designed to get you going quickly on a new or existing project.

First, make sure you have the latest NME installed. If are going to do some cpp compiling from windows, it is best to install the latest version of Microsoft Visual Studio (“Desktop” version). Now while you are waiting for that to download, you can have some fun with NME.

The haxe ‘haxelib’ utility allows you to run library scripts using the ‘run’ command, like:
haxelib run nme
NME has various features ‘commands’ that you can use, the first one is ‘help’, which prints a list of possible commands:
haxelib run nme help

The first thing you will notice that it is going to get pretty tedious typing “haxelib run nme …” every time you want to do something, so the best thing to do is to setup an alias. If you have your own admin style, you may choose to do this anyway you like (like the unix ‘alias’ command), but you can also achieve this using:
haxelib run nme setup
which will create a small shell script or batch file to save you some time. So now we can use the “nme” command instead of haxelib.

Now we have done some basic setup, it’s time to check out the demos. To see the list of installed demos, use the command:
nme demo
This should give you a list of 20-something demos to try. Listed on the left is the abbreviation you can use – just pass this command to the nme demo command (eg, ‘he’ is short for ‘HerokuShaders’). When you run a demo, the binary files will be created inside your current directory, so before we start, it is best to move to a ‘scratch’ area that we can delete later.

cd c:\temp
mkdir scratch
cd scratch

Has your compiler finished downloading yet? Maybe not, we will try it first with neko.

nme demo hero neko


This should get you up and running. You can explore the other demos like this. You will notice the last parameter, ‘neko’. This is the target – if you were not to specify anything here, nme would assume the default target, which is a ‘cpp’ compile. You can set the default target using the nme ‘set’ command:
nme set target neko
Now code will be compiled by default for neko. You can remove the set value with the ‘unset’ command. For advanced users, you can use the command:

nme set bin c:/temp/scratch

To set the output (binary) directory for all your nme projects. This will allow you to keep the generated output files outside your source file tree, separating the disposable files from the precious. You can also do this when compiling any project by using the ‘-bin path/to/output’ command line options. Don’t forget to “nme unset bin” to restore normal behaviour.

If you are every wondering what is going on under the hood, and where the files are actually going, you can use the ‘-v’ verbose flag to get nme to dump out a bunch of stuff as it goes. You can also set this on for always, using:

nme set verbose

Ok, the demos are working, but you want to get your own code going, and it is time to fire up the text editor. The main nme drawing APIs are based in the flash drawing APis. The easiest way to get started is to create a “DisplayObject” and draw something into it. If this is you “main” class, then NME will take care of getting your object onto the screen. The best place to start is in a empty directory with a “Sprite” class. So we can start with some code like this (in “MyGame.hx” – the name must match the class name):

class MyGame extends nme.display.Sprite
   public function new()

Now, in the directory you can issue the command:


With a little TLC, you can get your first game going (not very exciting mind you). When run on its own, the nme command will use the default target (which we have set to neko), it will run the default command (which is ‘test’, unless you use the ‘set’ command to say otherwise) and it will look for the best project file. If there is no project file, then it will look for a single “.hx” file. If the command gets confused by multiple files, it will simply just not work. You can also use this command in the demo directories since they have either a single project or single haxe file. Indeed, you can compile most projects like this.

There are also a few things you can do with source code using special comments to change some of the programs attributes. At some point it is worth switching over to a proper project file, but until then you can have some fun with ‘// nme:’:


// nme: background=0x000000
// nme: width=200
// nme: height=200
// nme: title=Cool Game

class MyGame extends nme.display.Sprite
   public function new()

Cool game indeed.

Nme also allows you to compile demos from some other projects. Just add the project name after the ‘demo’ command. Openfl is closely related to NME, so they are quite compatible. Firstly, install the openfl demos, using


haxelib install openfl-samples

Now you can get a list with:

nme demo openfl

And then run one with:

nme demo openfl pirate

Since HaxeFlixel uses openfl, it too shares compatibility with NME. However, you currently must be running the a version newer than 3.2.2 to get it to work. First install the flixel samples with:

haxelib install flixel-demos

Then get the development version by by cloning the repo from GitHub and using haxelib to point at this new download. This in turn needs the git version of flixel-addons, so updating requires:

haxelib git flixel https://github.com/HaxeFlixel/flixel.git
haxelib git flixel-addons https://github.com/HaxeFlixel/flixel-addons.git
nme demo flixel

Will show the list. We can now try the classic bunnymark, but this time will will make sure we compile it for ‘cpp’ for maximum speed. (Has your download has finished yet?). Arrr!

nme demo flixel flxbunny cpp



Another project you can try is the “haxeui” project. With:

haxelib install haxeui
nme demo haxeui
nme demo haxeui accord

Hopefully the NME TLC can help your workflow a bit.

NME 5.0 (re)Released!

It has been a little while coming, but I have released a new version of NME, v5.0, available on haxelib today (“haxelib install nme”). If you wish to do some development rebuilding the nme binaries, you can also download the companion project, nme-state, which provides the libraries required for developing NME.

The source code can be found on the official NME github repo. Bleeding edge/nightly builds can be found at the dedicated build site nmehost.com, and the discussion forum is the google NME host group.

NME is not Openfl. The NME and Openfl code bases forked towards the end of 2013 when new haxe code was placed in openfl-native. Later the run-tool, binaries and templates were also placed in separate projects. Today, NME is a lot closer to the lime project, which has the same native code DNA, but only has a subset of the haxe files. NME has also changed its remit to lessen its ties to the flash API, with “inspired by the flash API” probably being the closest description.

My main reason for resuming the NME project is focus. I have dropped support for all targets other than windows, mac, linux, iOS, android (x86 support has been added) and flash. I have also dropped support for opengles1 (fixed function) rendering, and everything is done with shaders now. There is currently no HTML target – this may change in the future – but also maybe not. Other binary platforms may be supported if there is significant and lasting support in the market. It has only been by reducing the scope of the project that I have managed to make forward progress, so I’m keen to keep this focus.

There are other reasons why a single, compact project is more appealing to me than several inter-dependent projects. That is, where the templates, binaries, haxe code and run tool are all 100% synchronized and edited as a whole. This coherence has made the additions of some new features much easier:

  • Android view. Instead of generating a full apk, NME can generate a self-contained fragment (jar, binary, java), which can be included in a larger project, which might contain native controls etc.
  • iOS view. NME can generate a library+header file that implements the UIViewController interface, which can then be linked into bigger iPhone applications.
  • StageVideo. The two mobile projects can use the new StageVideo API to play or stream videos, while using haxe for rendering controls or other graphics over the top.
  • Static linking. NME have moved to SDL2, which now has much more developer friendly licensing terms, so NME is now GPL free! This means that programs can be statically linked into a single exe with no external dependencies (if you so desire).

Some features have been disabled. Most notably, the extension system has been removed and not yet replaced. I’m hoping to implement a more simplified or integrated solution based on the static linking principles. Android audio has also been reverted to the Java based API while I’m hoping an opensl solution may be possible. Asset libraries have also been removed, to be replaced by using haxe code where appropriate.

There have been quite a few minor fixes to the code base, including:

  • Preemptive GC. This experimental feature can be enabled from the Stage and allows the garbage collection to happen in parallel with the render. Since the render uses native code (except for ‘direct renders’), the GC should be able to proceed with reduced impact on the frame rate.
  • Shader-based line anti-aliasing. This allows smooth edges on hardware accelerated lines without multi-sampling AA.
  • Vertex Buffers. Internally, hardware geometry is stored in vertex buffers, which should improve rendering performance.
  • Premultiplied alpha. Some initial support for premultiplied alpha (bitmap property) has been added to avoid halos on objects where alpha transitions to 0. There is still some work to be done on this feature.
  • JNI fixes. Improved android interaction with JNI and timing code
  • Integration with ‘waxe’ project. NME is forming a closer relationship with the waxe (wxWidgets native widget set) project.
  • Refactored run script. This is still a work-in-progress, with some features removed, but some features have been added – like three-letter-compiling (“nme”), and building without the need for a project file (for simple programs).

These changes are generally in the native code, which is similar to the code in the lime project. So it should be possible to port features from one project to the other.

I have also implemented an automated build system. This should mean more consistent and frequent releases – including nightly builds for the more experimental people, and makes supporting both static and dynamic linking easier. NME uses the companion developer project “nme-state” for rarely changing libraries. This project uses neko and the hxcpp compiler toolchain files to ensure that all builds have consistent compiler flags and all sub-targets are supported where required, while not requiring additional dependencies. Having automated builds also makes upgrading easier, such as upgrading libcurl to not block in ssl calls.

NME aims to be largely compatible with Openfl, so that developers can switch between the two implementations if required. There will be ongoing support for this.

So NME has gone through a few changes. Some things have been improved, some things may be still be in transition, and some things may be dropped. If you rely on one of the dropped features, I suggest you stick with Openfl. If you prefer this project structure, come and join the team.