Monthly Archives: September 2015

StarfishJS

I’ve finished porting a substantial chunk of (now completely) my friend Mars Saxman‘s Starfish—a C program for generating seamlessly tiled procedurally-generated wallpapers—into HTML5/JavaScript. You can try it out here, or there are some samples of some of the wallpaper tiles it has generated:

turvey-green-cream-dunes fuscia-avocado-storm regal-age blue-glisten

The original program has five different image-generating algorithms, that are chosen at random, coloried and layered one upon another; my current JavaScript port has only three of the original algorithms (one of them modified), but I’m already so pleased with the results I decided to post the program as it currently stands. I’ll probably get the remaining two image generators ported in the next week (Starfish’s C code is surprisingly easy to adapt into JavaScript). (StarfishJS now has all the layer-generators of the original. Some of them have been modified to my taste.)

If you want a little peak under the hood, you can see the individual image-generating algorithms at play: the three generators currently available are Coswave, Spinflake, Rangefrac, Flatwave, and Bubble.

The image generators all operate in monochrome values, and translated into color later. Some of the generated images aren’t displayed directly, but instead are used to hide/reveal pixels of other layers.

A units-of-measure implementation in JavaScript

I made something kinda interesting this week in JavaScript. It probably qualifies as “over-engineering”, but it was for my use, to meet my needs, and I had making it, and I’m having fun using it (so there! :-p).

It’s an implementation of measurable units of various types that I tend to use in my recent JavaScript-games-making excursions: such as seconds, milliseconds, pixels, radians, and frames. It lets you express that quantities are in rad/s, f/s, px/s^2 (for acceleration values), etc, and convert between them via multiplication and division (px/s divided by a time value results in px/s^2 (pixels-per-second-per-second), or if multiplied produces a value in number-of-pixels). It throws an error if you mix up which units you meant to use, which helps enforce the sanity of the arithmetic you’re performing.

Usage looks something like this:

The reason for this little library is that I’ve frequently run into problems thinking in the wrong units in my games. One variable might hold a length of time in seconds, another in milliseconds (from new Date()), and I’ll try to use them together, forgetting to convert between them. In MajicUnits, they’re all represented in seconds under the hood, and I can specify what unit I want when pulling them back out.

Or I often forget to scale a velocity or acceleration by the inter-frame time before adding to current state, resulting in a full second’s acceleration taking place in a single frame. Using MajicUnits, I’ll see an exception thrown if I forget to multiply by the frame delta.

It’s the sort of stupid error that led to NASA losing its $125 mil Mars orbiter because one group coded for metric units while another used imperial. If you have a language to express (and enforce!) unit types being used, you’ll catch the problem. Better, of course, if you can do it at compile-time, without requiring the offending code to run before you can catch it, but this is JavaScript, and writing my own to-JavaScript compiler that adds units of measure as strictly-enforced types at the language level would be really drastically over-engineering. 🙂

The library’s pretty crude at the moment: I’ve coded exactly as much as I need for the moment. There are places you could feed it bad input and break its assumptions. It automatically creates plural versions of your added units, adding ‘es’ if it ends in ‘s’, otherwise adding ‘s’. That obviously wouldn’t work with ‘activity’ (-> ‘activitys’), and can’t handle exceptions like ‘forum’ -> ‘fora’ or something. Rather than have an automatic pluralizer, I should be having the user explicitly specify when they register the unit… (All of the above is no longer accurate.)

A bigger problem is that when an exception is thrown I can’t currently just find what line of code went wrong. I throw an Error object (which includes file and line number info), but it points at the place inside the library that threw the exception, rather than at the failing invocation that caused the exception. Most implementations of Error provide some sort of stacktrace, so perhaps I can generate one and then turn it into a string that includes that stacktrace info… because when it comes out on my Firefox console I don’t get the stacktrace currently. Anyway.

You can see the current implementation (as of this writing) here (UPDATED), if you’re curious and/or masochistic (it does some magic with JS prototypes to do its job, and lacks any useful documentation/comments, though I plan to add some).

It’s written as one part of this game Gate Arena that I’ve been working on lately, but am rewriting to emphasize a more declarative style of expressing objects and logic and their relationships, to increase code reuse and the ease of adding new enemy types, etc. I plan to reuse the resulting engine for further games, increasing my flexibility for participation in game jams and whatnot.