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]( 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 []( 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:/”. From a shell in this directory, follow the instructions on project page about how to checkout the svn version:

svn checkout 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:/” etc. Now you can point your neko at this new code using the haxelib command:

haxelib dev nme c:/



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).

Announcing Neash

I have renamed the “blink” project to “neash” (_ne_ko fl_ash_) and made a project page for it on


You will need the neko/dlls from the new This has “blink” renamed to “neash” and I think I’ve fixed a bug in the font stuff that caused a crash on vista.

You could also use the new stand-alone exe (with font fix), and checkout the same demos with the fix too.




Speaking of stand-alone neko executables, the first half of the tutorial below is already covered the project [“xCross”](, which is cross platform,integrated with haxelib and includes regexp. So that is worth knowing about.

Stand-alone Neko

Did you know you can bind a neko “.n” file to the neko exe to create a stand-along exe? Well you can, with the “nekotools.exe boot” command. This simply appends the “.n” file to the standard neko.exe, and adds a small footer, giving you an executable that you can run. This is all well and good, except that you will also need to distribute the “.ndll” files, and place them correctly (usually, next to your exe) so that the dynamic loader can find them. This is also not that hard, but is there is an even simpler, single file solution, with no chance of picking up a wrong or development version. The trick is to build a statically linked version of neko.

To do this, you are going to need to compile the source code yourself. I will be using here Visual Studio 2005, express edition because I am tight and it is free. Start by downloading the source from []( Currently, neko is at version 1.6.0.
Unpack it and your will get a directory like “neko-1.6.0”, which has sub-directories like “libs” and “vm” in it. I will call this directory “the neko directory”, NEKO. You will also need the garbage collector, “gc”. You can download it from []( Unpack it, and you will get a directory called something like “gc6.7”. Now this is something I’ll be doing with all the extra packages we will be downloading: rename the directory to have no version number, and move it to somewhere in the NEKO/libs directory. ie “NEKO/libs/gc”.

Now start a new empty visual studio project. Set the location to NEKO, so the path names can be relative. I’ve called mine “neko-static”. Untick the “Create directory for solution” (because I hate this option). Exit visual studio and move the “.sln” and “.vc_proj” files out of the “neko-static” directory that VC created against your will into the NEKO directory. (my second most hated feature of VC). Now remove the neko-static directory, and launch the neko-static.sln file. You can leave it in the default location if you wish – I’m just old and stuck in my ways.

Expand out the neko-static folder and add existing items to the Source Files : all the “.c” files from the vm directory, except “gc.c”. (gc.c is not needed since we are using the gc lib).

At this stage if you try to compile you get a bunch dll linkage errors. To get around this, you need to add the -DNEKO\_SOURCES deines, so right-click the project, set the configuration to “All configs” instead of “Active” (THE FEATURE I HATE THE MOST – one of the reasons I prefer makefiles) and in the c++/Preprocessor/Proprocessor Definitions add “NEKO\_SOURCES”. This says we are building and exporting neko, not importing a dll.

If you compile now, you will get an error in alloc.c finding gc/gc.h, because it is in the “include” directory, not the base. I think the easiest way to fix this is to edit alloc.c to #include “libs/gc/include/gc.h”.

Now you get a bunch of “\_\_imp\_\_GC\_ …” undefines. This tells me that we are using the dynamic import version for gc, so also change the #define of “GC\_DLL” to “GC\_NOT\_DLL” in vm/alloc.c. Now we get the static versions undefined, which is what we want – fix this by creating a sub-folder in the project “Source Files” called “gc” and add the files:
allchblk.c alloc.c blacklst.c checksums.c dbg\_mlc.c dyn\_load.c finalize.c headers.c mach\_dep.c malloc.c mallocx.c mark.c mark\_rts.c misc.c new\_hblk.c obj\_map.c os\_dep.c ptr\_chck.c reclaim.c stubborn.c typd\_mlc.c win32\_threads.c.
*Hint: instead of using the “Existing item” dialog from the project, you can keep an explorer window open and drag in the files you want*.

I initally made the mistake of putting “gc\_cpp.cpp” in the project. This overrode the “new” operator and sent eveything through gc. It worked,
but was much slower (you could hear the hard drive grinding) (Edit:maybe it was the log file ?).

And add to the project the include directory “../libs/gc/include/” from the project properties (don’t forget my most hated feature) in c++/General/Additional Include Directory.

Now there are only a couple of errors. In builtin.c, comment out the “\_ftol2” function. Add the defines :GC\_NOT\_DLL;GC\_WIN32\_THREADS,
and add the “Linker/Input/Additional Dependencies” user32.lib. While you are there, add \_CRT\_SECURE\_NO\_DEPRECATE to the defines, and
4996 to the Advanced/”Disable Specific Warnings” for more reasonable output.

I now have a “Debug/neko-static.exe” that can be run. Not that it will do us much good, because it has no libraries, and crashes on:

class Test
   { public static function main() { neko.Lib.print("Hello static world.\n"); } }

because it finds the “std.ndll” from NEKOPATH. Because it is statically linked, it will not work properly with any extenal ndll files.
We can get around this with a simple trick. In “load.c”, instead of using

h = dlopen(val_string(pname),RTLD\_LAZY);


h = GetModuleHandle(0);

This is quite neat, because any “\_\_dllexport” functions will be accessable will be visible from the exe module.

Now the program just fails because there is no std library. Fair enough – just add one: Create in “Source Files” filters “libs” and “libs/std”, and
add all the .c files from libs/std. “neko.h” is not found, so add “vm” to the include path (DFMHF), and add “wsock32.lib” to dependencies. Also, comment out “_ftol2” from math.c.

Now build – hey presto a stand-alone neko exe!

One more trick – before adding the “.n” bootstrap onto the end, compress the exe using the rather satifying exe-packing program, [upx]( You need to do this first, because the script will be read from the original file on disk, not the decompressed image in memory.

So you get:neko-static-upx.exe that you can use as a base. To build an exe, you can use the “nekotools.exe boot -b neko-static-upx.exe Test.n”. If neko has trouble finding the exe, place it in the $NEKO\_INSTALLPATH directory. This exe should run anything that uses only the “std” library (sadly not “regexp”).
There is one bug with this build, it generates “gc.log” files. I will have to track down the flag to disable this.
So witness my opus:


*Note: Now, I’m no lawyer (as all good legal opinions start), but all the code here will be using the LGPL license (or more liberal). My understanding is that the spirit and letter of the law means that if you compile with LGPL code, you should give everyone the right to __RELINK__ your code with a different version of the LGPL code. Normally this is done with DLLs, since this is simple. In this case, it is being done with the “.n” file you are embedding. ie, there is no reason why someone could not relink your exe using the excact same procedure above. You do not need to give them your haxe source code, only your “.n”. However, it does mean you can’t do any tricky hidden DRM stuff in the exe, without surrendering the appropriate “.obj” file.*

“Harr”, I hear you say, “that is satisfying”. But wait, there’s more.


Wouldn’t it be cool if you had a simple base you could use for all your gaming? Well, it can be done. To statically link against NME, you need to gird your loins and download the following packages:

– SDL-1.2.12.tar.gz
– SDL_mixer-1.2.8.tar.gz
– SDL_image-1.2.5.tar.gz
– SDL_ttf-2.0.9.tar.gz
– libogg-1.1.3.tar.gz
– libvorbis-1.0.0.tar.gz
– freetype-2.3.5.tar.gz
– pcre-7.4.tar.gz

I ran out of steam and just commented out the “sge” library bits, and stopped at ogg audio (untested) (sorry Lee).

If you are not interested in gaming , the regexp bit may still be appropriate.
I extracted the pcre library to libs/regexp and renamed it “pcre”, and the “hand configured” by

cp  pcre.h.generic  pcre.h
cp  config.h.generic  config.h
cp pcre_chartables.c.dist pcre_chartables.c

Added ‘#include “config.h’ to top of pcre.h and removed “HAVE\_DIRENT\_H” define. I then added the c files (skipping the example files that define a “main” function) as well as “libs/regexp/regexp.c” to the project in a sub-folder.

I copied the NME source files from the “project” folder of the “haxelib” version of NME. I then added some extensions for blink, and commented out the sge stuff because there are only so many libraries you can add in an evening.

I created an “sdl” directory in the NME directory (should have probably stuck it next to it) and extracted all the above libraries and renamed them without their version numbers. I then painfully selected source files from these libraries for the project. Some things to note:

– #define OGG\_MUSIC from the project properties.
– #define \_WIN32\_WINNT=0x400 to get TRACKMOUSEEVENT
– Added each of the packages somewhere in the include path, eg: libs/nme/sdl/SDL/include libs/nme/sdl/SDL\_image libs/nme/sdl/SDL\_mixer etc.
– Added SDK path the get ddraw.h (additional download required for VS express edition)
– #define FT2\_BUILD\_LIBRARY to say we are building it, not using it.
– When adding files from freefont, you only need to add one from each “driver”.
– I commented out the “GC_write” function to try to stop the log.

When compiling modules with “DEFINE\_ENTRY\_POINT”, you get a multiply defined symbols. So I commented these out (could probably have done something in the header), and added specific calls to these boot routines in vm/main.c.

There, if you are still awake, you have it. The final output is the base: neko-nme-upx.exe(615k) which will run the BlinkDemo “.n” files (and any standard program that uses “std” and “regexp”) without and additional help. And see the stand-alone programs:

robotdemo.exe (765k)

cardemo.exe (760k)

Plenty of stuff still to be done, such as “subsystem:windows”, more audio, sge etc, but
I think this is an excellent way to deliver games (or utilities for that matter), without fear of DLL hell. It also sidesteps “manifest hell” that microsoft seems keen on inflicting on us by insisting that the vc8 dynamic runtime is installed in a central location. I think the logic goes “if .net apps have to have a separate runtime installer, every one has to too”. What a stupid solution to force when the simple “just put the dll in the application directory” has worked for decades. (sorry about the rant).

It runs faster, too!

Cross-platform again

So far, I’ve mostly looked at the flash/swf version but now I will return my attention to cross-platform development.

There are a number of existing libraries that can be used with haXe, but most of these are low level, but what I’m after is a higher level option. So the plan is to build a higher-level layer on top of an existing module. I have chosen to build on top of NME, which is SDL based. My decision was mainly to do with support for opengl, sound/music, font, input and screen management.

In the end, the design wrote itself, based on the simple rule “it should be easy to port something from existing flash code”. Initially I tried writing a substitute library called “flash”, but the haxe compiler rejected me. This is probably best, because, although the alternative requires slightly more porting for the flash case, I think it allows for greater possiblities of minor architectural changes. This has two big advantages – half the work is already done for me and there is an excellent design document for the rest.

The result is a library I have called “blink”. There is essentailly one blink class definition for each flash class. On the flash platform, a simple “typedef” is used to get exactly the same code as native flash. On the neko platform, there is a haxe implementation that ultimately falls through to an NME call.

The library is only at the demo stage, and only implements enough to get the APE demos off the ground, but I think is shows the possibility. The only changes required were to change “flash.” to “blink.”, modify the main-line boot function slightly and make sure to use cross-platform constructs (eg, no “__as__” casting).

The code here ( shows the same code compiled for flash and neko. It uses a slightly extended NME library, which is provided as a dll in the bin directory – to use the dll, make sure you run the neko.exe in the bin directory so it finds the right one.

The updated performace is (note:using “cast” not “as”):

Car Demo Robot Demo
Original 2.0ms 9.5ms
haXe 1.58ms 9.45ms
hx->as3 1.56ms 9.47ms
neko/nme 4.0ms 16.9ms

On first glance it would appear the numerical processing takes about twice as long under neko as it does under flash. However this code might not be the greatest test because we can see how the performance of the “cast” command can effect the results.

Also of note is that the graphics is quite capable of reaching 100fps, so I do not think the SDL code will be a bottleneck.

I am very pleased with this approach, and I think it might be the way forward for cross platform game development. In some ways (certain) games are easier because they use a generally smaller sub-set of graphics primitives – mostly image drawing.