ClojureScript vs. CoffeeScript for Processing sketches

DECEMBER 2015 UPDATE: I’ve run some tests with the latest ClojureScript and made some minor changes to the code, which significantly improved performance. Read this post for updated numbers. Keeping this post around for archival reasons.

The set up

This whole thing started not as a performance test, but as me experimenting with ClojureScript and Quil while reading Matt Pearson’s Generative Art. As such, it is not the most scientific of comparisons, and instead born out of my notes when exploring how to do sketches with ClojureScript for the web.

Consider the following example:

CoffeeScript

CoffeeScript is a huge improvement, but underneath all that synctactic sugar it’s clearly still Javascript:

Extending types from Clojure while working on the REPL

On the datatypes chapter of Programming Clojure 2nd edition (page 155) there’s the following bit where the CryptoVault is extended to support the default input streams:

The calls to spit/slurp didn’t work on my tests at first, even reloading the namespace.

UnitySteer acceleration smoothing changes

UnitySteer currently has an acceleration smooth rate parameter on TickedVehicle. It’s used to indicate the percentage of the velocity that is actually applied every frame to the current smoothed acceleration.

There’s two major issues with this:

• It’s framerate dependent, making vehicle behavior effectively non-deterministic.
• It makes it impossible to describe acceleration in the terms that people are used to thinking of them, for example 0 to 60 in 5 seconds.

The latter could be handled as an independent behavior or control, which gradually increases the maximum speed for the vehicle, but the former is a definitely something I want to address. And since I’m going to be working on that, I might as well implement the gradual acceleration as well.

The approach I’m thinking of following is adding two properties to AutonomousVehicle for maximum acceleration and deceleration per second. These would be evaluated on CalculatePositionDelta, so that the vehicle implementation can control its own acceleration style.

The only issue with this is that at the point that method is called, we have already assigned a speed to the vehicle when UpdateOrientationVelocity is called. This means the vehicle is supposedly moving at the full velocity, even if not necessarily all of it is being applied.

Overall, it looks like the necessary changes then are:

• Remove accelerationSmoothRate altogether, to eliminate the framerate dependent behavior.
• Add properties for maximum acceleration/deceleration per second to AutonomousVehicle.
• Not set Speed immediately, and instead save it on DesiredSpeed parameter (which is currently pretty much unused).
• When CalculatePositionDelta is called, we gradually lerp Speed to DesiredSpeed based on the time delta.
• Keep the Velocity property on AutonomousVehicle as is – defined as a function of the forward vector and the current speed.

This also has the advantage that it lets us simulate a bit of inertia, where it takes a vehicle a while to stop. It will be a major change and will have an effect on how your agents behave, so keep it in mind before upgrading.