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.

6 Replies to “NME 5.0 (re)Released!”

  1. It looks promosing! I have tested some new feature and works as expect.

    Some question, would u mind give some JNI example to make me know how the new JNI works? the sample code looks broken.

    1. Yes, it does look like the same code is broken. If you have a look in nme/filesystem/File.hx, the idea is that you create a static or member function. You will need the class name and the function “signature”. The signature specification is the standard JNI one. Once you have created the function, you can call it like any haxe function. But you have to be careful about which thread you call the standard ui functions from – will probably need “nme.Lib.postUICallback”.

  2. Hi, I have a question regarding hxcpp.

    I am using OpenGLView and noticed that GL.vertexAttribPointer is creating a bunch of GC objects. Looking in OGLExport.cpp it seems that the problem is that xxx_gl_vertex_attrib_pointer uses a lot of “val_int”s. Is this correct?
    I wonder if there is a way to get a static or const (inline) “val_int” that does not generate a GC object.
    Or as alternative, a way to inject directly OpenGL code. Tried with

    untyped __cpp__(…
    on an inline function, and (for Windows)

    @:headerCode(‘
    #pragma comment(lib, “opengl32.lib”)
    #include
    ‘)
    But a bunch of errors appear

    Thank you very much

  3. OK, solved this issue. It has nothing to do with the “val_int” but I believe that it is the fact that it is a “DEFINE_PRIM_MULT” type of function (it has more than 5 parameters). Defining my own function (DEFINE_PRIM) with 4 parameters, knowing that Type will be always GL.Float and Normalized=false, solves the issue.
    I wonder if we can have this kind of variations that extends the OGL API as official in NME (to avoid “DEFINE_PRIM_MULT” functions)?
    Thank you very much

Leave a Reply to Litao Cancel reply

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