3 Years On

Wow, has it really been 3 years? 2009 was an interesting year – I guess the big ticket items were haxe for the iPhone and getting hxcpp into the standard distribution for haxe. I am very satisfied with these achievements, however there is still quite a bit of polish to add – especially in terms of ease-of-use. I also started some other projects – fastcgi for haxe, and “waxe“, the wx/haxe interface, as well as continuing with neash and nme development. One of the big changes for hxcpp, although not visible, was using an internal garbage collector which has improved performance and reduced the compile dependence on a library that is hard to debug on other peoples machines.

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

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!

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.

A Second Look (iPhone + Haxe)

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.

Haxe on iPhone (Simulator) – First Look

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