Wednesday, September 2, 2009

fractal pinwheels

These are some little pinwheels made by a little fractal line drawing + you typical draw lines around a circle code:

You can see it in action here. Click anywhere to draw a random pinwheel... and hit space key to clear them

Here is the function to draw the lines:

public function funky_line( g:Graphics, x1:Float, y1:Float, x2:Float, y2:Float, depth:Int, max:Int ) {
if ( depth > max ) {
g.moveTo( x1, y1 );
g.lineTo( x2, y2 );
} else {
var nx = -1 * ( y2 - y1 ) * ( depth / ( depth * depth ) );
var ny = 1 * ( x2 - x1 ) * ( depth / ( depth * depth ) );
var xm = x1 + ( x2 - x1 ) / 2 + nx;
var ym = y1 + ( y2 - y1 ) / 2 + ny;
funky_line( g, x1, y1, xm, ym, depth, max );
funky_line( g, xm, ym, x2, y2, depth, max );

Max is the number of recursions and count is the number of lines to draw around the circle...


Monday, August 17, 2009

xquery script

The other day, I really wanted to be able to run an xquery expression over some xml and use it as some scripting input... I was really surprised to see there really doesn't appear to be a nice way to do this!

After all... xquery is the xml equivalent of grep. Imagine! Landing in an OS with no grep equivalent!

Oh, wait... I just described windoze...

I wrote a small piece of XLS wrapped in a script( the script got a slightly more complicated once I found out that if an input document has a namespace defined, you have to use it in your expression.

Now this is handled like magic, but can be turned off by uncommenting the line "XSNAP_SMARTY" then you can specify "xsnap:expression" to match the default ns of the document.

Here is the dealio: "groupId/text()" pom.xml

And viola! A "grep-like" tool for xml!

This mechanism is more robust that just grepping xml since it uses the xquery standard junk.

Saturday, June 6, 2009

Voronoi diagrams as seamless tiles

Check out my groovy new seamless tiles.

I now have an easy way to use Voronoi diagrams to generate seamless tiles! Fun!

Feel free to get any sort of use out of them you can.

Friday, May 29, 2009

file timestamp in RFC-2822 format

Creating an RSS feed from a script was pretty straight forward, but I ran into some nuisance getting the file timestamps in the right format:

element pubDate: Schemas validity error : Element 'pubDate': [facet 'pattern'] The value 'Thu May 28 22:53:18 EDT 2009' is not accepted by the pattern '(((Mon)|(Tue)|(Wed)|(Thu)|(Fri)|(Sat)|(Sun)), *)?\d\d? +((Jan)|(Feb)|(Mar)|(Apr)|(May)|(Jun)|(Jul)|(Aug)|(Sep)|(Oct)|(Nov)|(Dec)) +\d\d(\d\d)? +\d\d:\d\d(:\d\d)? +(([+\-]?\d\d\d\d)|(UT)|(GMT)|(EST)|(EDT)|(CST)|(CDT)|(MST)|(MDT)|(PST)|(PDT)|\w)'.

element lastBuildDate: Schemas validity error : Element 'lastBuildDate': 'Thu May 28 22:53:18 EDT 2009' is not a valid value of the atomic type 'Rfc822FormatDate'.

That's the output of validation from xmllint and the XSD I have... if it's "RFC 822", "RFC 2822", doesn't really matter that much to me...

I finally got ls to produce this output format:

% ls -l myfile --time-style=+'%a, %d %b %Y %T %z' | cut -f6-11 -d' '

The date command has a nice flag (-R) that will print in this format too:

% date -R ; date +'%a, %d %b %Y %T %z'
Fri, 29 May 2009 10:14:53 -0400
Fri, 29 May 2009 10:14:53 -0400

Makes me wish we could just use %s... :-P

Wednesday, May 27, 2009

css sprites for js games

The other day, I started to look at css sprites again.

Imagemagicks' montage command is a groovy way to concatenation images together:

montage  ???1.png   -tile 1x -geometry +0+0 -background none last1.png

Along with some js shenanigans, I was able to write a small bejeweled-like puzzle game.

It's pretty neato! Give it a go!!

Monday, March 23, 2009

feelin' randy!

Shuffle! Chaos! Randomness! Surprise me! How many times... have you wanted to:
  • shuffle a list of mp3 to pass to mplayer
  • randomize a list of background images to eog
  • pick a random file from a directory
Once or twice? OK! These can all be boiled down to reading in lines from stdout, mixing 'em up and spewing them back out in a random order.

Check out this tiny haxe program called randy. It's self compiling:
% wget
% chmod 755 Randy.hx
% ./Randy.hx
% echo -e "1\n2\n3" | ./randy

I wrote it just 4u!

Wednesday, March 11, 2009

got the macro replacement blues

As crazy as it may seem, I have implemented this type of silly macro replacement stuff about a million times:

public String replace( String message, Object ... argz ) {
int i = 0;
for ( Object arg : argz ) {
message = message.replaceAll(
"\\{" + ( i++ ) + "}"
, arg.toString()
return message;

Basicly it converts something like:

"this is some {0}, Mr. {1}... some real {0}" + "mess" and "Man"

to something like:

this is some mess, Mr. Man... some real mess

The only "tricky" part is that you have to escape the opening curly with a backslash and then escape the backslash with a backslash...


Sunday, March 8, 2009

UpperCamel: compiling haxe to a native executable

UpperCamel is a little program for going back and forth between
camel case and underlined uppercase.

Typically camel case is used for class names, variables, and method names.

Whereas underlined uppercase is used for constants, statics, etc.
     Sample Input     | Sample Output
UpperCamel | UPPER_CAMEL
UPPER_CAMEL | upperCamel
MIX-and-Match | mixAndMatch

Somewhat useful... The main point is to show how to compile haxe to create a native executable:
% haxe -main UpperCamel -neko upperCamel.n
% nekotools boot upperCamel.n
% echo hello_world | ./upperCamel

Neat, huh?
% file upperCamel
upperCamel: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped
% ldd upperCamel => (0x4001a000) => /usr/lib/ (0x4002e000) => /lib/ (0x4004d000) => /lib/ (0x40065000) => /lib/ (0x401a8000) => /usr/lib/ (0x401ad000) => /lib/ (0x401e1000)
/lib/ (0x40000000) => /lib/ (0x40207000)

The code for UpperCamel.hx has a bit of shell script which makes it easy to compile for Unix-env type folks:
% wget
% chmod 755 UpperCamel.hx
% ./UpperCamel.hx
% file ./upperCamel
./upperCamel: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped

Haxe to binary executable is a nice path for whipping up custom commands when you need them with a really low price of admission!

Go, Haxe!

Sunday, February 22, 2009

crude ascii cube

So... working on some stuff... needed the vertices and indices for cube. The point "0" is set at (x,y,z)

4 .--------. 5
|\ |\ floor : 0,1,2 0,2,3
| \ | \ ceiling : 4,5,6 4,6,7
|7 .--------. 6 back : 0,1,5 0,5,4
| | | | front : 3,7,6 3,6,2
0 .--|-----. 1| left : 0,4,7 0,7,3
\ | \ | right : 1,5,6 1,6,2
\| \|
3 .--------. 2

pushi( vertices, [
x + 0 , y + 0, z + 0 // 0
, x + m , y + 0, z + 0 // 1
, x + m , y + 0, z + m // 2
, x + 0 , y + 0, z + m // 3
, x + 0 , y - m, z + 0 // 4
, x + m , y - m, z + 0 // 5
, x + m , y - m, z + m // 6
, x + 0 , y - m, z + m // 7
] );

btw... Adobe... wtf doesn't Graphics.drawTriangles take a zcoord and do zbuffering? Way to phone it in guys... Flash 11?

Tuesday, February 17, 2009


I've decided to start hosing my demos on instead of just all over the place willy-nilly.

It is pretty bare-bones at the moment, but I plan to grow it.

ppm is a developer's best friend!

OK, that is a crazy overstatement, but it is pretty useful bit to know about.

So what is it? It's a baby-simple image format. Let's say we wanted to write out a 320x240 image. The file would look something like:

320 240

So... if the first pixel was black (0x000000), we would write 0, 0, followed by zero. Whereas if it were (0xFFAADD) we'd cleverly write 0xFF, 0xAA, 0xDD.

Ya dig it? Here is a snippet from TextHash2Ppm.hx after I loaded the text file into an array of strings called (creatively enuff) "lines":

out.writeString( 'P6\n' );
out.writeString( lines[ 0 ].length + ' ' + lines.length + '\n' );
out.writeString( '255\n' );

for ( line in lines ) {
for ( i in 0 ... line.length ) {
var char = line.charAt( i ) ;
var value = if ( '#' == char ) 255; else 0;
out.writeByte( value );
out.writeByte( value );
out.writeByte( value );

Here is a bit I wrote recently to show files like sample_dungeon.txt to
sample_dungeon.ppm which I then converted to

Which I can then use as input to this heightmap viewer even though it looks wonky as heck.

PPM is a handy format for when you need to create images and you don't have or don't want to use an image library to create jpgs, pngs, etc...

Monday, February 9, 2009

bitmap'n it!

So... Like a lot of folks, I've always been really fascinated with bitmap type effects. They're a lot of fun to watch and pretty easy to write.

I collected together a set of small demos of some classic bitmap effects.

Franticly clicking on the demo will reset the current effect and eventually enable you to press the keys to access the different effects:
  1. pixel average: this kooky bit manipulation creates bizarre plasma effects (be patient!)
  2. clouds: different clouds and cloud like effects
  3. hough: use a hough transfer to create trippy sine waves from partial lines
  4. bump: ye olde bumpmap effect using displacement maps from the other demos

See it in action!

Monday, January 26, 2009

square root estimation fun with javascript

After reading about Fast Inverse Square Root I thought it would be fun to see this iterative estimation process in action:

Wednesday, January 21, 2009

refactoring safety net

I recently started porting and collecting some code for doing various sorts of intersection, or collision, tests in haxe.

At the moment, it is pretty limited with ray/triangle and ray/sphere tests.

The first test I ported was based on based on "Fast, Minimum Storage Ray / Triangle Intersection" by Tomas Möller and Ben Trumbore and ported directly from the copy of the code on here.

The results documented in the paper are pretty impressive and having source code certainly made it an easy win, but some aspects of the code concern me:
  • points are represented as arrays, perhaps not very efficient in haxe
  • the code has multiple returns points, can't be inlined in haxe

I want to refactor the code to be as efficient as possible because this is likely to be the innermost loop of particle simulation routines, etc, but I don't want to break the implementation.

Enter the test case.

My initial testcase generated 1000 random triangles and rays and tested the culling and non-culling version of the algorithm.

All well and good, but not good enuff for refactoring since I need to make sure the same inputs produce the same outputs before and after my changes.

So... I put in some trace commands to produce xml like so:
<hit non_hit="1" cul_hit="1" t="0.5373583852">
<v0 x="0.6581358404" y="0.1374191698" z="0.9648343668" />
<v1 x="0.308879062" y="0.6053369969" z="0.3154988046" />
<v2 x="0.8667143827" y="0.1228679823" z="0.3068826511" />
<src x="0.1215154344" y="0.2182366329" z="0.4350455069" />
<dir x="0.7023522276" y="0.3298090568" z="0.1063413928" />

Now I can verify that the same input produces the same output.

My test looks like this now:
public function testCanned() {  
var count = 0;
var tests =

for ( i in 0 ... 50 ) {
for ( test in tests ) {
verifyTriangle( test );
var stopTime =;
var diff = ( stopTime.getTime() - startTime.getTime() ) / 1000.0;

trace( count + ' tests / ' + diff + 's = ' + ( count / diff ) + ' tests/s' );

After a few test runs, the initial numbers look like:
AppTest.hx:99: 459600 tests / 32s = 14362.5 tests/s
AppTest.hx:99: 459600 tests / 36s = 12766.66667 tests/s
AppTest.hx:99: 459600 tests / 35s = 13131.42857 tests/s
AppTest.hx:99: 459600 tests / 35s = 13131.42857 tests/s
AppTest.hx:99: 459600 tests / 36s = 12766.66667 tests/s

So... it averages out to around 13231.738096 tests/s

My first refactoring was to use a "result" variable and some branching to only have a single return point so I can use the inline function modified:
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s
AppTest.hx:99: 459600 tests / 32s = 14362.5 tests/s
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s

For an average of around: 14733.145160 tests/s

This comes to 14733.145160/13231.738096 = 1.11347013167180814489 , for an 11% speedup just from this trivial change.

From some earlier work, I saw that an optimized point class could be significantly faster than a typedef, some additional tests (unpublished) show that using arrays to represent points was about 4x slower than typedefs!

The next refactoring will be to use this "InlinePoint" class

AppTest.hx:101: 459600 tests / 18s = 25533.33333 tests/s
AppTest.hx:101: 459600 tests / 17s = 27035.29412 tests/s
AppTest.hx:101: 459600 tests / 17s = 27035.29412 tests/s
AppTest.hx:101: 459600 tests / 17s = 27035.29412 tests/s
AppTest.hx:101: 459600 tests / 18s = 25533.33333 tests/s

Average is 26434.509804. 26434.509804/13231.738096 = 1.99781084028493908605.

Damn! Of course it comes at the cost of a new type, but still.

So pretty, happy, but still a little concerned about this:
var edge1 = threePt();
var edge2 = threePt();
var tvec = threePt();
var pvec = threePt();
var qvec = threePt();

That's a lot of memory allocation madness... One optimization I tried was to move the declarations to where they are actually used... not much difference...

What about passing in a workspace? This bumped up to 28725 for an improvement of 8%, but doesn't really seem worth the bother.

So that's the good news... now the bad news...
ERR: AppTest.hx:48(tests.AppTest.randomTriangle) - expected '-0.206685315' but was '0.4077964499'

Happily, it turned out to be a red herring from the refactoring of the test itself:
assertEquals( cul.x, non.y );

should have been (and now is)
assertEquals( cul.x, non.x );


Friday, January 16, 2009

Finding the Twilight Samurai

I woke up this morning thinking of an oddly disturbing movie I saw a couple of years ago.

It's about this this samurai who is living right around the poverty line. A widower, he supports his daughters and elderly mother making extra money building and selling cricket cages to the local villagers.

In Meiji Japan, this sort of activity is borderline illegal due to a the caste system so it's a little sketchy.

Then one day, in the middle of barely being able to keep his family alive the leader of his clan shows up and says: "I need you to go kill this guy."

I googled on: samurai movie cricket cage widower

Which led me to:

Looking at the role of the samurai in a very narrow, mercenary sense, the appeal of risking your life in exchange for a position of authority and respect makes a certain sort of epicurean sense.

Watching this movie, I felt compelled to ask: why is he willing to risk his life and the life of his family for people who have really given him nothing in exchange?

Or course, the answer is honor. In this film, it is a rare commodity with a very odd exchange rate.

Just like in real life.

Tuesday, January 6, 2009

stickman physaxe

So I was reading about physaxe 1.2 and thought it would be fun to have some more stickman action leveraging it.

The demo I throw together is mostly from code ripped off from the original post and little bit of stuff to make the "springs":

Move the mouse around to move gravity and click anywere to add some junk:

Usage is something like this:

var a = body( 50, 40 );
var b = body( 50, 140 );
var j = new DistanceJoint( a, b );

world.addBody( a );
world.addBody( b );
world.addJoint( j );

It is not integrated into the physaxe code right, cuz I had to loop over my joints when I stepped the world.

The interesting piece of the "DistanceJoint" look like this:

public override function preStep( invDt : Float ) {
var currentDistance = dist( b1, b2 );
if ( 0 != currentDistance ) {

var diff = ( currentDistance - this.distance ) / currentDistance;
var xdiff = ( b2.x - b1.x ) * diff;
var ydiff = ( b2.y - b1.y ) * diff;

b1.v.x += xdiff * 0.5;
b2.v.x -= xdiff * 0.5;

b1.v.y += ydiff * 0.5;
b2.v.y -= ydiff * 0.5;

It doesn't take into account the relative mass of the bodies but that should be pretty straight forward.

It should be enough for stickmen, cloth, strings, etc.

If you are interested, you can find the code here.

Friday, January 2, 2009

segmented flowers

So... let me start off a little differently by saying: I'm not really all that thrilled with how this came out.

The basic idea was to model plants, flowers, as vertlet-based segments using distances constraints for each segment. In order to keep the plants upright, I added a new a "height constraint" to keep each vertlet a certain amount above the ground.

Additionally I rooted each plant's base point so it wouldn't wander off.

Next, I added rain by modeling each drop as a vertlet and testing it's previous and current coordinates again each segment (see below)

Here are the results:

You can click to toggle the rain. I think it might be improved using a better design for the plants (eg: that branching tree algorithm).

This partially scratched the itch I had to model dynamic plants, but not quite... Hopefully I'll turn up some more information on how to do properly at some point.

I think angular constraints might work...

Anyway, if you are interested, the code is available for whatever you like.

2d line intersection test

Once upon a time, long, long ago... I wanted to find out where 2 line segments intersected in 2d.

I played with rise over run and all that dumb crap till I finally found somebuddy who had the math-magic I was looking for.

Here it is translated to haxe:

public static function intersectionTime(
line_0_x0:Float, line_0_y0:Float, line_0_x1:Float, line_0_y1:Float
, line_1_x0:Float, line_1_y0:Float, line_1_x1:Float, line_1_y1:Float
) {
var line_0_xdiff = line_0_x1 - line_0_x0;
var line_0_ydiff = line_0_y1 - line_0_y0;

var line_1_xdiff = line_1_x1 - line_1_x0;
var line_1_ydiff = line_1_y1 - line_1_y0;

var line_1_normal_x = line_1_ydiff;
var line_1_normal_y = -line_1_xdiff;
var l2 = (
line_1_normal_x * line_1_normal_x
line_1_normal_y * line_1_normal_y
if ( 0 != l2 ) {
l2 = Math.sqrt( l2 );
line_1_normal_x /= l2;
line_1_normal_y /= l2;

var denominator = (
-line_1_normal_x * line_0_xdiff
-line_1_normal_y * line_0_ydiff

var t = -1.0;
if ( 0 != denominator ) {
var numerator = ( 0
+ line_1_normal_x * ( line_0_x0 - line_1_x0 )
+ line_1_normal_y * ( line_0_y0 - line_1_y0 )
t = numerator / denominator;
return t;

I'm sure you can find some explanation of what it does and why it works, but sometimes... don't you just wanna rip off code?

"So what's the deal?" you ask? Fair enuff. You pass it the end points for two line segments and it returns where along the first segment the intersection would occur (-1 means never, sorry).

If it is between 0 and 1, that means it occurred some where along the first segment.

If you want to see if the intersection (or collision) occurred on both segments, you can then call with the segment orders reversed to see where on the other segment it hit ala:

var t_0 = App.intersectionTime(
line_0_x0, line_0_y0, line_0_x1, line_0_y1
line_1_x0, line_1_y0, line_1_x1, line_1_y1
var t_1 = App.intersectionTime(
line_1_x0, line_1_y0, line_1_x1, line_1_y1
line_0_x0, line_0_y0, line_0_x1, line_0_y1

var hit_on_0 = ( t_0 >= 0 && t_0 <= 1 );
var hit_on_1 = ( t_1 >= 0 && t_1 <= 1 );
var real_hit = hit_on_0 && hit_on_1;

var x = line_0_x0 + ( line_0_x1 - line_0_x0 ) * t_0;
var y = line_0_y0 + ( line_0_y1 - line_0_y0 ) * t_0;

Note if "real_hit" is true then x,y will be the coordinates for the actual intersection, otherwise it is where it would have hit on the first line (line_0).

Here you can see it in action.

Grab the code here and look at


It's not the most optimized way to do things since there is some duplicated computation, but I know you don't wan me to have all the fun!

BTW.... does anyone know when/why these google turkeys stopped allowing the embed tag? Sheesh... Numbskulls! Yes... I am looking it in the mouth...