Game Haxe

Haxe on the iPhone - For Real!

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)

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

Some Help Getting Started With Hxcpp

Tony at touchmypixel.com has posted some very useful information to help you get started with hxcpp. Be sure to go over there and check it out.

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.

Hxcpp 0.4, NME 0.9, Neash 0.9 Released!

What the flash?

What is Hxcpp? Hxcpp is the c++ backend for haxe. This means you can compile haxe code to c++ code, and then compile this to a native executable, for Windows, Linux or Mac.

What is NME? NME is the “Neko Media” library that wraps SDL, providing gaming interfaces for neko, and now native compiled haxe code.

What is Neash? Neash is a compatability layer that presents the flash API to haxe code running on other systems, such as js, neko or c++ native code.

Together these allows you to write code to target flash SWF files, and also cross compile to native code for Windows, Linux or Mac.

Hxcpp on haxelib

I have finally packaged up a bunch of changes into offical haxelib releases. Hxcpp is now on haxelib, which means you can get it with “haxelib install hxcpp”. This effectively creates a whole separate install of haxe, which can be run side-by-side so you can test it out without risk.

The cpp backend now supports Mac(intel) and Linux as well as the original Windows platform.

The main change to hxcpp is the packaging - moving towards a the final installation form. Currently there are a whole bunch of files distibuted in this release that should become redundant once the c++ backend is merged into the main branch. Also, the library coverage has been expanded a bit, but it is still not complete.

Usage

Firstly, you will need to run “haxecpp” instead of “haxe”. This executable is found in the appropriate bin subdirectory. I’m not sure if the “executable” flag will survive the compression, so you may need to “chmod a+x” the file.

It is probably best to place the appropriate bin directory in your executable path. On windows, this will also solve the problem finding the dynamic link library, hxcpp.dll. And on all systems, this will allow you to use the “make_cpp” command from the hxml files. On Linux systems, you will have to allow the executable to find the hxcpp.dso. This is most easily done by setting LD_LIBRARY_PATH to the bin/Linux directory, or copying this file into an existing library path. Similarly on Mac, you should set DYLD_LIBRARY_PATH.

To build haxe code, use “haxecpp” inplace of “haxe”, with a target specified by “-cpp directory”. This will place source code and a makefile in the given directory. Then you need to do a “make” on linux/Mac, or “nmake” on Windows to build the executable. You may need to set the environment variable “HXCPP” to point the the directory that contains this file. On windows, this will be something like: c:\Progra~1\Motion-Twin\haxe\lib\hxcpp\0,4\

As a shortcut, if you are using a hxml file, you can use “-cmd make_cpp” which will do the build for you assuming you used the “-cpp cpp” directory.

Neash/NME

The big changes for NME is that it now supports Linux and Mac(intel) for neko ac c++ targets. There have been a few bug fixes as well as a few new features:

• Bitmap class
• Expanded and optimised TileRenderer for render scaled and rotated sub-rects from a surface
• A few smarts for finding fonts, if no ttf is supplied
• Some blend modes have been added
• Added scale9Rect
• Added drawTriangles, with perspective correct textures

ToDo

There is still plenty to do, including, but not limited to:

Hxcpp:

• Proper coverage of all APIs.
• Resolve the order-of-operation problem: In c++ f(x++,x++) is ambiguous as to what order the increments are performed. Or perhaps agree to live with it.

NME:

• Add all blend modes
• Add all filters
• Discuss with experts the merits of static vs dynamic linking Mac and Linux.

Neash:

• Sound is a big ommision
• Loader code
• Unit testing of supported APIs.

Despite these issues, I think there is a useful core of functionality here.

Let me know what you think.

Haxe Preloader For Flash - Written in Haxe.

There has been some talk about creating flash preloaders for haxe. However, these methods step outside the haxe toolchain and add some additional complication.

I have come up with a reasonably simple method for creating a haxe preloader in haxe, and then linking to a (very almost) unmodified swf generated in haxe using a small neko program to produce a single file. The neko program uses code from the hxformat project, some of which is provided so you can easily recompile the tool.

Since each original haxe swf contains one frame, the resulting code contains 2 frames. The first frame contains the preloader which waits for the whole file to load and then locates the PreloaderBoot class by name. This class runs the appropriate initialisation code, creating and running the correct “main” class.

For classes that appear in both preloader and the main swf, flash takes the first one - the one form the preloader. This means that both classes will have the same “flash.Lib.current” and (almost) everything will just work.

One complication comes from the fact that the flash.Boot class is given a unique name for each of the swfs. This means flash.Boot class in the main swf is not automatically “new”ed and placed on the stage, and the standard haxe initialisation code is not run. To compensate, we manually set the trace function and call the Boot initialisation code explicitly.

This sounds a little dodgy to me, but it seems to work - I will have to do some more testing.

The “Main” class in the example zip contains a resource to pad it out. The preloaded swf can be seen on it’s own screen. You can refresh to see it loading.

The example code is in haxe-preloader-0.1.zip

All code & data there is public domain, except for the hxformat code, which has its own license. Use at your own risk.

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.