JavaScript – ready or not.

JavaScript Performance

There have been some very promising improvements in JavaScript performance, but exactly how good is it? It turns out, that there is a pretty easy way to work this out – thanks to haxe.

Haxe allows the same code base to be compile to Flash, JavaScript, neko and cpp. The graphics is handled differently – Flash uses its plugin, JS uses canvas and neko is using the NME library, running opengl. To compare these, I’ve chosen the Physaxe library, which is optimized for all these platforms, and can give a feeling for an app that has a computational and graphics load.

Into this mix, I will add another interesting option: The V8 JS engine, running using the NME library in opengl mode. This cross-over mode is actually quite easy to implement because of 3 stars aligning: 1. The NME library has a external interface that uses opaque handles that map very naturally to the v8::Value *. 2. The haxe compiler makes it possible to program JS without losing your mind, and all the existing library code is valid for this target. and 3: The Google V8 JS engine has a clean API that makes it easy to embed (you would almost think they designed it that way – dispite the frugal documentation).

The benchmark I have chosen is the “Pentagonal Rain”, which is nice and stressful for the CPU. You can try for yourself – use the ’5′ key to switch to this demo.

• JavaScript Canvas
• Flash
• Win32 Binaries (Neko, V8VM, CPP-compiled) (extract and drag the “.n” file onto neko.exe, or drag the “.js” onto the v8vm.exe)

So as you can see, the V8VM option is actually quite viable as a scripting vm. Since there is a lot in common between neko, v8vm and cpp haxe targets and plugin architectures, it should be relatively straight forward to switch between them.

The JS demo can run on the iPhone. But just because you can do something, it doesn’t not mean you should – at about 2 FPS on the title screen, I can’t imagine how slow it would run in the Pentagonal Rain demo. And probably not great for your battery either

FastCGI For Neko On Share Hosting

In my previous post, I described you could setup neko web services on a shared host, using CGI. This method is not as efficient as it might be because a separate process is required for each request. However it is possible to extend this to “Fast CGI” (FGCI), which starts a single process, and keeps it alive. Apache talks to this over a socket, sending requests and receiving data and a very efficient manner.

If you got CGI working, and your server supports FCGI, then the transition on pretty simple.

The first thing to do is to download the new “fastcgi” haxelib. From a shell use:

haxelib install fastcgi

If haxelib asks you for a project directory, the following discussion assumes you specify your “haxeneko/lib” directory. There is one bit of housekeeping you should do at this time – copy the “nekoapi.dso” object from “~/haxeneko/lib/fastcgi/0,1/ndll/Linux” into your “~/haxeneko” directory. This ensures that this dso will be found when neko is run by the web server.

Now it is time to change the cgi script. The code is very similar, except the extension should be “.fcgi”. Here is the script I used Site.fcgi:

#!/bin/sh
export HAXENEKO=~/haxeneko
export LD_LIBRARY_PATH=$HAXENEKO
export PATH=$PATH:$HAXENEKO
export NEKOPATH=$HAXENEKO
export HAXE_LIBRARY_PATH=$HAXENEKO/std
cd ../../site
exec neko SiteFCGI.n

Note the final “exec” call to ensure the pipes are all correctly plumbed. And the obvious change to the .htaccess file (.fcgi extension):

RewriteEngine on
RewriteRule \.(css|jpe?g|gif|png)$ - [L]
RewriteRule ^(.*)?$ cgi-bin/Site.fcgi [L]

Finally, compile the “Test.hx” file that came with the fastcgi lib. I have a slightly altered version here:

class Test
{
   static var processed = 0;
   static public function main()
   {
      // Called in single threaded mode...
      fastcgi.Request.init("");
      // This can be called multi-threaded...
      var req = new fastcgi.Request();
      while( req.nextRequest() )
      {
         req.write( "Content-type: text/html\r\n" +
            "\r\n" +
            "<title>Neko FastCGI<title/>" +
            "<h1>Fast CGI</h1> Requests processed here: " + (processed++) );
         req.write( "\n page = " + req.getParam("REQUEST_URI") );
         req.close();
      }
   }
}

This version prints the request uri too. To compile, use: haxe -main Test -neko SiteFCGI.n -lib fastcgi

And that should be that! When you visit your web page, you should see the “processed” counter increase, verifying that it is the same process that is running.

Currently the system does not support easily killing the FCGI process, which is something that you must do when you update the “.n” neko file. The only way at the moment is to use the shell to do “ps -x” to identify the process number, and then “kill -9 number”, where number is the process number of the neko executable.

Neko on Shared Hosting

I started to think about using neko web technology, but since I have shared hosting, it was not obvious now this could be done. Currently I’m with site5.com, which is very cheap for running multiple websites, but since it is shared hosting, you don’t get to install anything. However, it does have few features that made getting a neko site up and running quite possible. The key features are:

1. Shell access – not really required if you can copy files to the site (eg, via ftp) but very useful for debugging and getting things going. The shell I have is “jailshell”, which I think prevents directory listings outsite your home directory, but otherwise is pretty functional (based on bash).
2. gcc access – again, not really required once things work, but as you will see, pretty much required if things go wrong. And also good if you want to compile a c++ target!
3. CGI access. Since we can’t modify the apache installation, the only way we can get our code to “run” is via and external process – this is what cgi is for. I will talk a bit about “fast-cgi” later (once I get it going).

First thing is to check you have cgi access. When I first set up the site, I have nothing but an empty “cgi-bin” directory. To test this create a file “test.cgi” in there containing:

#!/bin/sh
echo "Content-type: text/plain"
echo
echo "Hello from CGI!"
set

If you get a “500 – server error” at this stage, it must be fixed. The error is spectacularly unhelpful – not sure where to find the additional error info. Start by trying to run the file from the command line, ie type “~/www/cgi-bin/test.cgi” (assuming this is where your script is located). You should see the output, or perhaps a better error message. Also check for “execute” permission for “all”, as the apache server will run this script with limited privileges. Finally, make sure you have specified a “Content-type” and an additional blank line in the output.

Ok, now we have cgi working! Next step is neko – and haxe too since I will be doing some compiling on the server to help with testing. Haxe is not strictly required if you are deploying pre-compiled solutions.

The hard way

As I said before, you can’t “install” anything on the shared host (no package managers, so it all has to go in your home directory. First thing I did was to download the linux binary distro from nekovm.org. This is easy with the magic “wget” shell command. With your desktop browser, go to the download page and find the link – right click and “copy” the link address. Then go the the shell (putty) window and then paste the link in so you get something like “wget http://nekovm.org/_media/neko-1.8.1-linux.tar.gz?id=download” – hey presto a gzipped-tar file (may have a funny name -that’s ok. Try to use “tab” for tab-complete the filename to save typing). Make a suitable directory and “tar xvzf file” the file to extract the neko files. Now go to the directory and try to run neko. (ie, “./neko”).

You will probably get an error like “libneko.so not found”. But it’s right there, wtf? So you need to set you LD_LIBRARY_PATH (“export LD_LIBRARY_PATH=~/dir/neko-1.8.1-linux”).

Ok, now you get libgc.so.1 is missing, which indeed it is. The easiest way I found to fix this was to use wget to download the source from “http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc.tar.gz”, unpack it, “./configure” it and “make” it. You end up with the required libgc.so.1 file in the “.libs” directory, which I then copied to be next to the neko executable. And now “./neko” works – apparently. I will save you the suspense – you also need to do the same thing with “libcpre” from “http://sourceforge.net/projects/pcre/files/pcre/7.9/pcre-7.9.tar.gz/download” – I use the 7.9 version, not sure if 8.0 works. This is required for haxelib later.

See, I told you that compiler access would come in handy.

Ok, neko done, time for haxe. Again the installer is not much use, so I downloaded the binaries from “http://haxe.org/file/haxe-2.04-linux.tar.gz”, however when I went to run this, I found the “tls” library required a GCC 2.4 runtime, which I did not have, and could not up grade. So – you guessed it linux fans, compile from source. One small hump to get over first, haxe requires ocaml to compile. Of course, ocaml is not installed, but if you are still with me at this stage you know the answer – compile from source. So “wget” it, and here is the trick – make a ocaml directory in your home directory (or somewhere under it), extract the source and use “./configure -prefix your_ocaml_dir” – this provides the “install” directory, since ocaml can’t be used without installing it. The the make is 3-phase “make world opt install”, and now you should have a ocaml install. You will need to put this in your executable path before you can think about compiling haxe.

The online doco suggests that you download and run “install.ml”. I tried this, but the cvs timed out. So I ran this on my windows box (already had ocaml installed!), tarred up the result and ftp-ed it over to my site. Painful, but it worked. One thing is that this uses the cvs “head” – anyone know where to get the 2.0.4 source tar-ball? Once I had the source, I commented out the “download” call in install.ml and “ocaml”ed it. And haxe was built. The haxe distro has a “tools” directory under it, and you can build “haxelib” if you have neko setup correctly.

Getting the paths right is a bit tricky, so I decided to simplify things. I made a directory “haxeneko” in my home directory and “cp -r *” the files from the neko distro (including the new gc and pcre libraries) into this new directory. Also, I copied the bin/haxe built executable in there, and haxelib too (once it was built). Finally, I copied (“-r”) the “haxe/std” files from the haxe distro into this directory too. Now I have everything required in the one spot – and you can too!

The easy way

I have saved you the pain, and you can simply download the files from haxeneko-1.0.tgz. So you should be able to “wget” this, untar it and be almost ready. You may run into problems if there is some incompatible library somewhere – in which case, back to the hard way for you!

Finally, we need to set up the paths. Because my hosting provides the “bash” shell, this setup goes in ~/.bashrc. The required “install” is:

export HAXENEKO=~/haxeneko
export LD_LIBRARY_PATH=$HAXENEKO
export PATH=$PATH:$HAXENEKO
export NEKOPATH=$PATH:$HAXENEKO
export HAXE_LIBRARY_PATH=$HAXENEKO/std

You may need to login again for this to work (or you could paste it directly to your command-line), but now you should be ready to compile some code!

Start by creating your site-code in a directory that is not under you www (public_html) folder – I have called mine “site”. And here is a simple example haxe file:

class Site
{
   public function out(inString:String)
   {
      neko.Lib.print(inString);
   }
   public function new()
   {
      out("Content-type: text/plain\n\n");
      out("Hello World!\n");
      out("Page : " + neko.Sys.getEnv("REQUEST_URI") + "\n" );
   }


static public function main() { return new Site(); }
}

which can now be compiled with “haxe -main Site -neko Site.n”, and tested with “neko Site.n” to give:

Content-type: text/plain

Hello World!
Page : null

Alright – I think you can see where I’m going here, but we are not quite there yet. The problem is that the setup variables in the .bashrc file are not used by the apache server. Apparently, you can use “SetEnv” in a .htaccess file to get this to work, but I could not get it to (maybe the module was not enabled). But all is not lost. You can simply use a script to launch neko. Back in the cgi-bin directory, you can replace the “test.cgi” script with a “Site.cgi” script containing:

#!/bin/sh
export HAXENEKO=~/haxeneko
export LD_LIBRARY_PATH=$HAXENEKO
export PATH=$PATH:$HAXENEKO
export NEKOPATH=$HAXENEKO
cd ../../site
neko Site.n

Now point your browser at http://yoursite.com/cgi-bin/Site.cgi, and you should see the glorious neko output:

Hello World!
Page : /cgi-bin/Site.cgi

Now creating a bunch of cgi files is painful, and you do not want users to see this kind of implementation details, so we use one more trick – the almighty “mod_rewrite”.

In your base “public_html” (www) directory, create a file called “.htaccess”, and add the following lines:

RewriteEngine on
RewriteRule \.(css|jpe?g|gif|png)$ - [L]
RewriteRule ^(.*)?$ cgi-bin/Site.cgi [L]

This leaves the css and image files in the www directory, but it redirects all other URLs your neko script, where they show up in your REQUEST_URI. So now if you use the URL “http://yoursite.com/some_dir/file.html?param=abc&other=xyz”, you get the output:

Hello World!
Page : /some_dir/file.html?param=abc&other=xyz

Now the world (wide web) is your oyster – you can parse the URL anyway you like, and generate any output you like.

This certainly gets you up and running with neko on a shared-hosting web server. One problem is that 2 processes are created for every request. I have done a some initial work with the “fast-cgi” interface, and think I should be able to get this going, in which case there should be a big boost in efficiency.

There should also be no reason why you could not compile the site to a c++ native executable. However, this may reduce your ability to use the neko “.n” template system.

Haxe3D C++ Demo.

Nicolas Cannasse has written a 3D engine for flash 10. I have ported this code to neko and c++ using the neash library.

To test the code, first extract the contents of the zip and then look in the bin directory. Double click the h3d.exe or h3d_ogl.bat files to run the c++ version (the h3d_ogl.bat uses opengl, the other version uses the software renderer). You can see the flash version from the .html file (note: you will need flash player 10). You can run the neko if you have the haxelib version of nme installed by running “neko h3d.n”. All the source files are there in case you want to do some mods.

I have changed the mouse-look scheme from the original code to keep things a bit more centred. Move the mouse left/right to spin the objects, move it up/down to raise or lower the camera. You can use ‘w’ key for wireframe and the ‘p’ key for shading effects.

On my faster computer, I get about 100fps for the opengl renderer, 80fps for the software renderer, 40fps for the flash10 renderer, and 1fps for the neko/software renderer. There are some optimisations that could be done for the neash API, but really significant improvements could be gained by moving some of the engine into c++ code.

Currently, it is windows only. You can get it here.

Update:

There were reports of preformance loss in opengl, and I think I may have traced it to excessive texture transactions due to the text in the status panel. To work around this, I have cached the text as glyph bitmaps (doing this was on my todo list) which seems to have helped. (This update is in the svn version of neash). I have also added a command-line switch to use a simple fps counter instead of the status panel. You can try this out with the h3d_ogl_simple.bat command, In the new download.

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.

Usage

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.

Neash/NME

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

ToDo

There is still plenty to do, including, but not limited to:

Hxcpp:

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

NME:

• Add all blend modes
• Add all filters
• Discuss with experts the merits of static vs dynamic linking Mac and Linux.

Neash:

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

Haxe Preloader For Flash – Written in Haxe.

There has been some talk about creating flash preloaders for haxe. However, these methods step outside the haxe toolchain and add some additional complication.

I have come up with a reasonably simple method for creating a haxe preloader in haxe, and then linking to a (very almost) unmodified swf generated in haxe using a small neko program to produce a single file. The neko program uses code from the hxformat project, some of which is provided so you can easily recompile the tool.

Since each original haxe swf contains one frame, the resulting code contains 2 frames. The first frame contains the preloader which waits for the whole file to load and then locates the PreloaderBoot class by name. This class runs the appropriate initialisation code, creating and running the correct “main” class.

For classes that appear in both preloader and the main swf, flash takes the first one – the one form the preloader. This means that both classes will have the same “flash.Lib.current” and (almost) everything will just work.

One complication comes from the fact that the flash.Boot class is given a unique name for each of the swfs. This means flash.Boot class in the main swf is not automatically “new”ed and placed on the stage, and the standard haxe initialisation code is not run. To compensate, we manually set the trace function and call the Boot initialisation code explicitly.

This sounds a little dodgy to me, but it seems to work – I will have to do some more testing.

The “Main” class in the example zip contains a resource to pad it out. The preloaded swf can be seen on it’s own screen. You can refresh to see it loading.

The example code is in haxe-preloader-0.1.zip

All code & data there is public domain, except for the hxformat code, which has its own license. Use at your own risk.

Neash/NME first release

I am pleased to announce the initial version of neash 0.1, that works with the latest version on NME, 0.3.2. Neash allows the same code to be compiled for both the flash virtual machine and the neko virtual machine. NME provides the advanced vector rendering routines to emulate the flash9 API. You can download each of these packages using “haxelib install nme” and “haxelib install neash”.

The image here shows the same code running the the flash player, as well as a native win32 window. The code is in the samples area, and is as follows:

import neash.display.Sprite;
import neash.display.Shape;
import neash.geom.Matrix;

import neash.Timer;

class Clock extends Sprite
{
   var mCx:Float;
   var mCy:Float;
   var mRad:Float;

   var mMinuteHand:Shape;
   var mSecondHand:Shape;
   var mHourHand:Shape;

   public function new(inCx:Float, inCy:Float, inRad:Float)
   {
      super();

      neash.Lib.current.addChild(this);

      mCx = inCx;
      mCy = inCy;
      mRad = inRad;

      var gfx = graphics;
      for(i in 0...12)
      {
          gfx.beginFill(0x603030);
          gfx.lineStyle(0x000000);
          var theta = i * Math.PI * 2.0 / 12.0;
          var cos1 = Math.cos(theta-0.01);
          var sin1 = Math.sin(theta-0.01);
          var cos2 = Math.cos(theta+0.01);
          var sin2 = Math.sin(theta+0.01);

          gfx.moveTo( mCx + cos1*mRad,     mCy + sin1*mRad );
          gfx.lineTo( mCx + cos2*mRad,     mCy + sin2*mRad );
          gfx.lineTo( mCx + cos2*mRad*1.1, mCy + sin2*mRad*1.1 );
          gfx.lineTo( mCx + cos1*mRad*1.1, mCy + sin1*mRad*1.1 );
          gfx.lineTo( mCx + cos1*mRad,     mCy + sin1*mRad );
          gfx.endFill();
      }

      mSecondHand = CreateHand(mRad*0.02,mRad);
      mMinuteHand = CreateHand(mRad*0.05,mRad*0.75);
      mHourHand = CreateHand(mRad*0.1,mRad*0.5);

      var timer = new Timer(1000);
      var me = this;
      timer.run = function() { me.SetHandPositions(); }
      SetHandPositions();
   }

   function SetHandPositions()
   {
      var date = Date.now();

      var hour = date.getHours() % 12;
      var minute = date.getMinutes();
      var seconds = date.getSeconds();

      mSecondHand.rotation = seconds *360/60;
      mMinuteHand.rotation = (minute + seconds/60.0)  * 360/60;
      mHourHand.rotation =   (hour + minute/60.0 + seconds/3600.0) * 360/12;
   }

   function CreateHand(inWidth:Float, inLength:Float) : Shape
   {
      var result = new Shape();
      addChild(result);

      var gfx = result.graphics;

      gfx.beginFill(0x303060);
      gfx.moveTo(0,0);
      gfx.lineTo(-inWidth/2,-inWidth);
      gfx.lineTo(0,-inLength);
      gfx.lineTo(inWidth/2,-inWidth);
      gfx.lineTo(0,0);

      result.x = mCx;
      result.y = mCy;

      return result;
   }

   static public function main()
   {
      neash.Lib.Init("Clock",640,480); 
      neash.Lib.SetBackgroundColour(0xffffff); 

      new Clock(320,240,200);

      neash.Lib.Run(); 
   }
}

Porting this from a pure flash program involves:

1. Changing the “import” commands to replace “flash” with “neash”
2. Also changing from the “haxe.Timer” to the “neash.Timer”, which supports additional options.
3. The “main” routine must call “neash.Lib.Init( )” very early and at some point must call “neash.Lib.Run()”.
4. That’s it!

I’m looking at ways to remove point 1 using some compiler options, but this may not happen. Also note that the command-line for compiling requires “-lib neash” and, on the native platform, also requires “-lib nme”.

The clock example is really just to show timers working. NME runs the game loop as fast as it can at the moment, so timers are a bit pointless to some extent. This may change in the future.

The flash9 api coverage is a little thin at the moment. I have concentrated on flash.display.Graphics, including linear and radial gradients, bitmaps and line styles. However, some supporting things such as events and TextFields, are not well covered. Also note that some things (so far using a colour-alpha as a 32-bit int, eg #ffffffff) are not supported under neko.

Neash is currently only for flash9/neko compiling. Flash8 and JavaScript will only be supported if there is big need for it (basically if someone else wants to do it).

Neash does not have a binary component, so it works on platforms currently supported by NME. Namely windows and linux. Mac support will follow when NME is ported.

Neash was designed initally for games, and so is quite graphics-oriented. Here is an example showing the neash port of the “plotex” haxe module (you can get it with “haxelib install plotex”) running on windows. I’m not sure if this necessarily useful, but it is fun in a dorky sort of a way. One of the porting problems was due to the fact that plotex already supports 3 out of the 4 haxe platforms, so it contains conditional compiles. As a rule of thumb, use neash where you would use flash9. So “#if flash9″ becomes “#if (flash9||neko)”. Another issue was parameters passed from the html to the swf object. These are emulated in neash using command-line arguements. The source code changes can be found here. Note:copyright retained by original author, see plotex website for more details.

Porting NME to linux

So, I decided to try porting NME to Linux. The first thing you do is find an empty hard drive, download an ISO, and off you go, right? Wrong. I did this – but I wanted to keep my windows partition, without risk of rooting it over, so I didn’t over write my MBR. Then, I could not actually boot my linux partition. Eventually I got around this by booting from a rescue CD (I do not, and never will again, own a working floppy driver) and specifying my /dev/sd partition in a bit of a round about sort of way. Anyhow, I got Linux booting (with a little bit of pain per boot – but I could live with this), but then the wireless network did not work. This I could not live with, so I though about resurrecting some crappy old hardware I have lying around, but in the end I sought, and found, an infinitely better solution.

The answer is virtualization! I can’t overstate how much easier this was than actually getting the hardware together. First, I downloaded the free version of vmware’s “player” product, and then the Ubuntu 7.1 virtual machine, that included a dev environment http://jars.de/linux/ubuntu-710-vmware-image-download-english. The reference to “jars” seems to be a java reference, but we wont hold that against them. It “just worked”. I edited the xorg.conf file to change the keyboard to US, (so I could use the ‘|’ key), and that was about it. With only mimimal clicking, the network was fully working, and I could switch to my windows emails etc. This was what I wanted – much better than dual boot. Compiling NME was just a matter of adding the “dev” version of packages (vim, subversion, SDL, SDL_miver, SDL_image, TTF) with the GUI “Synaptic Package Manager”, which also “just worked”.

The download from code.google, via svn, worked easily once I added the “subversion” package.

Then a little makefile to bring it all together. I had to make some code hacks. I don’t know if this is a gcc “bug” or “feature”, but when I tried to call a class member function, that was templated on an int, eg: int x = Class.Member<4>(10); the gcc compiler thought I was using “operator<”, which is a bit of a shame.

I also had a quick go at static linking, via the “.a”s, rather than the “.so”s, but the linker told me I needed a “version section” for one of the SDL symbols, so I gave up.

The image you see is in the top left is of a window, on my windows desktop, running a virtual machine, running ubuntu, running the neko virtual machine, running a neko script linking to the Linux version of NME. And running it very well, I might add.

The only problems at the moment, are text, when a font is not supplied, the “mod” music in the “blox” demo, and OpenGL on my setup. The PNG, JPG, WAV and OGGs stuff all worked first time.

I think I might be able to get the music going, if I get the right plugin dso.

Also, I’m not sure about what “.so” files need to be distributed with the program to resolve all the dependencies. Any SDL linux guru have any comments on this?

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.

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

svn checkout http://nekonme.googlecode.com/svn/trunk/ 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:/code.google/nekonme-read-only/nme/Manager.hx” etc. Now you can point your neko at this new code using the haxelib command:

haxelib dev nme c:/code.google/nekonme-read-only

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