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


Now to enter this code, I used old-school remote ssh shell (using putty) & vi. You may choose to ftp it on use filezilla or similar. You will also need to add executable permission (chmod a+x test.cgi for ssh, not sure how to do this via ftp). You can then test it with yoursite.com/cgi-bin/test.cgi. With any luck, you should see the expected greeting, plus the “set” command should dump all the environment variables available to your application.

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.

Switched to IMMIX for Internal Garbage Collection

I did a little bit of profiling on the iPhone and found a bit too much time was spent doing garbage collection.
The hxcpp runtime has 2 modes – “Boehm GC with explicit statics” and “internal”. The former is from a standard and robust code base, with the latter uses built in code with explicit marking. I added the second mode because Boehm GC was just too slow on the iPhone – not sure why because it is pretty good on the other platforms (maybe I missed a configuration option).

The internal GC has some restrictions that make it mainly suitable for games. These are: the collection must be triggered explicitly, since no stack searching is done, which is most easily done once per frame. And it is not thread safe, which can be worked around. Within these confines, many different schemes can be tried.
My first attempt could probably be termed “Naive Mark and Sweep”, and used free lists. On Windows/Mac this underperfromed Boehm GC, but on the iPhone, worked better.

The current scheme is now “Simplified IMMIX“. It is simplified because it is single threaded, and I have not implemented overflow allocation, defragmentation (although there are hooks in there for moving) or any generational stuff.
I think overflow allocation should be easy enough, and defrag should not be too hard in some form or other. The insertion of write barriers for generational control may also be straight-forward using the “operator =”. I may also change the code generation to separate stack variables (local, function args) from member variables since in the current scheme, stack variables never form roots, and therefore would not need to use write-barriers.

Anyhow, on the “Physaxe” test, which creates lots of small list objects per frame, the Naive GC got about 51fps, Boehm GC got about 65fps and IMMIX got about 69fps – so a bit of a win there. For this test, I triggered all collections exactly once per frame. The difference between Naive and IMMIX is significant, and this perfromance gain also translates to the iPhone, which is good news.

Since the internal scheme is precise, I feel it should be able to outperform Boehm GC by a bit more, and maybe the extra could come from a generational system. The code is actually not that complex (1 cpp file, 1 header file) so any budding GC researchers may want to see what they can do.

Currently, the internal GC is default only for the iPhone, but you can try it on other platforms by changing the #define in hxGCInternal.h. The reason for this is the restrictions mentioned above – the easiet way to conform to these restrictions is to enable the “Collect Every Frame” in neash.Lib. To remove these restrictions, I will need to find some way of stopping the world (safe points?) and some way of capturing the stack (code mods to allow objects to push themselves on a shadow stack?), both of which are very doable, although I’m not sure on the effect on performance.

Haxe, iPhone & C++ At Last

Hxcpp 1.0, neash 1.0, NME 1.0

The release this week of haXe version 2.0.4 officially includes c++ as a build target, for Windows, Mac, Linux and iPhone. You can download and install from haxe.org. In addition to the standard includes, you will need the “hxcpp” library, which can be insatlled with the included haxelib management tool.

Coincident with the hxcpp release, I have updated the neash and NME libraries to versions 1.0. You can also download these via the haxelib tool too. There are several incrental improvements, and the iPhone target has been added!

Getting started with the iPhone

Getting started with the iPhone is quite tricky at the moment, mainly because of the pain of setting up an Xcode project. Also, getting the simplest program onto the device is hard due to the code signing requirements. So if you can already get one of the existing application templates to work, you are half way there.

Note that this solution uses the “SDL” library, and must statically link against this. SDL is covered by the LGPL license, and this has implications should you choose to release your software. I am hoping to remove the LGPL restiction at a later date.

The binaries used here are have been compiled for the “2.2.1” iPhone SDK. So choose this version when compiling for simulator or device.

  1. Download and install components
    • Get haxe & neko: Visit haxe.org
    • Get hxcpp: haxelib install hxcpp
    • Get nme: haxelib install nme
    • Get neash: haxelib install neash
    • Get the sdl-static libs for iphone: I have created a project with binary builds of these. You can get the latest builds directly from subversion svn code at:
      http://code.google.com/p/sdl-static/source/checkout.
      Or get the snapshot bundle from this site and install somewhere handy:
      sdl-static-iphone-1.0.zip
  2. Get Xcode with iphone sdk support – visit apple.com
  3. Get a Developer key (you can try simulator without it). You will need to pay to sign up as a developer on the apple site.
  4. Fire up Xcode and do File > New Project.

    Choose iPhone OS > Application. Here choose a “Windows-Based Application
    but infact we will use the delegate setup in the SDL code, so we will have
    to delete the one created by the wizard.

    Select a name & directory for the project. I’m calling it “Haxe Test”.

    Now as it stands, you should be able to build for the Simulator and
    get a lovely white screen and a program called “Haxe Test” in the simulator
    start screen.

    Next thing is to delete(to trash) the “…AppDelegate.h” “…AppDelegate.m”,
    the “Nib Files” group, Resources/MainWindow.xib and “main.m”.
    Finally, select the “Haxe Test” executable (in the Targets section) and from the “Get Info” –
    “Properties” tab, clear the reference to “MainWindow”.

    We will add replacements for these soon.

  5. Add “main.cpp” from the NME project.
    Select the top-level project folder and then use Action > Add > Existing Files.
    It is probably in /usr/lib/haxe/lib/nme/1,0/ndll/iPhone/ or
    similar depending on which version of NME you have installed. It can be
    very painful to get xcode to load from this location, unless you hit
    Command-Shift-G at the “Add” dialog and type (at least some) of this filename in.
    Choose to “Copy to destinations folder” so
    that you can mess with it if you wish. Note: you need to have a cpp mainline
    in order to automatically link in the correct runtime libraries.

  6. Add the libNME.iphoneos.a and libNME.iphonesim.a files from the haxelib NME project.
    You can add them both and the linker
    will select the correct on depending on your build. They are in the same place
    as main.cpp, you you should be able to use “iPhone” from the pull-down box
    in the add dialog. Probably best not to copy these files – in case you want
    to change them at some stage.
  7. Add the whole sdl-static/lib/iPhone directory.
    Again probably best not to copy.
    I used the “Recursively create groups” option. These will be where you stored them
    in step 1.

  8. Add the whole hxcpp/bin/iPhone directory like above.
    Again, this will
    be in a path like /usr/lib/haxe/lib/hxcpp/1,0,2/bin/iPhone/.
  9. Add the hxcpp include directory to the include path.
    Use the “Info” button
    to get the project properties, and on the build tab, under “Search Paths”
    add something like /usr/lib/haxe/lib/hxcpp/1,0,2/include/ to “Header Search Path”
  10. Now we are ready for the haxe code. If you have and existing project,
    then you can adapt the following instructions.

    Create a new file from Xcode (Other/Empty File] Here I have called it “HaxeTest.hx”, and unticked the “Targets” option. I’m prety sure there is a way to get “Haxe File” to appear as on option here – but I don’t know the details.

    In the haxe file, enter something like (Note the window size):

    import flash.display.Sprite;
    import flash.display.Shape;
    
    class HaxeTest extends Sprite
    {
    
       public function new()
       {
          super();
          flash.Lib.current.addChild(this);
    
          var circle:Shape = new Shape( );
          circle.graphics.beginFill( 0xff9933 , 1 );
          circle.graphics.drawCircle( 0 , 0 , 40 );
          circle.x = 150;
          circle.y = 200;
          addChild( circle );
       }
    
       static public function main()
       {
          neash.Lib.mOpenGL = true;
          neash.Lib.Init("HaxeTest",320,480);
          neash.Lib.SetBackgroundColour(0x447733);
    
          new HaxeTest();
    
          neash.Lib.ShowFPS();
          neash.Lib.Run();
       }
    }
    

    This is the “main” file for haxe, and the hxcpp compile will create a library matching
    this class name.

  11. Set up a build script to build changes you make to your haxe files into a library.
    Xcode has a few issues with a straight custom build script order due to incorrect
    dependency checking. This can be worked around by first adding a custom target.

    Highlight the “Targets” in the Groups & Files and use the “Action > Add > New Target..
    Choose “Other > Shell Script Target” and call it something like “Compile Haxe”.
    Close the pop-up and go back to the explorer. There should be a “Run Script”
    entry under the “Compile Haxe” target if you expand it out.

    Get info on “Run Scipt” and enter the following script

       if [ "$CURRENT_ARCH" = "i386" ]
       then
          haxe -main HaxeTest -cpp cpp -lib neash -lib nme  --remap neko:cpp --remap flash:neash -D iphonesim
       else
          haxe -main HaxeTest -cpp cpp -lib neash -lib nme  --remap neko:cpp --remap flash:neash -D iphoneos
       fi
    


    You can untick the “Show Environment” if you do not need to debug this.

    One last step – drag the “Compile Haxe” target into the “Haxe Test” target.
    It should now also show up as first item “under” the “Haxe Test” target.
    The build order should now be correct. (See image at end of post)

  12. Now you are ready to do the build. The first time you build, the build
    results will show “Running custom shell script…” for quite a while.
    Haxe compiles to cpp very quickly, but it take a while for the cpp files
    to compile to a library. You can see the progress if you expand out the
    middle tab bit.

    At this stage, you should get a bunch or errors when linking, but also haxe
    should have created a library for you. Add this library to the project –
    it should be in the local cpp/HaxeTest.iphonesim.a.

  13. Compiling now gets a bunch of unresolved functions from frameworks.
    Add the following frameworks to the project (Add > Existing Frameworks):

    • QuartzCore
    • OpenGLES
    • AudioToolbox

    These can be found in /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.2.1.sdk/System/Library/Frameworks/.

  14. Run!
    So you should be good to go. Open up the debug console so you can see
    any traces/printfs.

  15. Change the target to “Device – IPhone OS” from the pull-down and hit “Build and Go”.
    Again, this takes quite a while the first time.
    Now add the new cpp/HaxeTest.iphoneos.a library to the project.

  16. Now you need to sort out your code signing. If you have not done so already,
    setup you apple developer account & certificates on the apple web site.
    Go to the info of the “Haxe Test” executable and the “properties” tab.
    Change the “Identifier” to match one of your cerificates. Make sure to
    match your company URL. You may want to use “*” when creating your
    profile for easy changing.

    Under the “Build” tab, under the “Code Signing” bit
    in the “Any iPhone Device” pull down your profile. If you don’t have one then
    you will need to create one on the apple website.

  17. Connect up your iPhone(iPod touch) and build! W00t!

HaxeTest

I have had all sorts of errors when trying to upload to the device.
So far, they have been solved by getting out of the car, walking around it and getting back in.
ie, Disconnect and power down ipod. Fully exit Xcode and the start it all up and try again. Also, uninstalling the app from the “Windows > Orgainiser” directory can help.

But now the easy bit. Change to HaxeTest.hx file, and hit Build & Go. It is that simple.
Errors should show up nicely in xcode.

You can add data files (eg, pngs, xml etc) to the project and they will be copied to device so you can open them with a relative path.

In the properties of the “Info.plist” you can set a Icon File – don’t forget to add the icon to the project too.

Not covered here (because I have not fully sorted it out myself):

  • Syntax highlighting in XCode
  • Debug build (hxcpp can do then – it’s a matter of setting up Xcode)
  • Code completion in Xcode
  • Automating this procedure!

Edit: Add framework path, SDL version, MainWindow clearing.

Haxe on the iPhone – For Real!

iphone3 To progress this project a bit further, I needed a real device – so I convinced the little woman that an iPod touch would be a good thing to have around. She seems to have taken to it, so now I’m thinking I may need one each :).

After much phaffing about, I’ve finally managed to get stuff running on the actual device. I had to comment out quite a bit of NME, since I only used the base SDL, not all the extras. Boehm GC was also a bit tricky because I didn’t really know what I was doing, but I brought in some bits from the mono project and then disabled USE_MUNMAP because it caused it to crash. In the end, it seems to work – no crash, but then I may not have been running it long enough. I will have to try some memory thrashing later.

One thing I found with Xcode is that if you ever change the project name/AppID settings then you really need to clean the project, exit Xcode and get back in. But the hardest part was working out where to go the get the developer certificate! I guess I’m a bit thick, or missed the meno, but it took me ages to get to the web form to create a certificate.

So the big question is perfromance. In this demo, initally, it runs at about 2.5 frames a second (I don’t have a fps counter yet), but slows a bit later when things spread out. But this is using the high-quality, anti-aliasing software renderer. Next job is to hook up the OpenGLES renderer, then I’ll really know where I stand.
But overall, pretty positive result I think.

A Second Look (iPhone + Haxe)

iphone2

Once the basics are in place, the rest comes pretty naturally.

Just a slight tweak to the MovieClip transformation gets Physaxe doing it’s thing.

Performace seems ok-ish in the simulator, not sure how it woud go on the real device.

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.

h3d

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.

Output.swf

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.