Articles tagged video at null program 2026-04-07T03:24:16Z urn:uuid:6ca8997d-4783-46f5-9390-8b615eac5b75 Christopher Wellons https://nullprogram.com wellons@nullprogram.com You might not need machine learning urn:uuid:91aa121d-c796-4c11-99d4-41c707637672 2020-11-24T04:04:36Z This article was discussed on Hacker News.

Machine learning is a trendy topic, so naturally it’s often used for inappropriate purposes where a simpler, more efficient, and more reliable solution suffices. The other day I saw an illustrative and fun example of this: Neural Network Cars and Genetic Algorithms. The video demonstrates 2D cars driven by a neural network with weights determined by a generic algorithm. However, the entire scheme can be replaced by a first-degree polynomial without any loss in capability. The machine learning part is overkill.

Above demonstrates my implementation using a polynomial to drive the cars. My wife drew the background. There’s no path-finding; these cars are just feeling their way along the track, “following the rails” so to speak.

My intention is not to pick on this project in particular. The likely motivation in the first place was a desire to apply a neural network to something. Many of my own projects are little more than a vehicle to try something new, so I can sympathize. Though a professional setting is different, where machine learning should be viewed with a more skeptical eye than it’s usually given. For instance, don’t use active learning to select sample distribution when a quasirandom sequence will do.

In the video, the car has a limited turn radius, and minimum and maximum speeds. (I’ve retained these contraints in my own simulation.) There are five sensors — forward, forward-diagonals, and sides — each sensing the distance to the nearest wall. These are fed into a 3-layer neural network, and the outputs determine throttle and steering. Sounds pretty cool!

A key feature of neural networks is that the outputs are a nonlinear function of the inputs. However, steering a 2D car is simple enough that a linear function is more than sufficient, and neural networks are unnecessary. Here are my equations:

steering = C0*input1 - C0*input3
throttle = C1*input2

I only need three of the original inputs — forward for throttle, and diagonals for steering — and the driver has just two parameters, C0 and C1, the polynomial coefficients. Optimal values depend on the track layout and car configuration, but for my simulation, most values above 0 and below 1 are good enough in most cases. It’s less a matter of crashing and more about navigating the course quickly.

The lengths of the red lines below are the driver’s three inputs:

These polynomials are obviously much faster than a neural network, but they’re also easy to understand and debug. I can confidently reason about the entire range of possible inputs rather than worry about a trained neural network responding strangely to untested inputs.

Instead of doing anything fancy, my program generates the coefficients at random to explore the space. If I wanted to generate a good driver for a course, I’d run a few thousand of these and pick the coefficients that complete the course in the shortest time. For instance, these coefficients make for a fast, capable driver for the course featured at the top of the article:

C0 = 0.896336973, C1 = 0.0354805067

Many constants can complete the track, but some will be faster than others. If I was developing a racing game using this as the AI, I’d not just pick constants that successfully complete the track, but the ones that do it quickly. Here’s what the spread can look like:

If you want to play around with this yourself, here’s my C source code that implements this driving AI and generates the videos and images above:

aidrivers.c

Racetracks are just images drawn in your favorite image editing program using the colors documented in the source header.

]]> Inspecting C's qsort Through Animation urn:uuid:7d86c669-ff40-3210-7e28-78b801e35e50 2016-09-05T21:17:11Z The C standard library includes a qsort() function for sorting arbitrary buffers given a comparator function. The name comes from its original Unix implementation, “quicker sort,” a variation of the well-known quicksort algorithm. The C standard doesn’t specify an algorithm, except to say that it may be unstable (C99 §7.20.5.2¶4) — equal elements have an unspecified order. As such, different C libraries use different algorithms, and even when using the same algorithm they make different implementation trade-offs.

I added a drawing routine to a comparison function to see what the sort function was doing for different C libraries. Every time it’s called for a comparison, it writes out a snapshot of the array as a Netpbm PPM image. It’s easy to turn concatenated PPMs into a GIF or video. Here’s my code if you want to try it yourself:

Adjust the parameters at the top to taste. Rather than call rand() in the standard library, I included xorshift64star() with a hard-coded seed so that the array will be shuffled exactly the same across all platforms. This makes for a better comparison.

To get an optimized GIF on unix-like systems, run it like so. (Microsoft’s UCRT currently has serious bugs with pipes, so it was run differently in that case.)

./a.out | convert -delay 10 ppm:- gif:- | gifsicle -O3 > sort.gif

The number of animation frames reflects the efficiency of the sort, but this isn’t really a benchmark. The input array is fully shuffled, and real data often not. For a benchmark, have a look at a libc qsort() shootout of sorts instead.

To help you follow along, clicking on any animation will restart it.

glibc

Sorted in 307 frames. glibc prefers to use mergesort, which, unlike quicksort, isn’t an in-place algorithm, so it has to allocate memory. That allocation could fail for huge arrays, and, since qsort() can’t fail, it uses quicksort as a backup. You can really see the mergesort in action: changes are made that we cannot see until later, when it’s copied back into the original array.

dietlibc (0.32)

Sorted in 503 frames. dietlibc is an alternative C standard library for Linux. It’s optimized for size, which shows through its slower performance. It looks like a quicksort that always chooses the last element as the pivot.

Update: Felix von Leitner, the primary author of dietlibc, has alerted me that, as of version 0.33, it now chooses a random pivot. This comment from the source describes it:

We chose the rightmost element in the array to be sorted as pivot, which is OK if the data is random, but which is horrible if the data is already sorted. Try to improve by exchanging it with a random other pivot.

musl

Sort in 637 frames. musl libc is another alternative C standard library for Linux. It’s my personal preference when I statically link Linux binaries. Its qsort() looks a lot like a heapsort, and with some research I see it’s actually smoothsort, a heapsort variant.

BSD

Sorted in 354 frames. I ran it on both OpenBSD and FreeBSD with identical results, so, unsurprisingly, they share an implementation. It’s quicksort, and what’s neat about it is at the beginning you can see it searching for a median for use as the pivot. This helps avoid the O(n^2) worst case.

BSD also includes a mergesort() with the same prototype, except with an int return for reporting failures. This one sorted in 247 frames. Like glibc before, there’s some behind-the-scenes that isn’t captured. But even more, notice how the markers disappear during the merge? It’s running the comparator against copies, stored outside the original array. Sneaky!

Again, BSD also includes heapsort(), so ran that too. It sorted in 418 frames. It definitely looks like a heapsort, and the worse performance is similar to musl. It seems heapsort is a poor fit for this data.

Cygwin

It turns out Cygwin borrowed its qsort() from BSD. It’s pixel identical to the above. I hadn’t noticed until I looked at the frame counts.

MSVCRT.DLL (MinGW) and UCRT (Visual Studio)

MinGW builds against MSVCRT.DLL, found on every Windows system despite its unofficial status. Until recently Microsoft didn’t include a C standard library as part of the OS, but that changed with their Universal CRT (UCRT) announcement. I thought I’d try them both.

Turns out they borrowed their old qsort() for the UCRT, and the result is the same: sorted in 417 frames. It chooses a pivot from the median of the ends and the middle, swaps the pivot to the middle, then partitions. Looking to the middle for the pivot makes sorting pre-sorted arrays much more efficient.

Pelles C

Finally I ran it against Pelles C, a C compiler for Windows. It sorted in 463 frames. I can’t find any information about it, but it looks like some sort of hybrid between quicksort and insertion sort. Like BSD qsort(), it finds a good median for the pivot, partitions the elements, and if a partition is small enough, it switches to insertion sort. This should behave well on mostly-sorted arrays, but poorly on well-shuffled arrays (like this one).

More Implementations

That’s everything that was readily accessible to me. If you can run it against something new, I’m certainly interested in seeing more implementations.

]]> Emacs Chat with Sacha Chua urn:uuid:cbe9f993-8fb1-34a3-e872-f493268135aa 2014-06-04T16:51:45Z My previously mentioned Emacs Chat with Sacha Chua went well and the recording is available. At my request, Sacha agreed to put these recordings in the public domain, so they’re completely free for any purpose with no strings attached.

A number of my Emacs projects were mentioned, most of which I’ve previously written articles about here.

If you enjoyed this Emacs Chat, remember that there are a lot more of them! The chat with Phil Hagelberg is probably my favorite so far.

]]> A GPU Approach to Voronoi Diagrams urn:uuid:97759105-8995-34d3-c914-a84eb7eb762c 2014-06-01T21:53:48Z I recently got an itch to play around with Voronoi diagrams. It’s a diagram that divides a space into regions composed of points closest to one of a set of seed points. There are a couple of algorithms for computing a Voronoi diagram: Bowyer-Watson and Fortune. These are complicated and difficult to implement.

However, if we’re interested only in rendering a Voronoi diagram as a bitmap, there’s a trivial brute for algorithm. For every pixel of output, determine the closest seed vertex and color that pixel appropriately. It’s slow, especially as the number of seed vertices goes up, but it works perfectly and it’s dead simple!

Does this strategy seem familiar? It sure sounds a lot like an OpenGL fragment shader! With a shader, I can push the workload off to the GPU, which is intended for this sort of work. Here’s basically what it looks like.

/* voronoi.frag */
uniform vec2 seeds[32];
uniform vec3 colors[32];

void main() {
    float dist = distance(seeds[0], gl_FragCoord.xy);
    vec3 color = colors[0];
    for (int i = 1; i < 32; i++) {
        float current = distance(seeds[i], gl_FragCoord.xy);
        if (current < dist) {
            color = colors[i];
            dist = current;
        }
    }
    gl_FragColor = vec4(color, 1.0);
}

If you have a WebGL-enabled browser, you can see the results for yourself here. Now, as I’ll explain below, what you see here isn’t really this shader, but the result looks identical. There are two different WebGL implementations included, but only the smarter one is active. (There’s also a really slow HTML5 canvas fallback.)

You can click and drag points around the diagram with your mouse. You can add and remove points with left and right clicks. And if you press the “a” key, the seed points will go for a random walk, animating the whole diagram. Here’s a (HTML5) video showing it off.

Unfortunately, there are some serious problems with this approach. It has to do with passing seed information as uniforms.

  1. The number of seed vertices is hardcoded. The shader language requires uniform arrays to have known lengths at compile-time. If I want to increase the number of seed vertices, I need to generate, compile, and link a new shader to replace it. My implementation actually does this. The number is replaced with a %%MAX%% template that I fill in using a regular expression before sending the program off to the GPU.

  2. The number of available uniform bindings is very constrained, even on high-end GPUs: GL_MAX_FRAGMENT_UNIFORM_VECTORS. This value is allowed to be as small as 16! A typical value on high-end graphics cards is a mere 221. Each array element counts as a binding, so our shader may be limited to as few as 8 seed vertices. Even on nice GPUs, we’re absolutely limited to 110 seed vertices. An alternative approach might be passing seed and color information as a texture, but I didn’t try this.

  3. There’s no way to bail out of the loop early, at least with OpenGL ES 2.0 (WebGL) shaders. We can’t break or do any sort of branching on the loop variable. Even if we only have 4 seed vertices, we still have to compare against the full count. The GPU has plenty of time available, so this wouldn’t be a big issue, except that we need to skip over the “unused” seeds somehow. They need to be given unreasonable position values. Infinity would be an unreasonable value (infinitely far away), but GLSL floats aren’t guaranteed to be able to represent infinity. We can’t even know what the maximum floating-point value might be. If we pick something too large, we get an overflow garbage value, such as 0 (!!!) in my experiments.

Because of these limitations, this is not a very good way of going about computing Voronoi diagrams on a GPU. Fortunately there’s a much much better approach!

A Smarter Approach

With the above implemented, I was playing around with the fragment shader, going beyond solid colors. For example, I changed the shade/color based on distance from the seed vertex. A results of this was this “blood cell” image, a difference of a couple lines in the shader.

That’s when it hit me! Render each seed as cone pointed towards the camera in an orthographic projection, coloring each cone according to the seed’s color. The Voronoi diagram would work itself out automatically in the depth buffer. That is, rather than do all this distance comparison in the shader, let OpenGL do its normal job of figuring out the scene geometry.

Here’s a video (GIF) I made that demonstrates what I mean.

Not only is this much faster, it’s also far simpler! Rather than being limited to a hundred or so seed vertices, this version could literally do millions of them, limited only by the available memory for attribute buffers.

The Resolution Catch

There’s a catch, though. There’s no way to perfectly represent a cone in OpenGL. (And if there was, we’d be back at the brute force approach as above anyway.) The cone must be built out of primitive triangles, sort of like pizza slices, using GL_TRIANGLE_FAN mode. Here’s a cone made of 16 triangles.

Unlike the previous brute force approach, this is an approximation of the Voronoi diagram. The more triangles, the better the approximation, converging on the precision of the initial brute force approach. I found that for this project, about 64 triangles was indistinguishable from brute force.

Instancing to the Rescue

At this point things are looking pretty good. On my desktop, I can maintain 60 frames-per-second for up to about 500 seed vertices moving around randomly (“a”). After this, it becomes draw-bound because each seed vertex requires a separate glDrawArrays() call to OpenGL. The workaround for this is an OpenGL extension called instancing. The WebGL extension for instancing is ANGLE_instanced_arrays.

The cone model was already sent to the GPU during initialization, so, without instancing, the draw loop only has to bind the uniforms and call draw for each seed. This code uses my Igloo WebGL library to simplify the API.

var cone = programs.cone.use()
        .attrib('cone', buffers.cone, 3);
for (var i = 0; i < seeds.length; i++) {
    cone.uniform('color', seeds[i].color)
        .uniform('position', seeds[i].position)
        .draw(gl.TRIANGLE_FAN, 66);  // 64 triangles == 66 verts
}

It’s driving this pair of shaders.

/* cone.vert */
attribute vec3 cone;
uniform vec2 position;

void main() {
    gl_Position = vec4(cone.xy + position, cone.z, 1.0);
}

/* cone.frag */
uniform vec3 color;

void main() {
    gl_FragColor = vec4(color, 1.0);
}

Instancing works by adjusting how attributes are stepped. Normally the vertex shader runs once per element, but instead we can ask that some attributes step once per instance, or even once per multiple instances. Uniforms are then converted to vertex attribs and the “loop” runs implicitly on the GPU. The instanced glDrawArrays() call takes one additional argument: the number of instances to draw.

ext = gl.getExtension("ANGLE_instanced_arrays"); // only once

programs.cone.use()
    .attrib('cone', buffers.cone, 3)
    .attrib('position', buffers.positions, 2)
    .attrib('color', buffers.colors, 3);
/* Tell OpenGL these iterate once (1) per instance. */
ext.vertexAttribDivisorANGLE(cone.vars['position'], 1);
ext.vertexAttribDivisorANGLE(cone.vars['color'], 1);
ext.drawArraysInstancedANGLE(gl.TRIANGLE_FAN, 0, 66, seeds.length);

The ugly ANGLE names are because this is an extension, not part of WebGL itself. As such, my program will fall back to use multiple draw calls when the extension is not available. It’s only there for a speed boost.

Here are the new shaders. Notice the uniforms are gone.

/* cone-instanced.vert */
attribute vec3 cone;
attribute vec2 position;
attribute vec3 color;

varying vec3 vcolor;

void main() {
    vcolor = color;
    gl_Position = vec4(cone.xy + position, cone.z, 1.0);
}

/* cone-instanced.frag */
varying vec3 vcolor;

void main() {
    gl_FragColor = vec4(vcolor, 1.0);
}

On the same machine, the instancing version can do a few thousand seed vertices (an order of magnitude more) at 60 frames-per-second, after which it becomes bandwidth saturated. This is because, for the animation, every vertex position is updated on the GPU on each frame. At this point it’s overcrowded anyway, so there’s no need to support more.

]]> Revisiting an N-body Simulator urn:uuid:4e450cd9-5541-3ff4-0c15-351a77926825 2012-09-19T00:00:00Z Ten years ago I was a high school senior taking my second year of physics. Having recently reviewed vectors and gravity, as well as being an avid Visual Basic programmer at the time, I decided to create my own n-body simulation. I recently came across this old project and fortunately (since I can no longer compile it) I had left a compiled version with the source code. Here it is in Wine,

Really, it’s really not worth downloading but I’m putting a link here for my own archival purposes.

I didn’t quite understand what I was doing so I screwed up the math. All the vector computations were done independently. Integration was done by Euler method — a sin I continue to commit regularly to this day but now I’m at least aware of the limitations. Despite this, it was still accurate enough to look interesting.

Probably the most advanced thing to come out of it, and something I did do correctly, was the display. I worked out my own graphics engine to project three-dimensional star coordinates onto the two-dimensional drawing surface, re-inventing perspective projection.

As I said, I recently came across it again while digging around my digital archives. Now that I’m a professional developer I wondered how much faster I could do the same thing with just a few hours of coding. I did it in C and my implementation was about an order of magnitude faster. Not as much as I hoped, but it’s something!

It’s still Euler method integration, the bodies are still point masses, and there are no collisions so there’s numerical instability when they get close. However, I did get the vector math right! My goal was to make something that looked interesting rather than an accurate simulation, so all of this is alright.

I only wrote the simulation, not a display. To display the output I just had GNU Octave plot it for me, which I turned into videos. This first video is a static view of the origin of the coordinate system. If you watch (or skip) all the way to the end you’ll see that the galaxy drifts out of view. This is due to a bias in the random number generator — the galaxy’s mass was lopsided.

After seeing this drift I added dynamic pan and zoom, so that the camera follows the action. It’s a bit excessive at the beginning (the camera is too dynamic) and the end (the camera is too far out).

I bit more tweaking of the galaxy start state (normal distribution, adding initial velocities) and the camera and I got this interesting result. The galaxy initially bunches into two globs, which then merge.

I wouldn’t have bothered with a post about this but I think these videos turned out to be interesting.

]]> Perlin Noise With Octave, Java, and OpenCL urn:uuid:830cc950-634a-3661-135a-b932c8c5399e 2012-06-03T00:00:00Z I recently discovered that I’m an idiot and that my old Perlin noise post was not actually describing Perlin noise at all, but fractional Brownian motion. Perlin noise is slightly more complicated but much more powerful. To learn the correct algorithm, I wrote three different implementations (perlin-noise).

git clone git://github.com/skeeto/perlin-noise.git

In short, Perlin noise is based on a grid of randomly-generated gradient vectors which describe how the arbitrarily-dimensional “surface” is sloped at that point. The noise at the grid points is always 0, though you’d never know it. When sampling the noise at some point between grid points, a weighted interpolation of the surrounding gradient vectors is calculated. Vectors are reduced to a single noise value by dot product.

Rather than waste time trying to explain it myself, I’ll link to an existing, great tutorial: The Perlin noise math FAQ. There’s also the original presentation by Ken Perlin, Making Noise, which is more concise but harder to grok.

When making my own implementation, I started by with Octave. It’s my “go to language” for creating a prototype when I’m doing something with vectors or matrices since it has the most concise syntax for these things. I wrote a two-dimensional generator and it turned out to be a lot simpler than I thought it would be!

Because it’s 2D, there are four surrounding grid points to consider and these are all hard-coded. This leads to an interesting property: there are no loops. The code is entirely vectorized, which makes it quite fast. It actually keeps up with my generalized Java solution (next) when given a grid of points, such as from meshgrid().

The grid gradient vectors are generated on the fly by a hash function. The integer x and y positions of the point are hashed using a bastardized version of Robert Jenkins’ 96 bit mix function (the one I used in my infinite parallax starfield) to produce a vector. This turned out to be the trickiest part to write, because any weaknesses in the hash function become very apparent in the resulting noise.

Using Octave, this took two seconds to generate on my laptop. You can’t really tell by looking at it, but, as with all Perlin noise, there is actually a grid pattern.

I then wrote a generalized version, perlin.m, that can generate arbitrarily-dimensional noise. This one is a lot shorter, but it’s not vectorized, can only sample one point at a time, and is incredibly slow. For a hash function, I use Octave’s hashmd5(), so this one won’t work in Matlab (which provides no hash function whatsoever). However, it is a lot shorter!

%% Returns the Perlin noise value for an arbitrary point.
function v = perlin(p)
  v = 0;
  %% Iterate over each corner
  for dirs = [dec2bin(0:(2 ^ length(p) - 1)) - 48]'
    q = floor(p) + dirs'; % This iteration's corner
    g = qgradient(q); % This corner's gradient
    m = dot(g, p - q);
    t = 1.0 - abs(p - q);
    v += m * prod(3 * t .^ 2 - 2 * t .^ 3);
  end
end

%% Return the gradient at the given grid point.
function v = qgradient(q)
  v = zeros(size(q));
  for i = 1:length(q);
      v(i) = hashmd5([i q]) * 2.0 - 1.0;
  end
end

It took Octave an entire day to generate this “fire” video, which is ridiculously long. An old graphics card could probably do this in real time.

This was produced by viewing a slice of 3D noise. For animation, the viewing area moves in two dimensions (z and y). One dimension makes the fire flicker, the other makes it look like it’s rising. A simple gradient was applied to the resulting noise to fade away towards the top.

I wanted to achieve this same effect faster, so next I made a generalized Java implementation, which is the bulk of the repository. I wrote my own Vector class (completely unlike Java’s depreciated Vector but more like Apache Commons Math’s RealVector), so it looks very similar to the Octave version. It’s much, much faster than the generalized Octave version. It doesn’t use a hash function for gradients — instead randomly generating them as needed and keeping track of them for later with a Map.

I wanted to go faster yet, so next I looked at OpenCL for the first time. OpenCL is an API that allows you to run C-like programs on your graphics processing unit (GPU), among other things. I was sticking to Java so I used lwjgl’s OpenCL bindings. In order to use this code you’ll need an OpenCL implementation available on your system, which, unfortunately, is usually proprietary. My OpenCL noise generator only generates 3D noise.

Why use the GPU? GPUs have a highly-parallel structure that makes them faster than CPUs at processing large blocks of data in parallel. This is really important when it comes to computer graphics, but it can be useful for other purposes as well, like generating Perlin noise.

I had to change my API a little to make this effective. Before, to generate noise samples, I passed points in individually to PerlinNoise. To properly parallelize this for OpenCL, an entire slice is specified by setting its width, height, step size, and z-level. This information, along with pre-computed grid gradients, is sent to the GPU.

This is all in the opencl branch in the repository. When run, it will produce a series of slices of 3D noise in a manner similar to the fire example above. For comparison, it will use the CPU by default, generating a series of simple-*.png. Give the program one argument, “opencl”, and it will use OpenCL instead, generating a series of opencl-*.png. You should notice a massive increase in speed when using OpenCL. In fact, it’s even faster than this. The vast majority of the time is spent creating these output PNG images. When I disabled image output for both, OpenCL was 200 times faster than the (single-core) CPU implementation, still spending a significant amount of time just loading data off the GPU.

And finally, I turned the OpenCL output into a video,

That’s pretty cool!

I still don’t really have a use for Perlin noise, especially not under constraints that require I use OpenCL to generate it. The big thing I got out of this project was my first experience with OpenCL, something that really is useful at work.

]]> Making Your Own GIF Image Macros urn:uuid:dc4ca81c-6c35-33f6-58c5-a77a645f3fbf 2012-04-10T00:00:00Z This tutorial is very similar to my video editing tutorial. That’s because the process is the same up until the encoding stage, where I encode to GIF rather than WebM.

So you want to make your own animated GIFs from a video clip? Well, it’s a pretty easy process that can be done almost entirely from the command line. I’m going to show you how to turn the clip into a GIF and add an image macro overlay. Like this,

The key tool here is going to be Gifsicle, a very excellent command-line tool for creating and manipulating GIF images. So, the full list of tools is,

Here’s the source video for the tutorial. It’s an awkward video my wife took of our confused cats, Calvin and Rocc.

My goal is to cut after Calvin looks at the camera, before he looks away. From roughly 3 seconds to 23 seconds. I’ll have mplayer give me the frames as JPEG images.

mplayer -vo jpeg -ss 3 -endpos 23 -benchmark calvin-dummy.webm

This tells mplayer to output JPEG frames between 3 and 23 seconds, doing it as fast as it can (-benchmark). This output almost 800 images. Next I look through the frames and delete the extra images at the beginning and end that I don’t want to keep. I’m also going to throw away the even numbered frames, since GIFs can’t have such a high framerate in practice.

rm *[0,2,4,6,8].jpg

There’s also dead space around the cats in the image that I want to crop. Looking at one of the frames in GIMP, I’ve determined this is a 450 by 340 box, with the top-left corner at (136, 70). We’ll need this information for ImageMagick.

Gifsicle only knows how to work with GIFs, so we need to batch convert these frames with ImageMagick’s convert. This is where we need the crop dimensions from above, which is given in ImageMagick’s notation.

ls *.jpg | xargs -I{} -P4 \
    convert {} -crop 450x340+136+70 +repage -resize 300 {}.gif

This will do four images at a time in parallel. The +repage is necessary because ImageMagick keeps track of the original image “canvas”, and it will simply drop the section of the image we don’t want rather than completely crop it away. The repage forces it to resize the canvas as well. I’m also scaling it down slightly to save on the final file size.

We have our GIF frames, so we’re almost there! Next, we ask Gifsicle to compile an animated GIF.

gifsicle --loop --delay 5 --dither --colors 32 -O2 *.gif > ../out.gif

I’ve found that using 32 colors and dithering the image gives very nice results at a reasonable file size. Dithering adds noise to the image to remove the banding that occurs with small color palettes. I’ve also instructed it to optimize the GIF as fully as it can (-O2). If you’re just experimenting and want Gifsicle to go faster, turning off dithering goes a long way, followed by disabling optimization.

The delay of 5 gives us the 15-ish frames-per-second we want — since we cut half the frames from a 30 frames-per-second source video. We also want to loop indefinitely.

The result is this 6.7 MB GIF. A little large, but good enough. It’s basically what I was going for. Next we add some macro text.

In GIMP, make a new image with the same dimensions of the GIF frames, with a transparent background.

Add your macro text in white, in the Impact Condensed font.

Right click the text layer and select “Alpha to Selection,” then under Select, grow the selection by a few pixels — 3 in this case.

Select the background layer and fill the selection with black, giving a black border to the text.

Save this image as text.png, for our text overlay.

Time to go back and redo the frames, overlaying the text this time. This is called compositing and ImageMagick can do it without breaking a sweat. To composite two images is simple.

convert base.png top.png -composite out.png

List the image to go on top, then use the -composite flag, and it’s placed over top of the base image. In my case, I actually don’t want the text to appear until Calvin, the orange cat, faces the camera. This happens quite conveniently at just about frame 500, so I’m only going to redo those frames.

ls 000005*.jpg | xargs -I{} -P4 \
    convert {} -crop 450x340+136+70 +repage \
               -resize 300 text.png -composite {}.gif

Run Gifsicle again and this 6.2 MB image is the result. The text overlay compresses better, so it’s a tiny bit smaller.

Now it’s time to post it on reddit and reap that tasty, tasty karma. (Over 400,000 views!)

]]> Rumor Simulation urn:uuid:9fee2022-d273-34d6-0970-546b5e875460 2012-03-09T00:00:00Z A couple months ago someone posted an interesting programming homework problem on reddit, asking for help. Help had already been provided before I got there, but I thought the problem was an interesting one.

Write a program that simulates the spreading of a rumor among a group of people. At any given time, each person in the group is in one of three categories:

  • IGNORANT - the person has not yet heard the rumor
  • SPREADER - the person has heard the rumor and is eager to spread it
  • STIFLER - the person has heard the rumor but considers it old news and will not spread it

At the very beginning, there is one spreader; everyone else is ignorant. Then people begin to encounter each other.

So the encounters go like this:

  • If a SPREADER and an IGNORANT meet, IGNORANT becomes a SPREADER.
  • If a SPREADER and a STIFLER meet, the SPREADER becomes a STIFLER.
  • If a SPREADER and a SPREADER meet, they both become STIFLERS.
  • In all other encounters nothing changes.

Your program should simulate this by repeatedly selecting two people randomly and having them “meet.”

There are three questions we want to answer:

  • Will everyone eventually hear the rumor, or will it die out before everyone hears it?
  • If it does die out, what percentage of the population hears it?
  • How long does it take? i.e. How many encounters occur before the rumor dies out?

I wrote a very thorough version to produce videos of the simulation in action.

It accepts some command line arguments, so you don’t need to edit any code just to try out some simple things.

And here are a couple of videos. Each individual is a cell in a 2D grid. IGNORANT is black, SPREADER is red, and STIFLER is white. Note that this is not a cellular automata, because cell neighborship does not come into play.

Here’s are the statistics for ten different rumors.

Rumor(n=10000, meetups=132380, knowing=0.789)
Rumor(n=10000, meetups=123944, knowing=0.7911)
Rumor(n=10000, meetups=117459, knowing=0.7985)
Rumor(n=10000, meetups=127063, knowing=0.79)
Rumor(n=10000, meetups=124116, knowing=0.8025)
Rumor(n=10000, meetups=115903, knowing=0.7952)
Rumor(n=10000, meetups=137222, knowing=0.7927)
Rumor(n=10000, meetups=134354, knowing=0.797)
Rumor(n=10000, meetups=113887, knowing=0.8025)
Rumor(n=10000, meetups=139534, knowing=0.7938)

Except for very small populations, the simulation always terminates very close to 80% rumor coverage. I don’t understand (yet) why this is, but I find it very interesting.

]]> Lisp Let in GNU Octave urn:uuid:05e5318e-0cf4-3d80-4bf5-da695dbe9e47 2012-02-08T00:00:00Z In BrianScheme, the standard Lisp binding form let isn’t a special form. That is, it’s not a hard-coded language feature, or special form. It’s built on top of lambda. In any lexically-scoped Lisp, the expression,

(let ((x 10)
      (y 20))
  (* 10 20))

Can also be written as,

((lambda (x y)
   (* x y))
 10 20)

BrianScheme’s let is just a macro that transforms into a lambda expression. This is also what made it so important to implement lambda lifting, to optimize these otherwise-expensive forms.

It’s possible to achieve a similar effect in GNU Octave (but not Matlab, due to its flawed parser design). The language permits simple lambda expressions, much like Python.

> f = @(x) x + 10;
> f(4)
ans = 14

It can be used to create a scope in a language that’s mostly devoid of scope. For example, I can avoid assigning a value to a temporary variable just because I need to use it in two places. This one-liner generates a random 3D unit vector.

(@(v) v / norm(v))(randn(1, 3))

The anonymous function is called inside the same expression where it’s created. In practice, doing this is stupid. It’s confusing and there’s really nothing to gain by being clever, doing it in one line instead of two. Most importantly, there’s no macro system that can turn this into a new language feature. However, I enjoyed using this technique to create a one-liner that generates n random unit vectors.

n = 1000;
p = (@(v) v ./ repmat(sqrt(sum(abs(v) .^ 2, 2)), 1, 3))(randn(n, 3));

Why was I doing this? I was using the Monte Carlo method to double-check my solution to this math problem:

What is the average straight line distance between two points on a sphere of radius 1?

I was also demonstrating to Gavin that simply choosing two angles is insufficient, because the points the angles select are not evenly distributed over the surface of the sphere. I generated this video, where the poles are clearly visible due to the uneven selection by two angles.

This took hours to render with gnuplot! Here are stylized versions: Dark and Light.

]]> Cartoon Liquid Simulation urn:uuid:3819c303-f785-3d90-7c85-af2ca32b7ee4 2012-02-03T00:00:00Z Update June 2013: This program has been ported to WebGL!!!

The other day I came across this neat visual trick: How to simulate liquid (Flash). It’s a really simple way to simulate some natural-looking liquid.

  • Perform a physics simulation of a number of circular particles.
  • Render this simulation in high contrast.
  • Gaussian blur the rendering.
  • Threshold the blur.

I [made my own version][fun] in Java, using JBox2D for the physics simulation.

For those of you who don’t want to run a Java applet, here’s a video demonstration. Gravity is reversed every few seconds, causing the liquid to slosh up and down over and over. The two triangles on the sides help mix things up a bit. The video flips through the different components of the animation.

It’s not a perfect liquid simulation. The surface never settles down, so the liquid is lumpy, like curdled milk. There’s also a lack of cohesion, since JBox2D doesn’t provide cohesion directly. However, I think I could implement cohesion on my own by writing a custom contact.

JBox2D is a really nice, easy-to-use 2D physics library. I only had to read the first two chapters of the Box2D manual. Everything else can be figured out through the JBox2D Javadocs. It’s also available from the Maven repository, which is the reason I initially selected it. My only complaint so far is that the API doesn’t really follow best practice, but that’s probably because it follows the Box2D C++ API so closely.

I’m excited about JBox2D and I plan on using it again for some future project ideas. Maybe even a game.

The most computationally intensive part of the process isn’t the physics. That’s really quite cheap. It’s actually blurring, by far. Blurring involves convolving a kernel over the image — O(n^2) time. The graphics card would be ideal for that step, probably eliminating it as a bottleneck, but it’s unavailable to pure Java. I could have pulled in lwjgl, but I wanted to keep it simple, so that it could be turned into a safe applet.

As a result, it may not run smoothly on computers that are more than a couple of years old. I’ve been trying to come up with a cheaper alternative, such as rendering a transparent halo around each ball, but haven’t found anything yet. Even with that fix, thresholding would probably be the next bottleneck — something else the graphics card would be really good at.

]]> Infinite Parallax Starfield urn:uuid:6e9e0ad7-2a63-3c73-bdbc-ced783911f62 2011-06-13T00:00:00Z In my free time I’ve been working on an unannounced line-art space shooter game called Hypernova. It looks a little like Asteroids, but the screen doesn’t wrap around at all. Space is infinite, and there will be all sorts of things going on out there. Quests, loot, ship upgrades and enhancements, hirelings.

It will be using no bitmapped images. All the graphics are vector images described by text files. I was originally intending to follow the same path with sound effects, and rely mostly on MIDI. However, I quickly found out that many computers have no MIDI support at all.

One of the early challenges was a nice starfield background. It has several constraints:

  • Can’t use any bitmapped images.
  • Must work over practically infinite space.
  • I must be able to resize the display
  • Must be fast.

And in addition, there are some unnecessary, but desirable, properties,

  • When leaving a particular location and returning, I’d like to see the same starfield pattern again.

  • At the same time, I never want to see that same pattern at a different position.

When I was a kid I created the effect as a project, but it didn’t have the both the desired properties above. It’s also the method I found over and over when searching the Internet. There is an array of stars. Star positions are translated as the camera moves. If a star ever exits the display, replace it at a random position on the edge of the screen. To create a parallax effect, each star’s translation is scaled by a unique random factor.

However, there’s another algorithm I like much better, and it has both the desirable properties. Space is broken up into a grid of square tiles. To determine the star pattern in any given tile, hash the tile’s position, and use the hash output to generate a few positions within the tiles, which is where stars are drawn. To create a parallax effect, perform it in different layers at different scales.

Here’s what it looks like in the game,

Hypernova is written in Java, with Clojure as a scripting language, so the starfield drawing function looks like this.

public static final int STAR_SEED = 0x9d2c5680;
public static final int STAR_TILE_SIZE = 256;

public void drawStars(Graphics2D g, int xoff, int yoff, int starscale) {
    int size = STAR_TILE_SIZE / starscale;
    int w = getWidth();
    int h = getHeight();

    /* Top-left tile's top-left position. */
    int sx = ((xoff - w/2) / size) * size - size;
    int sy = ((yoff - h/2) / size) * size - size;

    /* Draw each tile currently in view. */
    for (int i = sx; i <= w + sx + size * 3; i += size) {
        for (int j = sy; j <= h + sy + size * 3; j += size) {
            int hash = mix(STAR_SEED, i, j);
            for (int n = 0; n < 3; n++) {
                int px = (hash % size) + (i - xoff);
                hash >>= 3;
                int py = (hash % size) + (j - yoff);
                hash >>= 3;
                g.drawLine(px, py, px, py);
            }
        }
    }
}

Assuming the origin is in the center of the display, it iterates over each tile currently covered by the display. Positions are created by looking at the first couple bits of the hash for X, shift a few off, and looking at the first few bits again for Y. Repeat until we run out of bits. It’s called with different starscales, back to front (darker to lighter), to create layers.

The STAR_SEED is just a Mersenne prime from the Mersenne Twister PRNG. It probably doesn’t matter much what you choose for the seed, but changing it by a single bit will drastically alter the starfield.

As far as I know, Java comes with no decent 32-bit (int) hash functions, which is really one of the biggest roadblocks in implementing effective hashCodes()s. Fortunately, I found an excellent hash function, Robert Jenkins’ 96 bit Mix Function, to do the trick.

/** Robert Jenkins' 96 bit Mix Function. */
private static int mix(int a, int b, int c) {
    a=a-b;  a=a-c;  a=a^(c >>> 13);
    b=b-c;  b=b-a;  b=b^(a << 8);
    c=c-a;  c=c-b;  c=c^(b >>> 13);
    a=a-b;  a=a-c;  a=a^(c >>> 12);
    b=b-c;  b=b-a;  b=b^(a << 16);
    c=c-a;  c=c-b;  c=c^(b >>> 5);
    a=a-b;  a=a-c;  a=a^(c >>> 3);
    b=b-c;  b=b-a;  b=b^(a << 10);
    c=c-a;  c=c-b;  c=c^(b >>> 15);
    return c;
}
]]> GIMP Painting urn:uuid:ed51c226-cd1e-39f3-05e6-c4dda7fcac92 2010-07-21T00:00:00Z

I drew the magic space elevator a few days back after some practice. Here's my very first attempt at this art style,


Full Size Video

And the image itself,

]]> GIMP Space Elevator Drawing urn:uuid:d2383e63-2310-3b31-b03a-67b5fc884cfd 2010-07-19T00:00:00Z

I've been looking for a nearby tabletop gaming group for awhile now. I asked people I knew. I asked around at work. I just couldn't find anyone. Luckily, a new thing that Wizards of the Coast has been doing is D&D Encounters where prepared adventures are run every week openly at local gaming stores. The purpose is for casual players or beginners to be able to freely to play some D&D without needing any commitment, preparation, or equipment. Characters are pre-generated, so no spending a half hour creating some new player characters every week.

I hopped into it for season two, which just started 6 weeks ago. Each weekly session is a 1.5 to 2 hour combat encounter. I've been having fun, but honestly it's not all that exciting compared to what a real campaign can bring. There is no role-playing, practically no NPC interaction, no puzzles, and no exploration. It also doesn't help that the adventures and characters are riddled with mistakes and very unbalanced. For an example of unbalanced, the character I've been playing, Barcan (or Barqan depending on where you are in the character sheet), could be killed — and I'm not talking about unconscious dying but negative bloodied value dead — by a monster critical strike in just about every encounter so far. Every time a monster attacked me there was a 1 in 20 chance, even at full health, that I might be done playing for the week.

But the great part is that it got me connected to other players in my area, which I think is the most valuable part of Encounters. One of my fellow players was just starting a regular gaming group and invited me to come along, so we've been playing on weekends now, with the intention of taking turns as the DM among those who are interested. And for a little irony, everyone except one person in the group also works at the lab. I guess I didn't ask around enough!

So I'm going to be DMing a 4e Dungeons and Dragons campaign sometime in the near future, and I'm quite excited about it!

Anyway, what does that have to do with drawing a space elevator in the GIMP? First of all, if you're one of the players in my group who found their way here stop reading now. You'll find out all this in the first session, so come back after that. So, I've had this campaign idea in my head for a couple of years now, and it involves a skyhook of sorts constructed by a combination of careful engineering and powerful arcane magic. It leads somewhere, not space, but somewhere. Since that somewhere is part of the mystery I won't reveal where that is, but if the campaign goes well I'll write about it more in the future.

When I run the first session I want to illustrate the skyhook to the players. Show, not tell they say. I like some of the work people do imitating Bob Ross in the GIMP. I've done a few of these to try it out, and it's surprising how well it can turn out even from a beginner. I employed this new art education to draw my skyhook for my game. The GIMP undo history reveals how I did it,


Full Size Video

And the result,

In retrospect I should have drawn the skyhook right after I finished those first clouds, since it's behind everything else in the scene. Oh, and that thing on the bottom left is a twisted scar left behind from a previous attempt at building the skyhook, but it collapsed. It's a dangerous place to be.

]]> Wisp Screencasts urn:uuid:55bef550-79a4-370d-ee00-679a3f13328e 2010-02-04T00:00:00Z

I've been chugging away on Wisp, announced in my last post, every day since I started it a few weeks ago, and it's becoming a pretty solid system. There's now an exception system, reference counting for dealing with garbage, and a reentrant parser. It's no replacement for any other lisps, but I've found it to be very fun to work on. 

git clone git://github.com/skeeto/wisp.git

I wanted to show off some of the new features of Wisp, and since I was inspired by Full Disclojure, since it's so damn slick, I decided to make some screencasts of Wisp in action. All of the screencast software for GNU/Linux is pretty poor, but after a few hours of head-banging I managed to hobble something together for you. Enjoy!

That video demonstrated the memoization function. It can be pulled in from the memoize library. You give it a symbol, which should have a function definition stored in it, and it will installed a wrapper around it. In the video I used the Fibonacci function from the examples library. 

(require 'examples)
(fib 30) ; Slooooow ...
(memoize 'fib)
(fib 100) ; Fast!

This demonstrated the "detachment" feature of Wisp, which is similar to "futures" in Clojure. It forks off a new process, which executes the given function. The send function can be used in the detached process to send any lisp objects back to the parents, which can receive them with the receive function. The send function can be called any number of times to continually send data back. The receive function will block if there is no lisp object to receive yet. 

(require 'examples)
(setq d (detach (lambda () (send (fib)))))
(receive d) ; Gets value from child process

This video shows off the point-free functions that have been defined: function composition and partial application (I accidentally say "partial evaluation" in the video). These are actually just simple macros that any lisp could do.

]]> SumoBots Programming Game urn:uuid:dcd695f6-8c7f-3fdd-5368-cbec6965764f 2009-09-02T00:00:00Z

In the summer of 2007 my friend, Michael Abraham, and I wrote a robot programming game in Matlab. The idea came out of a little demo he wrote where one circle was chasing another circle. Eventually the circles could be run by their own functions, then they were shooting at each other, then dropping mines, and so on. It was dubbed "Matbots".

It turned into a little programming competition among several of us at work. Someone would invent a new feature, like cooperative bots or bullet dodging, that would allow it to dominate for awhile. Then someone else would build on that and come up with some other killer feature. At one point we even hooked up a joystick so we could control our own bot live against our creations.

I never shared that here. Someday I will.

Anyway, Mike took a little bit of the Matbots code and design and came up with a new, similar game called SumoBots. Programmable bots are in a frictionless circular playing area with the ability to accelerate in any direction. Collisions between bots are governed by a spring force dynamics. Bots are out of the game when they leave the circular area. The goal is to knock out all the other bots. Here's a video,

I like how smooth and natural that looks.

He got a number of people at his lab to code up some bots to compete. I threw the code up over at bitbucket, a Mercurial host, which you can checkout with, 

hg clone http://bitbucket.org/skeeto/sumobots/

(I haven't convinced anyone else over there to use a version control repository, let alone this one, but here's hoping!)

You can use either Matlab or Octave to program your bot. It works in both, with Octave being on the slow side. For Octave, you'll need to define a cla function as a call to clf (they don't define it for some reason). To start coding a bot, just look at the samplebot bot for information on programming a bot. Edit the players in player_list.txt, then launch it by running engine (engine.m).

I wrote one bot so far called bully. It charges at the nearest bot, being careful to cancel out its own velocity. In the video above this bot is red.

The other bots so far is kyleBot, blue in the video, which passively runs circles around the outside of the surface hoping to trick aggressive bots, like mine, into running out. The bot2fun bot, black in the video, is like bully, but tries to keep safely near the center of the playing area. The brick bot, green in the video, is a dummy, practice bot that just gets knocked around.

The tricky part in writing a bot is managing the frictionless surface. Acceleration can't just be in the direction you want to travel, but also against the current velocity. You might want to set up some kind of process control for this.

Right now I think there is a balance issue. Passive bots have an advantage, but the game won't progress if everyone takes this advantage and writes passive bots. It's like camping in a first-person shooter. As a partial solution to these stalemates, Mike has proposed that the playing surface should shrink over time.

If you want to join in, grab the code and start coding.

]]> Up is Down urn:uuid:c4c73c3e-07ac-3a52-3358-bf69df5a2be7 2008-06-26T00:00:00Z

I was in an elevator the other day and I noticed something about the digital numbers. I was on the 7th floor going down. Inside the elevator was the standard 7-bar number display indicating the current floor,

Digital number 8

However, from the angle I was standing, the top right bar was not visible. Like this,

Digital number 8 covered

The arrow was indicating that the elevator was traveling downward, but with that bar in the way the numbers can appear to be going upwards, not downwards. It is an ambiguity, as without that bar, 6 is equivalent to 8 and 5 is equivalent to 9. One version is covered, the other is not.

Counting up/down Counting down

At first I thought this was simply some kind of quirky behavior of the elevator. "Why is it going up when the arrow points down? Seems like bad design to me!", I thought — until we got to floor 4, where it was obvious what was going on.

"Oh... now I feel foolish."

]]> Iterated Prisoner's Dilemma urn:uuid:4068d624-311a-30f4-a291-63713ffbc932 2007-11-06T00:00:00Z

I was reading about the prisoner’s dilemma game the other day and was inspired to simulate it myself. It would also be a good project to start learning Common Lisp. All of the source code is available in its original source file here:

I have only tried this code in my favorite Common Lisp implementation, CLISP, as well CMUCL.

In prisoner’s dilemma, two players acting as prisoners are given the option of cooperating with or betraying (defecting) the other player. Each player’s decision along with his opponents decision determines the length of his prison sentence. It is bad news for the cooperating player when the other player is defecting.

Prisoner’s dilemma becomes more interesting in the iterated version of the game, where the same two players play repeatedly. This allows players to “punish” each other for uncooperative play. Scoring generally works as so (higher is better),

Player A
coopdefect
Player Bcoop (3,3)(0,5)
defect(5,0)(1,1)

The most famous, and strongest individual strategy, is tit-for-tat. This player begins by playing cooperatively, then does whatever the its opponent did last. Here is the Common Lisp code to run a tit-for-tat strategy,

(defun tit-for-tat ()
  (lambda (x)
    (if (null x) :coop x)))

If you are unfamiliar with Common Lisp, the lambda part is returning an anonymous function that actually plays the tit-for-tat strategy. The tit-for-tat function generates a tit-for-tat player along with its own closure. The argument to the anonymous function supplies the opponent’s last move, which is one of the symbols :coop or :defect. In the case of the first move, nil is passed. These are some really simple strategies that ignore their arguments,

(defun rand-play ()
  (lambda (x)
    (declare (ignore x))
    (if (> (random 2) 0) :coop :defect)))

(defun switcher-coop ()
  (let ((last :coop))
    (lambda (x)
      (declare (ignore x))
      (if (eq last :coop)
          (setf last :defect)
          (setf last :coop)))))

(defun switcher-defect ()
  (let ((last :defect))
    (lambda (x)
      (declare (ignore x))
      (if (eq last :coop)
          (setf last :defect)
          (setf last :coop)))))

(defun always-coop ()
  (lambda (x)
    (declare (ignore x))
    :coop))

(defun always-defect ()
  (lambda (x)
    (declare (ignore x))
    :defect))

Patrick Grim did an interesting study about ten years ago on iterated prisoner’s dilemma involving competing strategies in a 2-dimensional area: Undecidability in the Spatialized Prisoner’s Dilemma: Some Philosophical Implications. It is very interesting, but I really wanted to play around with some different configurations myself. So what I did was extend my iterated prisoner’s dilemma engine above to run over a 2-dimensional grid.

Grim’s idea was this: place different strategies in a 2-dimensional grid. Each strategy competes against its immediate neighbors. (The paper doesn’t specify which kind of neighbor, 4-connected or 8-connected, so I went with 4-connected.) The sum of these competitions are added up to make that cell’s final score. After scoring, each cell takes on the strategy of its highest neighbor, if any of its neighbors have a higher score than itself. Repeat.

The paper showed some interesting results, where the tit-for-tat strategy would sometimes dominate, and, in other cases, be quickly wiped out, depending on starting conditions. Here was my first real test of my simulation. Three strategies were placed randomly in a 50x50 grid: tit-for-tat, always-cooperate, and always-defect. This is the first twenty iterations. It stabilizes after 16 iterations.

(run-random-matrix 50 100 20 '(tit-for-tat always-coop always-defect))

White is always-cooperate, black is always-defect, and cyan is tit-for-tat. Notice how the always-defect quickly exploits the always-cooperate and dominates the first few iterations. However, as the always-cooperate resource becomes exhausted, the tit-for-tat cooperative strategy works together with itself, as well as the remaining always-cooperate, to eliminate the always-defect invaders, who have no one left to exploit. In the end, a few always-defect cells are left in equilibrium, feeding off of always-cooperate neighbors, who themselves have enough cooperating neighbors to hold their ground.

The effect can be seen more easily here. Around the outside is tit-for-tat, in the middle is always-cooperate, and a single always-defect cell is placed in the middle.

(run-matrix (create-three-box) 100 30)

The asymmetric pattern is due to the way that ties are broken.

The lisp code only spits out text, which isn’t very easy to follow whats going on. To generate these gifs, I first used this Octave script to convert the text into images. Just dump the lisp output to a text file and remove the hash table dump at the end. Then run this script on that file:

The text file input should look like this:

You will need Octave-Forge.

The script will make PNGs. You can either change the script to make GIFs (didn’t try this myself), or use something like ImageMagick to convert the images afterward. Then, you compile frames into the animated GIF using Gifsicle.

See if you can come up with some different strategies and make some special patterns for them. You may be able to observe some interesting interactions. The image at the beginning of the article uses all of the listed strategies in a random matrix.

I will continue to try out some more to see if I can find something particularly interesting.

]]>