Biarc Interpolation

May 16, 2014

Interpolating between two points comes up all the time in game development. Most of the time, only a simple linear interpolation is needed. Linear interpolations are great because you can't really get them wrong. There is only one possible line connecting the points. Just follow it. When a curved interpolation is required, the solution gets far more complicated. There are an infinite number of curves to choose from and many methods for generating them: NURBS, Catmull-Rom, Bézier, Hermite, etc. I want to discuss a less common method that will generate circular shaped arcs.

Why would you want a circular interpolation? One reason might be that it is pleasing to eye, but it also has some practical use. If you are making a level editing tool that places roads (or making a game with procedural roads), you will may want turns to resemble their real-world counterparts. A second example, and the one I most often run across, is generating trails behind swords. Sword swings are often animated very fast. You only get a few sample points as the sword arcs through the attack. If you play the animation in slow motion, you'll find that the tip of the sword takes a rather circular path. By generating circular arcs between the sample points, a clean trail can be generated.

 Here's an example of the sword trails I programmed for Spyborgs. There might have been only five or six samples along the whole spin, but I was able to create a smooth arc of vertices. The Spyborgs algorithm was a bit different from what I'm going to present here, but generated similar results (they were actually slightly worse if you know what to look for).   So, how are we going to create these curves? The solution lies in a piece of geometry called a biarc.

Printing Floating-Point Numbers

March 05, 2014

As far as I could find, there are only two open source implementations of floating-point to string conversion that are both efficient and accurate. Each one uses a license requiring attribution in accompanying documentation. Personally, I don't use anything with an MIT or BSD style license because I'd rather avoid the legal baggage. Unfortunately, all of the public domain or Zlib-licensed alternatives don't produce accurate results (sometimes knowingly).

As an everyday tool that is often taken for granted, it might be surprising that it is so rarely implemented, but it's actually nontrivial to solve. It's also one of those problems complex enough where a wise engineer might recommend that "you never write your own", but I like a challenge and have been interested in it for a while. After spending a couple weeks investigating and experimenting, hopefully I can make it a bit more digestible for the curious.

RJ 9-bit

January 7, 2014

I made this font for my updated site design. Every character is made from a 3x3 grid and it supports the basic latin character set (but the punctuation is a bit of a mess to be honest).

Feel free to download and use it as long as you give me credit. It's released under the Creative Commons Attribution 4.0 International License.

Damped Springs

July 20, 2012

I've worked on third-person camera systems for numerous games and I often need a method for smoothing camera motion as the player moves through the world. The player’s motion may create sharp, discontinuous changes in direction, speed or even position. The camera, however, should:

1. Avoid discontinuities in motion. Accelerate and decelerate as needed rather than snap to a new velocity.
2. Never let the player outrun the camera. The farther away he gets, the faster the camera needs to move.
3. Move exactly the same with respect to time regardless of frame rate.

To solve this problem, I often simulate the camera with a set of damped springs.

iSquish

June 3, 2011

iSquish was both my first iPhone app and my first project built with Unity. I wanted to do something very simple to get my toes wet in the whole AppStore process. I did the programming, game design, sound effects, and user interface art. My friend, Takashi, modeled and animated all of the bugs.

All in all, I think going with Unity was worth it for the ease of iteration, portablitly, and the prebuilt editor, but it also came with a set of issues mostly focused on performance. Scripting in Unity is done with C# and C# is not built with the needs of a game in mind. The biggest problem comes from the language itself being built around the concept of allocate and forget with the assumption that performing garbage collection as needed won't be noticed by the user. This is fine in your average application, but in a game setting where you are always pushing the frame rate, the garbage collector is bound to cause a frame rate drop. This results in having to be annoyingly careful with what you do in C# to prevent hidden allocations from taking place. When you start realizing the need to avoid 'foreach' loops in favor of 'for' loops to prevent enumerators from being allocated behind your back, you quickly start to miss the simplicity of C/C++.

;