Posted on

NME From Scratch

Part 1 – Get The Basics Going

I’ve just got a shiny new computer at home – nothing installed. So it seems like a good chance to go through exactly what it takes to get and NME sample up and running on a new Windows 7 box.

8:20pm For starters, I’ll need a c++ compiler, so first thing is to start the MSVC 2010 Express downloading: 2010-Visual-CPP.

8:25pm OK – I’ve signed my rights away and that is downloading. The next thing I’ll need is haxe. It is easy to install from here.

8:28pm Haxe 2.07, neko 1.81 downloaded and installed. Windows complained that it might not have installed correctly, but this is just because the exe had “installer” in the name, and did not write an “uninstall” entry.

Test: Start a “cmd” prompt by clicking on the Windows start circle and type “cmd[Enter]” into the search box. And in this box, type “haxe [Enter]”. I am now rewarded with the haxe help message.

8:35pm Visual C++ Express in successfully installed.
Test: Start up a new cmd shell, and type “cl“. This does not work because the exe can’t be found in my path. But here is the trick. Type “c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat” at the prompt (note:include the quotes!), and get the message “Setting environment for using Microsoft Visual Studio 2010 x86 tools.”. Now “cl” is rewarded with the Microsoft banner.

8:41pm I’m on a bit of a roll here, so I’ll see if I can get an haxe project going. As I said, I have nothing installed, so I’ll go old-school. First thing is to make a directory. The cmd prompt starts in my home directory (c:\Users\Hugh), and I will make a directory:
mkdir projects
cd projects
mkdir hello
cd hello
And now, do the best I can:
notepad.exe Hello.hx (yes I do want to create the file)

class Hello
{
  public static function main()
  {
     trace("Hello!");
  }
}


And switch back to the cmd prompt:
haxe -main Hello -neko hello.n
neko hello.n
Hello.hx:5: Hello!

Woo Hoo! 8:48pm and I’ve run my own program.

Now lets get even more adventurous, and try a c++ example. Trying:
haxe -main Hello -cpp bin
Tells me that “Project hxcpp is not installed” – so let’s install it:
haxelib install hxcpp
And try again:
haxe -main Hello -cpp bin
And test:
bin\Hello.exe
8:43pm, I have my first hxcpp prgram working!

Now, try for some graphics:
haxelib intall nme
and start a new project:
cd ..
mkdir graphics1
cd graphics1
copy “c:\Motion-Twin\haxe\lib\nme\2,0,1\samples\02-Text\Sample.hx”
haxe -main Sample -cpp bin -lib nme
bin\Sample.exe

9:05pm And there it is. Haxe, neko, hxcpp, nme VC2010 installed and run in 40 minutes, including this write up.

Part 2 – Compile NME From Source

Well, that went much better than I expected, so I will now attempt some bleeding-edge stuff. The version on NME used above is old, and I have no one to blame but myself. My intentions are to do a release soon, but I just have not got my finger out. Which leave me with the option of compiling NME from source if I want the latest features.

First thing, is to create a place where I can download various bits of source code for compiling. I’m going to put it a “e:\code.google”, because my C drive is a fast SSD, and has limited room.

e:
mkdir code.google
cd code.google

Following the instructions from the source page, but changing the name, I can get a copy with:
svn checkout http://nekonme.googlecode.com/svn/trunk/ nme
– if only I had svn installed. So first install this, I’ll be using this version. Once installed, I have to restart the cmd prompt and do the vsvars32.bat thing again. Now when I try again, I get the required files. There is also a companion project to go with NME, and that is the “sdl-static” project, which contains libraries required by NME. To get this, simply do:
svn checkout http://sdl-static.googlecode.com/svn/trunk/ sdl-static
This takes a while….

Time to build –
cd nme\project
haxelib run hxcpp Build.xml
The “haxelib” tool looks for a file called “run.n” in an installed haxe library and runs it. In the hxcpp project, the run.n file gathers compiler options to build the haxe output. This same program can be used to build other projects – including the NME project. Unfortunately, compiling NME like this gives the error ” cannot open input file ‘ddraw.lib'”. This is because the VC express install does not have all the required system support files. This file can be found in the “DirectX SDK”, and I’ll be using the June 2010 version. This is a huge file, so it will take a while. If you think it is a lot of effort for a tiny lib, then you are right.

10:10pm and the download has finished. I have chosen to install it in “e:\SDKs\Microsoft DirectX SDK (June 2010)”, because I’m trying not to put crap on my C drive, and I will be installing quite a few SDKs, and it is nice to have them all together.

This does not immediately fix the problem, because the NME project does not know where I installed it. This is where the per-machine hxcpp config comes in.

Following the instructions in BuildCommon.xml, I create a file in “C:\Users\Hugh” called “.hxcpp_config.xml”, and put the following in it:

<xml>
  <section id="exes">
     <linker id="dll" if="windows">
        <flag value = "-libpath:e:\SDKs\Microsoft DirectX SDK (June 2010)\Lib\x86"/>
     </linker>
  </section>
</xml>

Oh crikey! Looks like Microsoft in their wisdom have dropped support for this ddraw.lib, and I’m currently using a version of SDL that needs it! It’s OK, problem solved – I’ve added it to the NME project, but you still need the SDK for dxguid.lib, which I guess I should also add.

Anyhow, after a long delay, at 10:30pm I have NME building!

Now, going back to the original graphics1 example, the first thing to do is tell haxe to use our SVN haxe code instead of the 2.0.1 dowloaded from haxelib. This is done via:
haxelib dev nme e:/code.google/nme

Then build & test:
haxe -main Sample -cpp bin -lib nme
bin\Sample.exe

Which works as before. But now we can test some of the new features in NME. First get the new sample, and the new associated project file:
copy e:\code.google\nme\samples\02-Text\Sample.hx .
copy e:\code.google\nme\samples\02-Text\Sample.nmml .

Then you can use the NME build tool, with the command “test” (which is “build” and “run”) on the Sample.nmml project file, and for the target “neko”.
haxelib run nme test Sample.nmml neko
And you can see the result. Then you can test for cpp:
haxelib run nme test Sample.nmml cpp

So it’s now 10:45pm (had to catch the end of “Dexter”) and I’ve successfully compiled the latest version of NME and tested the new project feature.

Part 3 – Android

Things seem to still be going well, so I’m going to take one more step – android (spoiler – this is going to take longer than expected). First thing to so is install the Java Development Kit. (NOTE: Install the “windows” version, not the “x64” version) Then, the android SDK.
I installed java JRE and JDK in my SDK directory, but Google’s (always painful) build tools seem to think I have not installed java, even though it works from the cmd prompt. Thank guys. So I’ve uninstalled it, and reinstalled the JRE in the default location, and now it seems happy. The Android SDK download is just the start – it now runs and downloads a whole bunch more. This looks like it may take some time…

I may as well get on with downloading the NDK too. And while I wait for those I’ll get my phone ADB USB drivers installed. My HTC phone actually installs the drivers when I install HTCSync, found on my sdcard that was shipped with it.
EDIT: The android ndk r5b still has issues with exceptions/c++. However, these can be solved by dropping this version of libstdc++.a from the Crystax r4 distribution over the top of sources/cxx-stl/gnu-libstdc++/libs/armeabi/libstdc++.a in your downloaded ndk. If google ever manage to write a good build system, they might end up being a successful company.

The Google build tools also require the “Cygwin” utilities, so install these too.

Finally, we will need a new version of hxcpp, which we can get with:
e:
svn checkout http://hxcpp.googlecode.com/svn/trunk/ hxcpp
haxelib dev hxcpp e:\code.google\hxcpp

11:45pm, I have finally downloaded and installed the Android prerequisites (I think) but will give up now.

Next day – Here we go again. Now to use the google android NDK, you need to have the cygwin dlls in your exe path. To change the path, right click in the “Computer” shortcut in the start menu, and choose “properties”, then on the left “Advance system settings”, then the “Environment Variables” button and scroll through the top bit for “PATH” and click “edit”. This already has haxe and neko in it, so we add the cygwin:
%HAXEPATH%;%NEKO_INSTPATH%;e:\SDKs\cygwin\bin
Now restart the cmd prompt, and typing “ls” should work.
And one more thing – in lieu of using “eclipse” for java building (which I just can’t stand – don’t get me started), the google tools need the “ant” program, which you install by unzipping somewhere.

Tell the build system where we installed these things.

set ANT_HOME=e:/SDKs/ant
set ANDROID_SDK=e:\SDKs\android-sdk
set ANDROID_NDK_ROOT=e:\SDKs\android-ndk
set JAVA_HOME=e:\SDKs\Java\jdk1.6.0_24

And rebuild nme, like before, except that the “obj” directory should be removed first, because I have not yet allowed 2 compilers to be running at the same time.
haxelib run hxcpp Build.xml -Dandroid

Now, back in the original directory, we can build + run for android:
haxelib run nme test Sample.nmml android

Which, finally, works! You can terminate the debug log with control-c.

So, an awful lot of set up, but subsequent projects should only be a single line.

Posted on

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.

Engine FPS
Neko/nme 9
Chrome 4.1, JS 11
Opera 10.5.3, JS 18
V8VM/nme 23
Flash 37
CPP/nme 130

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 🙂

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

Neash/NME first release

clocks.png

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.

shapes.png
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](http://code.google.com/p/plotex/) for more details.

Posted on

Porting NME to linux

Linux Port
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](http://vmware.com/products/player/), and then the Ubuntu 7.1 virtual machine, that included a dev environment [http://jars.de/linux/ubuntu-710-vmware-image-download-english](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](http://nekonme.googlecode.com/svn/trunk/project/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?

Posted on

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.