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.

This entry was posted in flash, linux, neash, neko, nme and tagged , , , , . Bookmark the permalink.

40 Responses to Hxcpp 0.4, NME 0.9, Neash 0.9 Released!

  1. Mason says:

    Great job, I’m looking forward to trying it out!

    Unfortunately I keep getting the following error with MS Visual Studio 9.0 express:

    Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
    Copyright (C) Microsoft Corporation. All rights reserved.

    cl -nologo -I”C:\haxe\lib\hxcpp,4/include” -Iinclude /EHsc -c -Zi -O2
    src/__main__.cpp -Foobj/__main__.obj
    NMAKE : fatal error U1077: ‘”C:\Program Files\Microsoft Visual Studio 9.0\VC\bin
    \cl.EXE”‘ : return code ‘0xc0000135’

    Any idea where I’m going wrong?

  2. Huge says:

    I think the problem is that the compiler path is not setup correctly for the command line.
    Try running VCVARSALL.BAT first.
    See http://msdn.microsoft.com/en-us/library/x4d2c09s(VS.80).aspx

  3. Bravo!! Your work is GREATLY inspiring and could change this industry!

  4. makseiz says:

    Tried to compile an haxe program using the process class and got an error.
    the implementation of lazyload, haxetoneko and nekotohaxe is missing.
    how can i implement them?
    can you drive me?

  5. Huge says:

    Unfortunately, I have not ported the neko.io.Process class to hxcpp yet. The porting is not too difficult – it basically involved using the neko code, but changing the way some things are used, but I have not get there yet. On hxcpp, there is note need for haxetoneko or nekotohaxe, since the same “Dynamic” class is used. Also, with strings, you do not need to pass the “__s” of the string in, just the string itself. When you get the string in the c code, keep in mind that it is a “wchar_t” string, not a char, so some conversion may be required.
    In the next version of cpp, you will not be able to include neko classes that have not been properly ported, so some of this confusion may go away.

  6. Hey,

    Why is the hxcpp dynamic library (hxcpp.dylib on Mac) needed for NME?

    Well, I installed ‘hxcpp’ for other reasons, but I fail to see how that is needed for proper Neko use of NME.

    The error I get when not adding that dylib to DYLD_LIBRARY_PATH is:

    Uncaught exception – load.c(232) : Failed to load library : /usr/lib/haxe/lib/nme/0,9/ndll/Mac/nme.ndll (dlopen(/usr/lib/haxe/lib/nme/0,9/ndll/Mac/nme.ndll, 1): Library not loaded: hxcpp.dylib
    Referenced from: /usr/lib/haxe/lib/nme/0,9/ndll/Mac/nme.ndll
    Reason: image not found)

    But, with that dylib added, I do get greatness 🙂


  7. Huge says:

    You are right – it should not be required. There must be a mistake in the makefile when building the ndll. I will have to look at it.

  8. Fedor says:

    Great tool.

    It has problems when converting HaXe type or functions which name is keyword in C++. For example,

    public static function bool( a : Value )

    is correct in HaXe, but it gives

    static Dynamic bool( format::amf::Value a);

    which is incorrect in C++.

    Of course, I can change source to

    public static function bool_( a : Value )

  9. Fedor says:

    Other issue:

    when arguments have type Void

  10. Huge says:

    C++ keywords will be better addressed in the next release (auto renaming). I have also fixed “Void” to be an actual type (the “null” type) rather than the C++ “void”. This fits better with haxe. Thanks for your comments.

  11. Fedor says:

    Other issue:

    cl -nologo -I”C:/Program Files/Motion-Twin/haxe/lib/hxcpp/0,4/include” -Iinclude /EHsc -c -Zi -O2 src/neko/Sys.cpp -Foobj/neko-Sys.obj
    src/neko/Sys.cpp(27) : error C2065: ‘__dollar__loader’ : undeclared identifier
    src/neko/Sys.cpp(27) : error C2227: left of ‘->__Field’ must point to class/struct/union/generic type
    type is ”unknown-type”
    src/neko/Sys.cpp(27) : error C2228: left of ‘.Cast’ must have class/struct/union
    src/neko/Sys.cpp(27) : error C2059: syntax error : ‘)’
    src/neko/Sys.cpp(28) : error C2065: ‘__dollar__tarray’ : undeclared identifier
    src/neko/Sys.cpp(28) : error C3861: ‘__dollar__typeof’: identifier not found
    src/neko/Sys.cpp(32) : error C3861: ‘__dollar__asize’: identifier not found
    src/neko/Sys.cpp(34) : error C2065: ‘__dollar__tstring’ : undeclared identifier
    src/neko/Sys.cpp(34) : error C3861: ‘__dollar__typeof’: identifier not found

  12. Huge says:

    Your are getting this error because you can’t use neko.Sys from the cpp target (yet). In this version, I allowed the use of all neko classes because I used some of them in cpp, so the compiler is not giving you the correct warning “you can’t use neko classes in cpp”. I will fix this in the next version (and implement replacements for neko.Sys).

  13. Bader says:

    I love it (together with the iPhone haXe this will be awesome.. it’s like.. like.. multi-platform Flash 🙂

    Do you expect to wrap this up so nicely that even regular ActionScript developers can use it? I mean: i don’t know anything about C++, static vs dynamically linking and such like, but i certainly would like to use my l33t ActionScript skills on the iPhone (Objective C is a b**** imho, so is X-Code). Something you can add a command for in Eclipse and then insta-run your project?

    I’m also quite interested in the performance: does it (or do you expect it to) run faster when compiled to C++ and then to Win PC (vs a Flash Projector .exe)?

  14. Forwolk says:

    This is great, however I am getting the same error as Mason. After I have set all the Classpaths as described here.

    Flash develop gives me:
    C:\Users\forwolk\Documents\FlashDevelop\HaxeTest\New Project\src\cpp>nmake -nologo
    cl -nologo -I”C:\hxcpp04\release/include” -Iinclude /EHsc -c -Zi -O2 src/__main__.cpp -Foobj/__main__.obj
    NMAKE : fatal error U1077: ‘”D:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.EXE”‘ : return code ‘0xc0000135’

    I have already tried rerunning VCVARSALL.BAT with admin rights, but it’s still no use.
    Os – Windows 7.

  15. Huge says:

    Hi Mason,
    I’m not too sure about this one – I think it’s to do with 32bit vs 64bit dlls in you exe path. Can you simply run cl.exe from the command line instead of nmake? I’ve heard of a few people with problems like this, and I’m pretty sure it’s to do with command line / exe_path setup. In the next version I’m hoping to use project files instead of command line to get around this problem.

  16. Simon says:


    I’ve compiled and successfully build my first pure haxecpp file, but when I want to add more functionality, specifically anything to do with neash I get an error when I try and run the executable (on a mac)

    Error : could not load module nme.dylib

    I’ve tried setting DYLD_LIBRARY_PATH to solve this, but to no avail, is there any insight please ?

    export HXCPP=”/usr/lib/haxe/lib/hxcpp/0,4″

    export DYLD_LIBRARY_PATH=”:$HXCPP/bin/Mac:/usr/lib/haxe/lib/nme/0,9/ndll/Mac:”

  17. Huge says:

    Hi Simon,
    There are a couple of things that may be going on here. Firstly, the nme.dylib file may not be binary compatible with your system – ie, some binary API/ABI is different. Or 2, it may not be able to find the library. You could try copying the nme.dylib file into the directory with your exe. If this works, this it may be to do with the path.

    To debug this stuff, you can set certain environment variables to see what is going on a bit better. Try DYLD_PRINT_LIBRARIES for some basic stuff and DYLD_PRINT_BINDINGS for some more detailed stuff. If you see the nme library getting loaded, and then unloaded straight away, it could be because some dependency is missing. Let me know what you find, and I’ll offer some more suggestions.

  18. Amanita says:

    Hi, again. I’ll try to lunch Simple and got next:
    amanitas-macbook:cpp Amanita$ ./Simple
    Error : could not load module nme.dylib
    amanitas-macbook:cpp Amanita$
    I copy all needed libraries in the same directory, export needed path and DYLD_LIBRARY_PATH – and nothing help. Why?

  19. Amanita says:

    I made all from: “To debug this stuff, you can set certain environment variables to see what is going on a bit better. Try DYLD_PRINT_LIBRARIES for some basic stuff and DYLD_PRINT_BINDINGS for some more detailed stuff. If you see the nme library getting loaded, and then unloaded straight away, it could be because some dependency is missing. Let me know what you find, and I’ll offer some more suggestions.”

    Can send u the log. And if the “the nme.dylib file may not be binary compatible with your system” what can I do to resolve this problem?

  20. Huge says:

    Hi, if the nme.dylib is not compatible, then you will probably need to compile it yourself. Although, I would like to sort this aout to save other people pain. Could you please email me the logs at “huge” at this domain name.

  21. Amanita says:

    I sent the logs with compiling Simple.a. If you need more information – let me know. Thanks.

  22. Huge says:

    Hi, just a quick question – do you have SDL runtimes installed? I think I left the Mac NME with sdl dynamic linking (hope to fix this soon). You can install the latest SDL for mac from sdl.org. If this fixes your problem, I know what I have to do – statically link NME.

  23. Fedor says:

    I have downloaded latest HaXe from CVS and latest hxcpp. Tried to execute
    haxelib run hxcpp Build.xml haxe -Ddebug -Dcpp -Ddebug -Dhaxe_203 -Dtrue
    – got
    “invalid field access : __s”
    probably string equals to null – changed code of the EReg.hx (just added check for null) – other error:

    Called from line 1
    Called from BuildTool.hx line 476
    Called from BuildTool.hx line 215
    Called from BuildTool.hx line 231
    Called from neko/io/File.hx line 42
    Uncaught exception – [file_contents,Build.xml]

    Downloaded latest Neko from CVS, compiled – the same error.

  24. Huge says:

    Hi Fedor,
    Although this is in a state of flux, what you have should work. Is the Build.xml file being generated in your cpp directory? What OS are you on, and what directory did you specify with “-cpp” (i’ve only been testing -cpp cpp)? Also, with the EReg, is it that OSTYPE is not set? I’d like to get this fixed before release. Thanks for reporting.

  25. Fedor says:


    I use windows xp. Build.xml is generated. Forgot to say that I have added line at the end of the Build.xml
    – without that it have complained that no compiler defined.

    Yes, OSTYPE is not set:
    Called from line 1
    Called from BuildTool.hx line 448
    Called from EReg.hx line 89
    Uncaught exception – Invalid field access : __s

    I used “-cpp cpp”

    Changes in EReg.hx was simple
    public function match( s : String ) : Bool {
    if (s == null) return false;

  26. Huge says:

    Thanks Fedor, I have defaulted the OSTYPE to windows. I’m not sure whether the EReg should throw or return false.

  27. Fedor says:

    Tried to compile with last version from svn.
    Next errors:
    1. Not found hxFieldMapCreate, uncommented the ones in hxObject.h
    2. hxGC.o : error LNK2019: unresolved external symbol _GC_remove_roots referenced in function “void __cdecl hxGCRemoveRoot(class hxObject * *)” (?hxGCRemoveRoot@@YAXPAPAVhxObject@@@Z)

  28. Huge says:

    Fedor, I just submitted fixes for these issues.


  29. Fedor says:


    I have problem with next simple example:

    package ;

    enum EnumWeek {

    class TestEnum {

    static function EnumWeekToInt( c ) : Int {
    return switch( c ) {
    case Monday: 1;
    case Tuesday: 2;
    case Wednesday: 3;
    case Thursday: 4;
    case Friday: 5;
    case Saturday: 6;
    case Sunday: 7;

    static function getDays() : Array {
    var a = new Array();
    for( kname in Type.getEnumConstructs(cast EnumWeek) ) {
    var EnumWeek_obj = EnumWeek;
    var k = Reflect.field(EnumWeek_obj,kname);
    a[EnumWeekToInt(k)] = k;
    return a;

    static var HKINDS = getDays();

    static function main() {



  30. Huge says:

    I will have a proper look at this later, but it could be to do with the name of your variable. Internally, I use “ClassName_obj” in the c++ code – so it looks like you may have hit on a name clash here. Try changing the name of your “EnumWeek_obj” variable. I will have a think about a proper fix for this.

  31. Fedor says:

    It compiles OK. I have problem during execution, problem in next:
    after line
    var k = Reflect.field(EnumWeek_obj,kname);

    k is equal not to “Friday” but “iday”.

    Type.getEnumConstructs(cast EnumWeek) returns cutted strings “nday”, “esday”, …

  32. Huge says:

    Hi Fedor,
    I’v looked at as couple of systems and do not see this bug. Are you running 64-bit OS and compiler? I have just made a minor modification to hxMacros.h that may fix your problem. Let me know if the problem persists.
    If you feel like it, you could also try replacing the string macro with:
    #define STRING(s,len) String(s,len)
    and see if that fixes it.

  33. Fedor says:


    I’m running Win32 and VS2008. After internal errors I’m using intel compiler for VS2008.

    Checked with standard VS2008 compiler – TestEnum does not generate that error, but intel compiler (icl.exe) produces it.

    Standard VS2008 compiler still have internal error on more comples projects.

  34. Fedor says:


    I think that in “runtime\libs\std\Thread.cpp” in method
    static value thread_create( value f, value param )

    error near the end:

    return p->t->v;

    should be changed to

    return v;

  35. Huge says:

    Thanks Fedor you are certainly correct. I have fixed the source code, and will get the binaries sorted later this weekend.

  36. Joacim says:


    I’m having some trouble running the binary compiled by hxcpp. I get “Error : Could not load module nme@nme_filter_image__2” when trying to run my own code or any of the samples included.

    I tried both setting DYLD_LIBRARY_PATH and copying nekoapi.dylib and nme.ndll to the same dir as the binary. No luck.

    I also tried setting DYLD_PRINT_LIBRARIES and DYLD_PRINT_BINDINGS, but can find no references to nme or neko whatsoever.

    The neko version compile and runs fine.

    Any ideas what might go wrong?

    I’m running OS X 10.6 och hxcpp 1.0.7 (and haxe 2.0.4)


  37. Huge says:

    Hi Joacim,
    Is your system 64-bit? Your cpp code may have been compiled as 64 bit, in which case it will not be able to load the 32-bit ndll files. I think the easiest fix in this case would be to add a flag to force 32-bit compiles.

    I have not tried this, but you can try this out in the “BuildCommon.xml” file in the “build-tool” sub-directory of your haxelib hxcpp distribution.

    in the MACOS section that starts with:

    <compiler id="darwin" exe="gcc" if="macos">

    Add the line:

    <flag value="-m32"/>

    Also, you can debug the HXCPP loading by setting the HXCPP_LOAD_DEBUG environement variable.

  38. Joacim says:

    Thanks Huge, setting the -m32 flag did the trick!

    I also had to set the -m32 flag in the linker sections below to avoid “file is not of required architecture” errors from g++.


  39. Huge says:

    Joacim, thanks for reporting that. I’ll fold this logic into the next release.

  40. Joshua Granick says:

    I also am receiving the “Error: Could not load module nme@nme_filter_image__2” error. I’m publishing it to a phone (similar to iPhone), where all the code is linked together. Is it possible that this is a pathing issue, once its linked together, or why wouldn’t it find this module?

    Thank you for any help!

Leave a Reply

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