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.

Version 2.3.9, Default
Version 2.3.9, AutoHinting
Version 2.4.4, Default
Version 2.4.4, AutoHinting
Flash (Mac)
GDI Threshold (Current)
GDI AA
GDI AA + Gamma
Flash (Windows)

So a few observations: The “Default Hinting” has changed quite a bit for TrueType fonts in the latest version. I think this code is what the expired patent related to, allowing the font-specific hinting data to be used. The “AutoHinting” mode is based on font-independent logic built into FreeType. The Flash renderer uses component based sub-pixel rendering, using RGB components to get finer details. The font also looks a bit “fatter”.

Currently NME uses a single set of bitmaps for the fonts, which must be used for all colours. This means that component based sub-pixel rendering is not really an option. However, it may be possible to sort something out (at the expense of more memory) if the need really arises. But also note, this is counter-productive in landscape mode on mobile devices.

On windows, NME currently uses GDI fonts with a threshold. I like the look of this (I spend most of my time on windows) for the small fonts, but it looks pretty bad on the larger fonts. Particularly note the exactly 1-pixel wide vertical lines in the “H” and the “l”, which I like. The larger fonts look much better with anti-aliasing on. However, windows applies some kind of gamma-correction when rendering fonts, and you get quite a different look for black-on-white and white-on-black. To work around this, I have applied a lookup-table to get a bitmap that will work for both light and dark.

Finally notice the windows flash renderer does not use AA with this swf (although the Mac version did).

In the next version, I will change windows over to use GDI + AA + Gamma. It is possible to use FreeType, but I think the font is slightly less readable at the smaller sizes. What do you think?

I would also like say a big thanks to those who have donated to the site – it is nice to feel useful.

The main change since last update was the release of hxcpp 2.07. This goes with the latest haxe release and fixes many bugs, making the platform more robust.

Work on NME continues. There has been some increased interest of late, and a new release is well overdue. I’m currently working on a “project” system to help with getting up-and-running on the various platforms. This will replace the iPhone template system and extend it to all supported platforms.

You can always checkout the svn version of NME, but you will need to build the binaries yourself. Although I have quite a few outstanding issues, I think I will do a release once I get the project system up-and-running.

There is one significant change though – the “nekoapi.dll” file that is used for compatibility between hxcpp binaries (ie, NME) and neko has changed its extension to “ndll” so that neko can communicate directly with it. This allows the String instances created externally to be “blessed” as haxe strings without having to call nekoToHaxe on them, and therefore methods such as substr will work.

The other change of note is that I removed the libfreetype code from the iPhone target, and used native font rendering instead. Let me know if this breaks anything. One side effect is that the default font will now be system dependent, with the iPhone getting its usual font. I will also have to have a good look at the font render quality – freetype may have a little bit better sub-pixel sharpness.

There was a bug in the 2.06 haxe distribution when writing files. I have fixed this by putting an override in hxcpp, which you can access with the command line options: “-lib hxcpp”. I have also folded this change into haxe svn, so you will not need to do this in 2.07.

• You use –remap flash=nme instead of –remap flash=neash
• The “boot” code has changed, so you will need to follow the main line from one of the samples.
• Improved performance!

I updated my Xcode SDK, which caused a bunch of link errors linking for the simulator with the NME library. It seems Apple have changed the “ABI” for objc (basically, broke binary compatibility). So I must choose pre 4.0, post 4.0 or both. I think I am going to require NME iphone simulator users to have the latest SDK – unless there are any objections?

iPhone Xcode Template

I finally got around to making an Xcode template for haxe compiling. Try it out and let me know if it works. It’s my first one, so I’m open to ideas for improving it.

To use the template, first extract it to your developer template area, eg: /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Project Templates/Application.
Then when you create an new Xcode project, this template should show up. You should be able to build for the simulator.

To build for a real device, you will need to go though the official Apple developer program, and get yourself signed up. Then you need to get your certificates in order, and finally edit the “plist” file in the Resources folder and change the company URL to match the one you used in your certificates.

You can edit Main.hx code in the “haxe/src” directory, but you will probably want to locate your haxe source tree outside your project area, since we are multi-platform developers an do not want to tie ourselves to Xcode. To do this, you can edit the class path in the Build.xml file, and change the boot code in IPhoneMain.hx. It is done this way so the haxe-generated library always has the same name. If all else fails, you can have a look in the makefile, which is set up to allow building debug and release versions for iphoneos and simulator without having to change other project settings.

Let me know if you have any luck.

Currenly, I’m working on an NME rewrite to remove GPL code from the iPhone target, and to help integration. Now that hxcpp has reached a certain level of quality, the diverse projects are starting to coalesce and I’m pushing ahead with a complete hxcpp/nme/iphone solution which should be very useful.

Looks like 2010 may be the year it all comes together (hopefully!).

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!

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.

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.

iPhone Dev

The iPhone SDK requires you statically link everything, and I wanted to make it easy as possible to change haxe code -> generate cpp -> link to Xcode -> test of iPhone (or simulator). The solution I am currently using is to generate a library from the haxe code using the standard command line make, and include this library in the Xcode project. I hope to add a “pre build” step to drive the make system automatically.

Hxcpp executables typically use the “NME” library for graphics, which is in turn based on libSDL. The good news is that the source version of libSDL compiles for the iPhone! I tried the svn download first, but this does not seem as nicely bundled as the Apirl 13 version, which worked very nicely indeed (besides a small problem with RenderRect args changing).

Getting the hxcpp backend to generate a library was almost trivial – you take the same obj files and put them in a lib instead of an exe. The only minor difference is you do not explicitly create a “main” (ie, program entry point) call, but instead create a function (currently called \_\_hxcpp\_lib\_init) that the user supplied main line must call. This may also be good for windows applicaions that want to use a “WinMain” instead of console based main function.

Compiling the hxcpp runtime as a static library was also pretty easy after the post 0.4 code reorganisation that assimilates thirdparty code rather than linking to it. Again, it was a matter of taking the same objs and putting them in a lib instead of an dso. Initally I got link error when linking with Xcode, but if you include 1 real, small c++ file in the project, these link error go away.

Compiling “plugin” modules as static libraries (eg, NME) was slightly more difficult. I could use c++ static initialisation to auto-register the exported functions, if I could get Xcode to link to the required obj. To force objs to be included, I needed to put a special symbol in each cpp file that exports functions, and make reference to these from the main code base. It is really only something that needs to be sorted out once, and it is done now, so it should not really be a problem any more.

I also have to cull out quite a bit of code (eg fonts, image loading, opengl & sound) from NME, but I can look at adding these bits in one by one.

The astute ones among you will notice that the colour of the above circle if RGB/BGR reversed. This is something that will obviously need to be fixed.

Not being used to Xcode, it took a bit of getting used to – things like frameworks etc. However, I think that ultimately, we could end up with a very nice solution. The idea would be to create frameworks for hxcpp and nme, and a project template to link it all together. You would then create a project from the template, modifiy the boiler-plate haxe code and hit build. This would also be good for standard mac apps (rather then iPhone apps). Still a way off this, but moving in that direction.

SDL, LGPL and you

Dynamically linking against SDL (or NME) normally discharges your obligations to the GPL, however in this case, we are statically linking to it so there are still some issues. However, all is not lost because my interpretation is that you must allow others to relink your application. (ie “so that the user can modify the Library and then relink to produce a modified executable containing the modified Library”, where Library is “SDL”). So you must forefiet your hxcpp compiled library file (rather than haxe or cpp source), as well as you project files (which should be boiler-plate anyhow). So this is actually borderline acceptable, although I will work towards a GPL free solution).

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.