Posts Tagged ‘haxe’

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.

Box2D mouse drawing, now with ear clipping

Saturday, October 24th, 2009

In my previous post I presented an example of drawing arbitrary shapes for Box2d using the mouse. It was done using triangulation to deal with concave shapes. However, triangulation does produce a lot of vertices (as seen when holding down T), which isn’t really necessary and hogs the physics engine a lot. Since we can have up to 8 vertices per shape in a Box2d body, the number of shapes can be reduced by generating a collection of <8 vertex shapes instead of 3 vertex ones.

After som digging I found this post at Touch My Pixel’s blog, featuring a few awsome AS3 classes for doing this trick. After converting to haXe and making a minor alteration to limit the numer of vertices per shape to <8 I replaced the trianglutaion by this and it works great! It also got rid of most of the strange lines sometimes shooting out of the Box2d  shapes (probably due to lots of very small angles produced by the previous triangulation method).

Also, I figured I should try out the new haxe port of Box2d recently put on googlecode by Heinz Hoelzer. So this swf is haxe all the way! :)

I also changed the style of debugDraw and added the mouse dragging feature from the box2d tests this time.

You can grab the source code for this version here if you wish.

Update: I have now made the source code compatible with hxcpp and neash, so it will compile for the C++ target. Box2D performance is about twice as fast as for the flash target. Nice!

Get Adobe Flash player

Instructions:

* Draw bodies using your mouse.

* Hold shift while drawing to make static bodies (ground).

Box2D mouse drawing

Tuesday, October 20th, 2009

This post is obsolete, go here instead: http://www.splashdust.net/2009/10/box2d-mouse-drawing-now-with-ear-clipping/

In my physics game making endeavors I eventually came across the problem of getting arbitrary polygons in to physics simulation engines such as Box2D.

The problem is that such engines cannot handle concave polygons. And also a polygon cannot have more than a certain number of vertices (for performance reasons I would assume). So in order to feed your polygon to the engine you need to convert it to a format that the engine will be happy with. If it is a concave polygon with lots of vertices it will have to be split up into a set of less complicated convex polygons.

Since I basicly suck at math I had no clue how to do these kinds of calculations, so I turned to google to see if someone else might have already solved the issues. And indeed someone had.

Regarding the problem of concave polys and vertex limits I found a great AS3 class for polygon triangulation over here: http://actionsnippet.com/?p=1462
That class takes a polygon and spits out a bunch of triangles, which when put together assumes the same hull shape as the original polygon. This solved a lot of my problems. However, triangulation does not work when there are overlapping segments in the polygon, which might easily be the case when one jots a bunch of lines on the screen in no particular order. So I needed something to make order from that kind of mess. What I found was the Graham scan algorithm, neatly converted to AS3 at http://blog.efnx.com/as3-creating-a-convex-polygon-from-unordered-points/

Then, of course, I had to convert these classes to haxe, but that was mostly a matter of find-and-replace.

So now I have the following set up:

* Draw a bunch of line segments while the mouse button is down.

* When mousebutton comes up, feed the segments to a function; makeBody()

* If they consist of less than 8 vertices and make up a convex polygon and are in a clockwise order (checked using algorithms found here), then we reverse the vertices to make them CCW and then feed them straight to Box2D. Otherwise we’ll treat it the same way as 8 < vertices polygons.

* If it is more than 8 vertices, than we need to triangulate before Box2D gets them. And if it turns out that they cannot be triangulated, then we’ll feed them to the Graham scan to straighten them out, and then back to the triangulator to try again. If it manages to triangulate this time, then Box2D will get the result. If not, something went terribly wrong, and the whole thing will probably fall into an endless loop of Graham scanning and triangulating.

And that’s that! The result is below for you to play around with.

And here’s the source code.

Get Adobe Flash player

Instructions:

* Draw bodies using your mouse.

* Hold shift while drawing to make static bodies (ground).

* Hold down “T” to see the shapes that make up each body.

Thanks to Zevan Rosser (www.actionsnippet.com), Schell (blog.efnx.com) and Paul Bourke (debian.fmi.uni-sofia.bg/~sergei/cgsr/docs/clockwise.htm) for posting awesome code!

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.

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.