NME Still Rocks

NME is over 8 years old now, and stronger than ever.

As seen at the wwx2015, there are now many great frameworks you can use with haxe. I would like to outline what I believe are the core values of NME to help you, the developer, choose a framework for future developments, or entice you into trying out NME with your existing project.

  1. Stability. Stability is the #1 priority. If your code compiled with NME yesterday, then it will compile with NME tommorrow unless there is a very good reason. NME is older than a lot of programming languages and sometimes this could be considered a bad thing, however NME’s #2 core value means that stability translates into reliability, not obsolescence.
  2. Innovation. We love innovation in NME- we’re always looking at how new technology can be applied to existing problems. When NME was conceived, there were no iPhones and no Android phones, however once they came out, these were quickly targeted by NME. NME also tracks (and inspires) cutting-edge development in the haxe compiler and the hxcpp backend. This can be seen with the latest Cppia integration. This combination of stability and innovation means that you can try out these new technologies risk-free.
  3. Pragmatism. NME concentrates on practical solutions to real problems. For example, when it became apparent how painful it was to set up an Android project then the nme tool was developed to solve this problem. Later the android testing workflow was significantly improved with the Acadnme backend.
    NME is also very light (50% lighter than other “light” media engines), and includes everything you need to build an app – no “dependency hell”. The stable versioning and automated build process means that you can easily try side-by-side fully-working cutting-edge or historical versions simply by downloading a single haxelib-ready zip file from nmehost.
    The extent to which the flash Api is mirrored is also governed by practical considerations. NME is not emulous of the name or implementation of flash – NME will happily add functions like drawTiles to help out developers, or to add the OpenGLView to allow the default rendering to be mixed with or replaced by traditional OpenGL rendering.
    NME takes a pragmatic approach to licensing too – wherever possible (currently everywhere) libraries are chosen to avoid any potential GPL issues and workflows are designed to avoid any patent issues (particularly with audio).
    Pragmatism is also a consideration when choosing what targets are supported by NME. Some targets such as BlackBerry, Tizen and Windows sandbox apps are not supported due to what I perceive as their cost/benefit ratio. This can change in the future if the benefits go up – perhaps Windows 10 will see some more interesting applications.

Getting (re)acquainted with NME.

For existing haxe users, NME is super easy to get started with. First, install the latest release with “haxelib install nme”, then create an alias for running the nme tool with “haxelib run nme setup”. Now you are setup with the “nme” command. If you do not want to create the alias, you can simply use “haxelib run nme” in wherever the “nme” command is used in the following discussion.

You can run the demos without needing to actually clone any demo code, but you probably want to start in a clean directory since the intermediate and application files will be created in a subdirectory of the working directory. Use “nme demo” for a list of NME demos. This list includes the first few letters in square brackets – this shows the shortcut you can use run the demo. eg, “nme demo ca” will run the “Camera” demo, with the default target “neko”.

NME is still largely compatible with Openfl projects, including flixel projects. And, it can make guesses about demos from other haxelibs, eg: “nme demo flixel” will list the flixel demos (assuming you have them installed), and “nme demo flixel:mode” will run the demo with neko, or “nme demo flixel:neon cpp” will compile + run a demo with hxcpp.

If you have an existing Openfl project, you can simple try nme by running “nme” or “nme cpp” in your project directory.

If you want to start a simple test from scratch, you do not even need a project file. You can start with a single haxe file, like you might with flash. eg, start by typing in Test.hx:

class Test extends nme.display.Sprite {
    public function new() {

then just run “nme”.


One of the big innovations for this year is the cppia target and the Acadnme runtime.
Acadnme This scripting target has the advantages of the neko target – being lighting fast to compile – combined with the versatility of the cpp target – that is, run on almost any device.

Acadnme comes precompiled for desktops targets (currently, Windows and Mac) in the acadnme haxelib (haxelib install acadnme), and for Android via the Google Play store. Once installed, you can test your program with cppia with something like “nme demo flixel:neon cppia”. This particular demo has some trouble with neko due to Floats initializing to null, whereas the cppia script follow the hxcpp quirks extremely closely and initialize these variables (more usefully) to zero.

To test on Android you need to be on the same wireless network. First, install and run the app and take note of the ip address displayed on the startup page. Then provide this to the nme tool as the “deploy” variable, like: “nme demo Stage cppia deploy=”. Your app obviously needs to be “Android ready” for this to work well, that is, ready for touch input and screen scaling.

You can create your own cppia target to use instead of acadnme, with “nme set cppiaHost /path/to/your/host”. Have a look at the opensource acadnme project to get an idea of what might be involved.

Give it a go.

I understand that there is not a one-size-fits-all approach for app frameworks. Other projects place higher values on things such as console targets, modularity of multiple libraries, re-architecting to get things 100% right and either avoiding or embracing the flash Api. NME’s core values are stability, innovation and pragmatism. If you also value these things, then we would love to have you on the team. If you prefer another framework, you can still have NME installed to use for testing and comparison, or for quick scripting via Acadnme.

It is very easy try out NME to see if it suits you needs. See how you like it, and tweet me @gamehaxe.

15 Replies to “NME Still Rocks”

  1. At wwx I was told to try NME. I had used it in the past but moved to openfl during because of the “announcement”. I was hesitant to try another moving target and I also wanted to use the source for Windows, Mac, Linux, Android, IOS, and html5 (JS). Is there a possibility of a JS target for NME??

    Wow. My stupid little game ran at 123 FPS. In openfl it was 91 FPS. It also felt visually smoother. That test game uses tiles.

    I then compiled my charting tool. yah, that worked solid. Much faster. The tiled version was spot on fast. I have another version that leaves the chart as drawn sprites. It hasn’t been usable in Openfl in the 1500 sprites (each sprite has a lot of graphics.lineto calls) range. In NME it very nearly is. It also looks tremendous. My biggest issue has been editable text fields. Yep, that works perfect too.

    Android worked perfect on my quick tests

    So this leaves me with a few questions:
    With Android/IOS is there a way to enable Slide typing or voice to textfield (http://www.techrepublic.com/blog/software-engineer/make-your-next-android-app-a-good-listener/)
    Is it setup for grabbing camera/pictures?

    1. Hi again. Glad you like it.
      The JS target is a tricky one – I have not done this mainly because I simply do not have the time to give it the focus it deserves. If someone else was super keen to add it, I could help with that. But also referring the the pragmatic approach, there are 2 other very interesting solutions – 1 is simply using openfl. Either by directly calling “openfl …” or indirectly by referring to the openfl haxe files somehow. This would channel energy into maintaining compatibility rather than rewriting the code, which could be a win all around. Or 2 – emscripten (and soon wasm). NME currently compiles to emscripten reasonably well, and this may soon become a web target. Currently the files sizes are a little large (couple of megs) but not outrageously so – and this will be reduced with wasm so I suspect it will be a pretty good solution.

      There is currently no android voice – but if you log an issue I will see what I can do – does not look super hard.

      Currently, there is a webcam view of mac and windows, and a video view for android and ios. I’m hoping to cross this over for all targets – just not there yet.

  2. Wow! Very impressive and sounds great!
    What the advantages(and disadvantages) of nme over openfl, snowkit or kha?

    1. NME is most similar to openfl. It is harder to compare it with snowkit and kha since their goals are a bit different.
      To compare with openfl, they both provide a vector graphics display list (flash Api) with an option for adding or replacing this with opengl. On top of this, they offer unified Apis to audio, networks and filesystems. Now since they both start from the same base, the interfaces are very very similar (and similar enough to flash that you can write web apps with the same code), it then comes down to implementation – what goes on under the hood. And this is where the projects differ. I personally prefer the project structure of NME (I would say that) and some of the technical decisions that have been made. It then comes down to whether you are a “framework hacker” or not. If you are, then things like repo layout and the organization of the code becomes important (again, I prefer NME). If not, and you just want to use the framework, you should compare them as “black boxes” with criteria that is important to you – stability/performance/targets etc. and this will depend on what you want and want you need.
      Currently I would say that the biggest advantages/disadvantages of NME and openfl, besides the internal stuff, are to do with the targets. Openfl targets JS, tizen, blackberry and offers console support, while NME offers android view, ios view and acadnme. I hope that the projects stay compatible, so you can use NME for acadnme and openfl for JS.
      As for snowkit and kha, they are also game frameworks – but they will generally have different graphics/audio/event Apis and also offer different combinations of targets. Comparing these is very personal – you would really need to see what the code for a simple game or app would look like in the different fameworks, and whether you like that style. Some like low-level, some light high-level – it is really a question of taste.

  3. Hi Hugh, quick question, does the current NME support native extension (for “native” target like Android, iOS, Windows). IIRC you decided to deprecated it/put it on hold in the past?

    1. I have added some compatibility for lime extensions, so there is a reasonable change they will work. I am happy enough to do a few tweaks to get any requested extension to work. I got together with a few of the other framework guys at wwx and discussed how we might define some kind of specification that would allow the different frameworks to share extensions.

  4. The acadnme “nme demo Stage cppia deploy=″ worked out of the box and is impressive. Unfortunately, the rest didn’y work so well. Assuming fresh haxe 3.2 install and nme 5.4.2 the Test.hx gives :

    haxelib run hxcpp Build.xml haxe -DHXCPP_M32=”1″ -Ddesktop=”1″ -Dhaxe3=”1″ -Dhax
    e_ver=”3.2″ -Dhxcpp=”3.2.102″ -Dhxcpp_api_level=”321″ -Dnme=”5.4.2″ -Dnme5=”1″ –
    Dnme_install_tool=”1″ -Dnme_ver=”5.4.2″ -Dno_console=”1″ -Dopenfl=”2.1.6″ -Dwind
    ows=”1″ -I”bin/windows/haxe/” -I”C:\HaxeToolkit\haxe\lib\hxcpp/3,2,102/” -I”
    C:\HaxeToolkit\haxe\lib\nme/5,4,2/” -I”C:\HaxeToolkit\haxe\extraLibs/” -I
    “” -I”C:\HaxeToolkit\haxe\std/cpp/_std/” -I”C:\HaxeToolkit\haxe\std/”
    Error: Could not guess MINGW_ROOT (tried [c:/MinGW]) – please set explicitly
    Error: Build failed

    nme demo 06 gives the same, and the neon compiles fine but when playing, no sounds and
    Error in music Unrecognized music format (C:t150702NeonVectorcppiaNeonVecto
    Error in music Unrecognized music format (C:t150702NeonVectorcppiaNeonVecto
    Error in music Unrecognized music format (C:t150702NeonVectorcppiaNeonVecto
    Error in music Unrecognized music format (C:t150702NeonVectorcppiaNeonVecto

    in the console.

    I probably missed something obvious though.

  5. I guess the problem with NME is that there is no website providing news of the project and documentation.

  6. Hi. I want to test openfl (legacy) code in NME. How can I quickly set a –remap openfl:nme flag? ( In cmd and in XML ). Thanks

    1. This is already done automatically for you – it remaps openfl and lime to nme. Just type “nme cpp” in your project directory.

  7. Sorry, I see that the remap should be working automatically which it is great. My next question is, is there some documentation for the compiling tools? Last time I checked they were very different to Lime’s. Thanks.

  8. madrazoman, the tools are pretty similar – you should pretty much be able to use the nme tool like you would the lime tool. There are a few more niceties, like assume “test neko” if you do not specify otherwise, and also if you only have one xml or haxe file, it will use this, so often you can just do “nme” in your project directory and it will work.
    You can also build without a project file if you just want a quick test of an single haxe file, and you do not need to clone a demo to test it.
    But generally test/update/uninstall on neko/cpp/android/cppia etc works the same.

  9. Thanks for the post. This sounds very interesting. I’m currently investigating Haxe frameworks like OpenFL and I have two questions:

    1. Lime (OpenFL’s core) uses static mutable class members. I’m in an environment where this is a problem (e.g. because of multithreading and multiple app instances in one process). How is NME in this area?
    2. Is it (easily) possible to have NME reuse a native window handle from outside? I would like to pass in a NSWindow* (or HWND) pointer instead of letting NME open its own window.

    Thanks for your time. Please keep up the good work!

    1. Nme is very similar to lime in this respect. When dealing with different OSs and UI frameworks, a lot of things have to run on a specific thread, and this is the code where you will find most of the static/global values (eg, nme.Lib.current and the fact that DisplayObjects should be manipulated from the main thread) so there is not much point in complicating this code in this case. And since much of the Api is derived from the flash api, a single-threaded model is assumed for things like loading callbacks. However, this should not stop you from using threading in the non-ui code – you just might have to be a bit careful to synchronize to the main thread.
      For point 2, nme offers a “Ios view” and “Android view” targets. These generate libraries that you can then insert into bigger xcode or eclipse projects like components.

  10. Great! Thanks for your help, I think this could work. My concern with static data is not only about threads, but also about the multiple instances in one process. Each instance must have its own window, data etc., but of course all static data will be shared between the instances.

    By the way, I have posted a question about HxCpp here: https://groups.google.com/forum/#!topic/haxelang/bCJpwXFSHUA
    If you have time, any help would be much appreciated 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *