Minor Updates

I have just released a few minor updates to nme + hxcpp, which you can find on haxelib. These are relatively small \- just pushing out a few fixes for some bugs that have been reported. In most cases the bug reports we accompanied by a fix \- you’ve gotta love open source. The iPhone/Xcode template has also been updated, you may need to follow the instructions in the post below.

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.

New Releases!

Finally, I’ve managed to make a few more releases. Namely, HXCPP 2.06 and NME 2.0.
HXCPP can be downloaded via “haxelib”, and works with the new 2.06 version of haxe. This release contains many bug fixes and optimizations. Also, when you compile with the -debug flag, you can get additional null checks and stack dumps.
NME 2 is a complete rewrite from the ground up. Most of the logic has been moved from neash to the c++ code for optimization reasons.
For NME developers this only means a couple of things:

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

Android Port – Second Look

I have looked into some of the performance aspects of the Android port, and I’ve come to some conclusions. Firstly, after looking at the disassembly, there did not seem to be any additional code associated with exception handling, so there was no optimizing to be done there. Secondly, the compile flags meant that software floating point operations were used, rather than the built-in hardware FPU.

So I added compile flags to force hardware floats, and added armv6 instructions while I was at it. You can get the installer here.

This gives my phone a nice 50% boost in frame-rate to about 15fps. However, on some devices this app may fail to run. This change brings the performance in line with iPhone performance for the simulation side of the program. However the OpenGL seemed slower. I guess the Qualcomm MSM 7227 does not have strong 3D acceleration \- or perhaps I am still missing something?

For comparison, you can test the flash version of the code in this directory. I get about 6\-7 fps, which is not too far from my initial software-float based results and is quite impressive. I’m not sure if the flash renderer is using software or hardware rendering \- maybe it’s worth a closer look to find out what it’s doing.

Android Port – First Light

I bought myself and Android (2.1) HTC Legend phone. Obviously, the first thing I wanted to do was to get haxe/NME running on it. Now the Android platform is very well setup for Java development but, unfortunately, the haxe Java target is not fully developed at the moment. Luckily, there is also a “native” development kit (NDK) that allows you to run c++ code on the device using a Java bootstrap to load the code and JNI.

The NDK is based in the GCC toolchain, and therefore is already pretty well supported by the hxcpp haxe backend. The problem is that the standard NDK is somewhat crippled – it does not support exceptions or the STL. It is possible to rework the hxcpp backend to work without the STL, but removing exceptions may take a bit more work. I managed to work around this by using a slightly modified NDK, created by a very helpful member of the comminity over at crystax.net. In theory this should have been all that was required, however the NDK also lacks proper wchar_t support. When I finally worked this out, it was reasonably easy to substitute a simple translation layer to fix these wide-char problems.
So far, I have only implemented the rendering API, with no interactive options. The OpenGL ES rendering code is exactly the same as for the iPhone, except that the initial context and display surface are setup in the Java code, rather than the Objective C code.

Developing with haxe for the Android target requires several modules to work together. First, you compile your haxe code as normal to a shared object – which is actually a JNI module. This exposes a single “main” function that can be called from Java. Your actual Android application starts with Java code, and you can setup the properties etc. from eclipse. Ultimately this will be boilerplate code and you will only need to change the bits you need to. This Java code then calls the haxe main function. In the graphical/NME environment the main thing this does is dynamically load the nme native library and setup a callback for when the graphics are finally initialized. You then return to Java code and setup a OpenGL ES context. When this is done, a JNI call is made into the nme dynamic library, which in turn calls back into your haxe application to complete setup. The “MainLoop” is then processed in Java, and events such as “Redraw” (and later “OnMouse” etc) are passed into the nme library, and then into the haxe application as registered “addEventListeners”.

So in this somewhat convoluted way, Java maintains full control of the app, and therefore correct interaction with the OS, while almost all the real work is done in the haxe code. In the example shown here, no changes were necessary to the haxe code, and the internal garbage collection also worked without modification, so it is a pretty solid cross-platform solution.

Now the bad news. The performance is way down compared to my 2nd generation iPod touch. This example is 10fps on the Android device, and about 24 on the iPod. Which is strange, because the core should actually be running a bit faster. The slowdown seems to be on both the OpenGL side, and the physics calculation side. It should also be noted that this is a first pass, so there is quite a bit of room for improvement. My guess is that the gcc compiler is generating significant runtime overhead per function because of the exception code. This is what I noted while compiling for the iPhone (it was doing a pthread lock per function!) \- but in that case the penalty was only incurred in functions that actually “threw”, so I simply moved the throwing code into a separate function. Which brings me to my second problem …

No easy profiling or debugging support for native code. This is a real pain for debugging (back to “log” debugging) and the lack of profiling makes it very hard to work out what needs optimizing for the target. I may be able to use a simple “setjump” style system for exceptions because the use of garbage collection means that there are no real destructors required for cleanup. But I would need to be sure this would help – premature optimization and all that.

I would also count the fact that you really need to use eclipse as an IDE as a big negative, but I think that this is just my personal dislike of the program. I think there may ultimately be ways around this with command-line compilers etc.

Native compiling tools for the Android target are still in active development and moving forwards, so I’m assuming that most of these problems will be overcome eventually. And of course, the big advantage of the Android OS is the openness \- so I can provide you with the actual application to run on your device \- give it a go, and let me know if it runs for you.

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 🙂

Bravo, Apple

Finally, Apple is doing away with those arrogant upstarts who think then can write a few lines in a high level language and call it a program. Their new developer agreement requires:

3.3.1 – Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This has a couple of good points – firstly banning stupid languages (used by those people who are not smart enough to learn c++), and secondly getting rid of translation layers. Apple has clearly put a lot of thought into their APIs, so why would anyone want to put a layer on top of them – it’s just going to make things harder to use.

Languages

There has been a lot of talk recently about compiling “foreign” languages, such as haxe, as3, javascript, java, .net based languages, into binaries that will run extremely well on the iPhone. But like all foreigners (who are responsible for all the terrorism in the world) these languages should be cleansed from all iPhones to maintain the iPhones mono-lingual purity. Putting such insidious diversity into a beautifully designed device can be shown to confuse consumers, most of whom don’t even know their device and been compromised by these so call “high level” languages.

By raising the barrier of entry, and only permitting “real” programming languages (ie, “C” based ones), Apple ensures that the quality of apps will remain at its current lofty levels. “Natural Selection” will then weed out those people who are too lazy or too stupid to learn a proper language. In fact, I think Apple has not gone far enough here and should dabble in a bit of “Intelligent Design” by requiring that all developers who wish to submit apps hold at least a 4 year degree in computer science. Just imagine a world where any kid can work out of his garage and build an application with an original language, or bit of hardware, that snubs its nose at the establishment – anarchy would ensue. Therefore, it is important that the responsible companies out there vet such potentially disruptive ideas before they can cause too much damage.

It can’t be said that Apple don’t like new langauges, after all, they championed the greatest NeXT Step in programming ever, Objective-C, it’s just that all the other languages are utter crap. Some of then do away with the beautiful square bracket, some use commas to separate function arguments and nearly all the modern ones perform “Garbage Collection”. What a joke! Apple solved this problem years ago be simply not creating garbage in the first place. Again, it is only those too lazy to learn about how to use allocation pools and correct reference counting that need anything as dirty as Garbage Collection.

The new langages, such as haxe, are so terse that you do not even know when you are using a delegate. How can anyone possibly understand that code like:
addEventListener(KeyboardEvent.KEY_DOWN, function(event) { trace(event); });
Is supposed to do? I mean where is the delegate? Where is the class that implements the UITextFieldDelegate protocol? (And why must these languages continue to call things “Interfaces” when they are clearly “Protocols” ?)

I think Apple are right to ban code generators, such as the haxe c++ backend. While these produce code that could in theory be produced by hand, the code it robotic and lacks the “soul” of hand written code. To err is human, and without the quirks introduced bu a human coding c++ we may as well hand the future over to SkyNet and let the machines run everything.

Layers and Tools

Thankfully, Apple has also done its research into programming techniques as well as programming languages. The problem with programming these days is that where are too many layers and tools to learn, and they are taking us back to a simpler times where you are “close to the metal”. Apple rightfully shuns these extra layers, and focuses only on code. Once you understand Objective-C, Interface Builder, NIB, XIB, Frameworks, .app layouts, provisioning, xml, plist, controllers, delegates, owners and outlets, then you can create pure lovely code, without any of that layering crap getting in your way.

Programmers must beware of code that essentially “lies” by pretending that the beautiful, native API actually looks like one of the ill-conceived APIs from another language. For example, why would anyone want to view a native UIView image as the practically unsable as3 “equivalent” (I use the term loosly) of BitmapData? I don’t think there is a single successful application ever written that uses this BitmapData class.

Isolating your code from the native API will cause your code to lose its identity. If you can compile it for another (obviously inferior) device then your code will become tainted by the lower class device, even it it performs identically on the Apple device. How quickly people forget that the upper class should not mingle with the lower class.

I hope Apple’s ban extends to the gzip “translation layer”. Programmers should not be using this library because it has security implications, and they should simply use the streaming classes and do the decompression in their own code. If more programmers thought like Apple, then there would be a lot fewer security holes in software.

Don’t get me started on Game Making programs. Thank god these are banned – imagine letting a non-programmer create an App. What next, Artist creating games? Don’t make me laugh.

Conclusion

Apple has made a huge stride forwards by tightening the definition of what a real developer is, and I’m looking forward to what’s next. I think they have a little way to go – for example, what about all those people using foreign editors, rather than XCode? Surely if XCode is not good enough for a developer, then that developer is not good enough for Apple. The best way I can see for them enforcing this is for them to install a “watchdog” application the the developer’s machine, and send screenshots back to Apple periodically. That way, if the developer does not conform to the coding purity required by Apple, they could be identified and sent to a camp to help them concentrate on being better programmers. Win-win, what a great idea.

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.