The driver for the xbox controller built into the kernel (xpad) seems to be quite broken. Luckily there is an alternative. Here is how to set it up under Ubuntu, other Linux distributions might differ.

Blacklist xpad kernel driver

The first step is to blacklist the xpad kernel driver to prevent it from being loaded.

# as root
echo "blacklist xpad" > /etc/modprobe.d/blacklist.conf
#unload module if already loaded
rmmod xpad

Install xboxdrv

# as root
apt-get install xboxdrv

Start xboxdrv

I start xboxdrv manually (as root) before I play. I tried to automate it but it wasn't very reliable.

# check it is working
xboxdrv
# Should output something like
# Your Xbox/Xbox360 controller should now be available as:
# /dev/input/js0

For actually playing I tend to start it with --silent.

This solves all the xbox gamepad issues for me. Steam, Shank, Overgrowth all work fine with xboxdrv.

A little while ago I released a canvas based fluid simulation demo. Now I have the WebGL version ready. It's doing roughly the same thing as the canvas one. It's nicely illustrating how much faster the GPU accelerated WebGL version is compared to the canvas one. As an added benefit, it does not explode anymore because the boundary conditions are now properly enforced.

Demo

View WebGL fluid simulation demo

Code Overview

Most of the interesting code for this demo lives in shaders. Here is an overview of the data flowing between the shaders.

The flow is defined inside the main.js file. All the other logic is in the shader files.

If you are wondering why I left out diffusion in this demo. The way the algorithm works seems to introduce a fair amount of diffusion already so I figured I'd just drop that term. :)

Resources

• The original paper - Stable Fluids by Jos Stam
• Fast Fluid Dynamics Simulation on the GPU - GPU Gems
• Game Physics by David H. Eberly

I have worked on this demo for quite a while. The initial plan was to do a voxel based multiplayer shooter. It didn't turn out to be all that much fun (the movement is clunky and blowing stuff up doesn't provide too much lasting entertainment). So rather than just leaving it all to rot in a dark corner on my disk I decided to just release my prototype as it is.

Experiment

Play with the WebGL Voxel Worlds Demo

Video

Talk

I gave a 30 minute talk on some of the things in this demo at the super awesome ongamestart conference in Poland.

Also at ~12:00 you can see my notebook falling off the lectern. ;)

Source Code

I pushed the source code of this demo to github.

It is really hacky prototype code. Feel free to learn from it (and my mistakes), don't use it in production. If you have questions, feel free to ask. :)

I started to look into fluid simulation a little while ago. It turned out that it's not quite as trivial as I had hoped. That is unless you go for the hacky way as I did back in 2010.

So after getting familiar with the problem and some solutions I implemented a simple fluid simulation using the canvas element. You can find it in my sandbox.

The plan for the next step is to create a WebGL version. I hope that the final result will be a worthy successor to the immensely popular (by my standards) Neon Flames experiment I did last year.

I extracted the simplex noise implementation of my recent voxel experiments into a simple library. You can of course find the source on github. Check out the READ ME or the npm package for more details.

Simple demo

View Demo

I'm happy to finally release something new. I have been playing around with terrain rendering using webgl for quite a while now. I initially planned to release the finished result as a simple game or flight simulator. But because I'm very busy learning to paraglide right now I simply don't have the time for this at the moment. Rather than releasing nothing I decided to just make a little demo out of it. I hope you like it.

Features

• Terrain LOD using CDLOD
• Frustum culling
• Reflective Water
• Emulating user defined clipping planes for reflections using oblique frustums.
• Volumetric fog (kind of)
• Simple collision detection

It's currently not streaming the terrain (loading it all in one go), and there are some other quirks but it mostly works.

Video

If you can't view the actual demo for some reason, I have also created a video demonstrating the different effects in this demo.

Evolution

Here a few shots from the evolution of this demo.

Data

The dataset used for this demo is of the Island of Maui. I got it from from NOAA's National Ocean Service (NOS), National Centers for Coastal Ocean Science (NCCOS). The vertical extents and sea level are not to scale. For the conversion into a usable format I used gdal. The normal map was created in the gimp.

Source

You can find the source on github. The most of the code for the terrain is stuffed into terrain.js. The WebGL implementation of oblique view frustums to emulate user defined clipping planes is in scene.js Keep in mind that this is hacky proof of concept code, that needs a good deal of scrutiny before any production use.

Photo by Horst Gutmann

I recently did a talk on css preprocessors at djangocon.eu. They did a good job at recording it so you can enjoy the talk even if you were not there.

Links

• Video
• Slides

Analyzing the talk

The great thing about having a video is of course that I can analyze my performance. So here are my conclusions:

Plus

• Dry mouth management went well except for the very end.
• Except for the little hiccup with the syntax highlighting it went very smoothly.

Minus

• I seem to handle the presenter in a very stiff way -> posture.
• I don't sound very enthusiastic, except for when I'm being zynical.
  But frankly I am a bit like that in private too.

What I want to improve

I think to two big things to improve would be to make a better case for why you need them (Jonathan Verrecchia did that really well). Also it was a bit boring and 'flat' for the lack of a better word. But I found it really hard to try to find something exciting AND relevant.

Click here to open the tool!

Image error level analysis is a technique that can help to identify manipulations to compressed (JPEG) images by detecting the distribution of error introduced after resaving the image at a specific compression rate. I stumbled across this technique in this presentation by Neal Krawetz and decided to do a quick implementation in JavaScript.

How to use this tool

To analyse an image simply drag and drop it onto the page (requires a modern browser like firefox or chrome). Then play with the quality slider to spot anomalies in the error level. The image I analyzed in the screenshot above is a picture of myself that I modified in GIMP. As you can see the error level on the fake part is quite significantly higher than on the rest of the image. There are no such anomalies on the original.

Having that said the algorithm is not exactly reliable, especially with images that have been rescaled and compressed often/intensely. So take it with a pinch of salt and feel free to have a look at the simple source code.

2012-03-02 - updated to use ruby 1.9.3 and official instead of system rvm.

When trying to install ruby 1.9.2 using rvm I got a nasty suprise:

ossl_ssl.c:110:1: error: ‘SSLv2_method’ undeclared here (not in a function)
ossl_ssl.c:111:1: error: ‘SSLv2_server_method’ undeclared here (not in a function)
ossl_ssl.c:112:1: error: ‘SSLv2_client_method’ undeclared here (not in a function)
make[1]: *** [ossl_ssl.o] Error 1
make[1]: Leaving directory `/var/cache/ruby-rvm/src/ruby-1.9.2-p180/ext/openssl'
make: *** [mkmain.sh] Error 1

The solution

# install rvm
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
# make sure we have $rvm_path
source /etc/profile
# don't use ubuntus openssl
rvm pkg install openssl
rvm install 1.9.3-p125 --with-openssl-dir=$rvm_path/usr

I generally like dynamic languages and in generally don't run into much trouble with them. Having that said, I hate the way undefined and NaN work in Javascript.

This turns a simple typo into a NaN apocalypse. After half of your numbers have turned into NaNs it's hard to find out where they came from.

var o = {y: 0},
#NaN
1/o;
#NaN
var x = 1/o.x;
#NaN
var y = x*10;

Setting up traps

So how do you catch stray NaNs? You set up traps. Because it can become very tedious and error prone to have asserts everywhere I wrote a little helper, fuckNaN().

function fuckNaN(obj, name){
    var key = '__' + name;
    obj.__defineGetter__(name, function(){
        return this[key];
    });
    obj.__defineSetter__(name, function(v) {
        // you can also check for isFinite() in here if you'd like to
        if(typeof v !== 'number' || isNaN(v)){
            throw new TypeError(name + ' isNaN');
        }
        this[key] = v;
    });
}

// Examples
var o = {x: 0};
fuckNaN(o, 'x');
// throws TypeError: x isNaN
o.x = 1/undefined;

// Also works with prototypes
function O(){
    this.x = 0;
}
fuckNaN(O.prototype, 'x');
var o = new O();

// throws TypeError: x isNaN
o.x = 1/undefined;

Place some of those traps during debug mode in critical locations like your Vector and Matrix classes and they will bring doom and destruction to those NaNs..

Note: This doesn't work in IE<=8 and you shouldn't use it in production. Use it as a tool during development to make your code fail early.