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.

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

Quick Update

Just a quick update to let you know things are still moving forwards. I have not done very much iPhone specific stuff recently, but I have been working on the graphics code base in general. The idea is to separate the graphics code from SDL (although still use SDL most of the time) to avoid GPL issues and also allow the library to be used in a wider set of applications rather than just games. For example, inside a window in a larger desktop application, or inside Google’s Native Client plugin. Another goal is to improve rendering speed by minimising the amount of data moved between haxe and the graphics code – this involves moving code logic from haxe into c++. I have also been looking at a few minor tweaks such as setting object widths/alphas like flash does.

Once this is done and moved into Neash/NME, I will fix a few of the remaining issues on the C++ backend – maybe even get to add dynamic properties to the runtime. I would also like to spend a bit of time finishing off the internal garbage collection to make it thread-safe and run automatically – this could solve some of the problems compiling boehm-gc on various systems.

And, of course, I would like to write more tutorials…

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.

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.

WordPress markdown.php Unknown modifier ‘|’

So all of a sudden, all the posts started showing preg_replace_callback() [function.preg-replace-callback]: Unknown modifier ‘|’ in …/wp-content/plugins/text-control/markdown.php. I presume this was because my provider changed php versions. There are 2 possible fixes:

1. Disable your markdown plugin
2. Fix the markdown.php file, if you can edit it. This problem was a couple of lines above the one reported, one of the opening braces (“{“) had a back-slash quote where it should not have. ie, it was …(?:[ ]\{$md_tab_width}… but shold just be …(?:[ ]{$md_tab_width}…

GM2D.com – New Sister Site

I’ve just launched a new site, GM2D.com, about making games in 2D. The new site is more about tutorials and documentation for haxe, flash, NME and Neash libraries, as well as general documentation, while this site will remain more about technology and experimentation. I hope the new site will help motivate me to bring out some more documentation and promote some of the great things that are being done in haxe.

2 Years Old!

Another year has gone, and I’ve updated the blog look for a bit of a change. 2008 was pretty productive – three main technologies (NME, for low level rendering, Neash for flash interfacing and HXCPP for generating C++ code) have progressed to the “very useful” stage. I have one more technology to go, “gm2d” – a reasonably light weight API to abstract the platform quirks required for super fast rendering on flash, software NME or OpenGL. This will also contain some stuff for making games more easily. And of course, I hope to get the first three technologies to production quality.

HXCPP 0.3 Released

I have put together a new version of hxcpp, the c++ backend for haxe. New features include improved coverage of language features. All the unit tests except remoting pass now. I have also cleaned up the ocaml code a bit and improved the output consistency. Still a bit to do here, but not that much.

The code now contains a dependency system that allows for incremental compiling, greatly improving the speed.

Dlls are now all in one directory – by adding this to the exe path no dll copying should be required. This still needs a little thought :- I tried to delay load the dll, thereby giving greater control over locating it, but it seems the rtti system brings the dll in before I can change the load path. Apart from this, most of the 0.1 TODO list is finished. There are still a few little language features required – such as “break” from within a return block but it’s 99% there, and the external libraries are pretty much untested.

I have also hijacked the neko code to provide OS libraries. This means that I had to allow “neko” class paths in the cpp target – this seems a little odd – I will have to think about a solution here.

Strings are implemented with wchar_t, rather than utf8 bytes, so some neko functions that took “string” actually take “byte array” in cpp. On the plus side, multi-byte characters are “native” in the c++ target.

The source and demos are in hxcpp-03.zip.

HXCPP 0.2 – Huge performance increase.

I have switched hxcpp over from using ref-counting to using Boehm garbage collection. I have also added some additional perfromance improvements, such as integer-index field names to make interaction with neko more efficient.

The overall result is that for the Physaxe demo, the frame rate went from 24 fps to 82 fps (in opengl mode). The swf file runs at about 35 fps, and neko at about 8 fps. This is about what I was hoping for from the first round, but I got there in the end.

You can download the updated files here.

Boehm GC, virtual inheritance and finalizers.

I’m trying to get a speedup for the cpp backend for haxe by using garbage collection. Initial results are very promising – potentially about twice as fast. Howerver I spent a good few hours getting the the bottom of a little problem. Boehm garbage collection is a very impressive piece of work – it has all sorts of magic that does magical things, such as deal with virtual inheritance. This was a bit of a surprise because you do not always get “real” pointers, when you store an object pointer, you get one with an offset. However it seemed to work. Until I added finalizers to the external draw objectes used by the renderer. Apparently, you can only add finalizers to the “real” pointers (ie, those returned from “GC_MALLOC” et al), rather than a pointer to the same object related by virtual inheritance. The symptom was that the object gets finalized in the first “gc_collect”, even though it was still “used” as far as I was concerned. I guess this is not too surpising, and the fix was pretty easy, but the fact that everything else worked so well lulled be into not suspecting this initially.