Archive for the ‘haXe’ Category

SamHaXe + Snow Leopard

Sunday, November 29th, 2009

Ex spies and big cats don’t always get along well. The main problem you will face when trying to compile SamHaXe on OS X 10.6 is that the Neko version you got from installing HaXe (Which I will assume you have installed) is a 32 bit one. SamHaXe will not be able to link against libneko.dylib when you compile, because your target architecture is 64-bit in Snow Leopard.

After some fiddling around and some kick-ass help from the SamHaXe mailing list I finally managed to get SamHaXe up and running on Snow Leopard. In a nutshell, the solution is to compile a 64-bit Neko before you compile SamHaXe.

Here’s how how to do it:

  1. First install MacPorts. It will make it a lot easier to get the right dependencies.
  2. Then install PCRE and ImageMagick: 
    $ sudo port install ImageMagick pcre

    This will take ages, so go get a good book or something. :)

  3. Neko will need to link against Hans Boehms garbage collector, so you will need to compile and install that before getting on with Neko. Go and get version 7.1 from the downloads section at http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
    If you configure and compile it right away you will get an error due to Apples aggressive deprecation policy, so you will have to get your hands dirty with some preprocessor code here.
    Open mach_dep.c and find these lines:

    #if !defined(HAVE_PUSH_REGS) && defined(UNIX_LIKE)
# include <ucontext.h>
#endif

    Change them to this:

    #if !defined(HAVE_PUSH_REGS) && defined(UNIX_LIKE) && !defined(DARWIN)
# include <ucontext.h>
#elif defined(DARWIN)
# include <sys/ucontext.h>
#endif

    Now you can do the usual

    $ ./configure
$ make
$ make install
  4. Ok, now you’re all set for compiling a 64-bit Neko. Version 1.8.1 that is the current official version has a bug in it that prevents using modules on Snow Leopard, so you will have to get the CVS version. There’s instructions on the Neko downloads page: http://nekovm.org/download.
    Unfortunately, there’s a new OS X bug in the CVS version that you will have to work around manually for now (Hopefully this is fixed soon though). Here’s how:

    • Create a file called “clock_gettime_stub.c” in [neko-source-dir]/libs/std. Copy the contents from http://le-depotoir.googlecode.com/svn/trunk/misc/clock_gettime_stub.c into that file.
      [Edit: It appears that this file doesn't get compiled. So all you need is the change to neko.h below. This will allow Neko to compile, but I suspect it will crash at run time if something accesses the sys_thread_cpu_time() function. I will leave this be as long as it works for me though.]
    • Open [neko-source-dir]/vm/neko.h and put the following lines right above C_FUNCTION_END at the bottom of the file: 
      #ifdef NEKO_MAC
 typedef enum {
     CLOCK_REALTIME,
     CLOCK_MONOTONIC,
     CLOCK_PROCESS_CPUTIME_ID,
     CLOCK_THREAD_CPUTIME_ID
 } clockid_t;
 EXTERN int clock_gettime(clockid_t clk_id, struct timespec *tp);
 #endif

      [Edit: This has been fixed on CVS now, so this step should no longer be needed]

    Now you can compile Neko like this:

    $ make MACOSX=1

    You will be asked three times about headers for mod_neko, mod_tora and mysql. I decided to simply skip these as I won’t need them.

  5. Now you have a 64-bit binary version of neko in the [neko-source-dir]/bin directory. To install it to your system, make a backup copy of /usr/lib/neko and then copy the contents of [neko-source-dir]/bin into it and replace what ever is in there.
  6. Now you should be able to compile SamHaXe. Follow these steps:
    • Create ant.config and put these lines in it. The paths should be correct for a default installation of MacPorts. 
       haxe.path=/usr/bin
 haxe.stdpath=/usr/lib/haxe/std
 imagemagick.path=/opt/local/bin
 imagemagick.include.path=/opt/local/include/ImageMagick
 imagemagick.library.path=/opt/local/lib
 imagemagick.library.name=MagickWand
 neko.path=/usr/lib/neko/
 neko.include.path=/usr/lib/neko/include
 neko.library.path=${neko.path}
 freetype.path=/opt/local/bin
 freetype.include.path=/opt/local/include/
 freetype.library.path=/opt/local/lib
    • Open build.xml and change image-imagemagick.dylib to libimage-imagemagick.dylib on line 238 and font.dylib to libfont.dylib on line 317
    • Now type ‘ant’ in the terminal to compile.
  7. That’s it! If all went like it should you now have a fully working SamHaXe in the [samhaxe-source-dir]/bin directory.

A problem you might encounter is that haxelib won’t work with the 64-bit neko, since haxelib is 32-bit by default. To fix this, you can compile a new haxelib from /usr/lib/haxe/std/tools/haxelib/. Simply cd to that directory and do “haxe haxelib.hxml”. Then copy the new binary over the old /usr/bin/haxelib.

Tags: , , , , ,
Posted in Mac, Web development, haXe | 2 Comments »

BitmapData and paletteMap

Tuesday, November 10th, 2009

I just happened to stumble across a feature of flash’s BitmapData class that I hadn’t noticed before: paletteMap()

With paletteMap() you can switch the color values of the pixels in a BitmapData using mapping arrays. The function will basicly take the red, green or blue value of a pixel (0-255), and then replace it with the value found at the corresponding index in the mapping array. Doing this is a lot faster than using the setPixel method.

To try this out, I applied it to the fractal code I used in an earlier post. In this particular case I can assign an index value to each pixel, instead of a color, and then simply use a single array for the palette mapping.

So first I set an index value for each pixel in the bitmap data, and the palette data (The palette data will retain the original values, and I will use it to map against when I set the values for my bitmap).

bitmapData.setPixel(ix, iy, iteration);
paletteData.setPixel(ix, iy, iteration);

And now, my render loop only need to do 128 steps, one for each index. this is much quicker than looping through all 320×240 pixels.

for(i in 0...128) {
    r = i + colorModifier;
    g = i + colorModifier + r;
    b = i + colorModifier + g;
    rgbArray[i] = (r<<16 | g<<8 | b);
}
...
bitmapData.paletteMap(paletteData, bitmapData.rect, new Point(0,0), rgbArray, rgbArray, rgbArray);

The performance gain is pretty awesome. The setPixel version ran at about 50-60 fps on my machine at 320x240.This paletteMap version runs at 1000+ fps! (Takes less than 1 ms to render). Nice.

Get Adobe Flash player

And here's a version running at 1024x768 with 512 iterations.

Also, as a curious side note, I happend to notice that "flash.Lib.current.stage.stageHeight" is not a good thing to use in a loop (duh) :) Replacing it with an inlined static variable reduced fractal generation time with several hundred ms.

The full haXe source is available here if you want it.

Tags: , ,
Posted in haXe | No Comments »

AS3 vs haXe performance

Sunday, October 18th, 2009

A while back I saw a documentary about fractals. I was amazed by how simple the algorithm required to generate them are, so I decided to try to make one myself using flash.

Today, all of a sudden, I got the idea to port that code to haxe, just to see if there were any noticeable difference in performance.

And yes, there’s a huge difference. In haxe, the fractal is generated in slightly less than half the time compared to AS3. And the color cycling animation I made runs almost three times as fast in haxe on my 2.66 Ghz core 2 duo MacBook. That is pretty awesome.

See for yourself:

Click here to view the AS3 fractal.

Click here to view the haXe fractal.

And if you want to peek at the source code, you can grab it here.

Tags: , , ,
Posted in Web development, haXe | 2 Comments »

haXe + Box2D

Saturday, October 17th, 2009

I’ve been fiddling around a while with trying to make some sort of flash based physics game. I started out with AS3 + Box2D. Then I found out about haXe and PhysaXe. I was really impressed by it’s perfomance, so I decided to convert my code to haXe and throw out Box2D. But after a while I realized that while physaxe is very snappy, it does lack a lot of features and isn’t very well documented.

So now I wanted to switch back to Box2D again. The problem with that is that there is no Box2D port available for haXe. After some googling i found out that it is possible to use AS3 libs from haXe by incorporating an existing swf into the one compiled by haXe. This is done using the –swf-lib directive in the .hxml file and using the –gen-hx-classes switch to generate haXe class headers for that swf.

So I did that with Box2D. But guess what. Box2D does not follow the AS3 naming convention, which is apparently enforced in haXe. The Box2D classes look like this: “Box2D/Dynamics/b2World.as” and so on. haXe requires that package names start with lower case letters and class names with upper case, i.e “box2d/dynamics/B2World.as”. So in order to get it working I had to change the naming of all the Box2D classes and paths to match haXes requirements. Once that was taken care of it worked great!

Here is the Box2D swf together with the hx classes that I generated. To use it, put the box2d directory in your class path and put –swf-lib path/to/Box2D.swf in your .hxml file. Then you can simply use “import box2d.dynamics.B2Body;” and so on for the box2d classes that you need, and use box2d as you would from AS3. But remember that all the box2d class names start with an upper case B, so if you copy and paste AS3 code you’ll have to change that.

Oh, and the Box2D version is 2.0.1 btw.

Tags: , ,
Posted in Box2D, Web development, haXe | 4 Comments »