Parametric Art

I've been meaning to make some "parametric art" for some time now, and having worked on Tale graphics automation, I now have the tools I need. Parametric art is the name I'm using for creation of artistic compositions where the position, orientation, and shading are programmed using what we learned in High School trigonometry by the pseudonym "parametric equations". Last night I decided to attack the problem by making another set of backdrop images for Jason Reinsvold's Bowmaster. I popped open Inkscape, created some layers for sky, sun, moon, and terrain. Instead of hand positioning the Sun and Moon, I just put them on the origin. Then I pulled up my Python SVG tools that I made for generating maps. Using some trig, I programmed the positions and rotations of the sun and moon. Here are some samples:

more

Tomorrow's project is adjusting the linear gradients that overlay the cells in the foreground terrain to catch the light of the sun, moon, sky, or form shadows and silhouettes.

New Character Sprites

I completely recreated the rider (or stand-alone character) for the Tale sprite graphic. The major goal was to represent both genders equally in the game. On the way, I created several hair styles and facial expressions, articulated the arms into three positions for each gender, and created a lot of layers. Here's the breakdown:

• male or female
• round, oval, or angular head
• arms out stretched, bent for holding shields and such, or hanging at your sides
• shirt with detachable sleeves
• pants or shorts
• shoes, boots, or sandals
• buckler, roman shield, hero shield
• long or short, lobed or round ears
• 11 hair styles
• 14 facial expressions

Here are a couple samples of riders:

Portraits

Hey folks. I've been down with the Flu, but I'm getting back in the saddle.

Saturday, a week ago, I stayed up late agonizing about a color module for Cixar Javascript. The new color module builds on the refinement of the Mootools color module and the Cixar Javascript type system. The new Color type provides accessors and mutators for HSL and RGB components and can parse hex strings in both modes. The color also tracks opacity. Under the hood, the Color instance is modal, converting its internal components array to arbitrary modes, radices, and cardinalities. For example, when you parse a six character RGB string, the color implicitly switches to base 256 with values in [0, 256) in RGB mode. When you set its lightness to .5, the color implicitly normalizes its components to HSL mode with values in [0, 1]. When you get the RGB string out, it actually doesn't do a conversion, but makes a copy of the color and converts that to RGB 256 mode so that you don't get floating point propagation error. The color modules is here. I still should port the "invert" function and find a way of consistently calculating "strobes" and "complements", but first I need to beat the definitions out of an art major (easy), but first I need to find a math major who knows some math (hard). All in all, this was a nice diversion, but I don't know whether I'll ever use it and I certainly stayed up too late working on it and fell ill.

I've continued my perusal of Javascript libraries. I started looking into uses for the new canvas tag that debuted in Safari and made its way into Opera and Firefox. Internet Explorer doesn't support the standard, but I found an open source library that Google has contributed to the community called excanvas that transparently causes canvas tags to mostly work in IE. The library performs some VML voodoo and provides an interface consistent with the canvas standard. The interface supports rotation, translation, and turtle drawing, but does not support gradients. I starting paring out pieces of the implementation into a matrix module for Cixar Javascript that provides a Matrix type with Google's matrix multiplication written elegantly and, alas, sub-optimally. Before I pare it out in favor of fast native loops, here's the pretty version:

return matrix.Matrix(
 each(range(value.getWidth()), function (x) {
  return each(range(other.getHeight()), function (y) {
   return sum(each(range(value.getWidth()), function (a) {
    return value[x][a] * otherValue[a][y];
   }));
  });
 })
);

Tale News

I'm redrawing the rider graphic for the sprite. This is the character sprite that will appear on maps, in battle mode, and close up in your inventory or equipment viewer. Additionally, the sprite will provide a small portrait for chats and status messages about your character. The portrait will have interchangeable faces to reflect your mood and also serves as an emoticon. Also, the primary goal in the redraw was to provide male and female variations of the character. So far, I've made the two figures, three arm positions each (outward, bent, and down for holding various armaments), three head shapes, several faces, many hair styles including "lemming", "block", and "dreads", and four kinds of ears. I've also outlined some clothes. Until the whole ensemble is ready, here are some samples for each of the facial expressions:

Javascript Libraries

I've been poring over Javascript libraries lately, trying to ascertain the extent of their features, how much implementation overlap there is among them, and which ones implement certain features best. The idea is that I'm going to integrate the best tidbits into Cixar Javascript. I'm reading:

• Yahoo's YUI,
• Dojo,
• Prototype,
• Mootools,
• Mochikit, and
• Scriptaculous, plus outliers and extensions like
• Flapjax,
• Mooshow,
• iBox, and
• Lightbox.

Please contact me if I need to add a library to my reading list.

I've got some general impressions so far. Dojo and Mochikit are by far the heaviest. They're loaded with lots and lots of well tested unreadable undocumented components. Dojo supports its own weight because it's the only Javascript library that has a module loader, albeit a module loader that loads modules into the global name-space. YUI, Mootools, and Scriptaculous are comparatively higher quality but smaller and limited to their size by the lack of a good module system. YUI is the best documented, having lots of Javadoc style comments. Mootools, I think proves to be the highest quality code for the few things it does and does rather well. Scriptaculous and its base library Prototype, spun off the Ruby on Rails project, both seem to work pretty well, but the code is criminally bad, showing lots of signs of having been designed by whim. I get a very strong "the least that would work" vibe from it.

Dojo's module system intrigued me because it loads modules synchronously with AJAX and Javascript's eval. I've considered applying the same ideas for Cixar Javascript's module system. However, the current Cixar Javascript module system puts the power of nomenclature into the hands of the module writer, not the hands of Kurremkarmerruk, the Wizard who knows and manages all (or most) of the names in the universe. I think that the "CJS" syntax is verbose because of this feature, not because it loads modules asynchronously. Since loading modules asynchronously may have higher performance in the long run, I don't see much reason to adopt Dojo's approach. However, Dojo does include a lot of good snippets that seem to embody a lot of working knowledge on how to make Javascript work in many, many environments, so I do intend to study it throughly.

Let me back these statements up with some code. This is the Dojo syntax for defining, loading, and using a module:

dojo.provide('dojo.provided_module');
dojo.require('dojo.required_module');
dojo.provided_module.provision = dojo.required_module.provision;

This is Cixar Javascript's:

this.register('cixar/provided_module.js', function () {
this.require('cixar/required_module.js', function (that) {
this.provision = that.provision;
});
});

I particularly like using Javascript's with block to effectively bring all of a module into my name-space so that I don't have to qualify any of its names.

this.register('my.js', function () {
this.require('javascript.js', function (js) { with (js) {
assertEq(js.List, List);
}});
});

I'm getting comfortable with the parentheses and braces because I feel that localizing names is really important for the long term maintainability and extensibility of the world of Javascript.

From this preliminary analysis, I think I will be integrating most of Mootools code since it's small and high quality. I will probably also integrate parts of Dojo and Mochikit since their feature coverage is quite extensive, but porting whole modules is probably out of the question. In any case, I will try to bring a comprehensive set of features into CJS so that people coming from any of these frameworks will find some degree of familiarity, if not because of their experience with their respective Javascript libraries, then because of their familiarity with the server side scripting language on which that library was based.

Blowfish

Enough said.

McLorry

The McLorry, powered by a SirFusion reactor, operating by the magical virtues of the LuxTransistor, grants the operator initiative, the ability to dodge circumstance, to correct mistakes made.

Dancing Hamster

At work, someone wondered aloud what had happened to the dancing hamster. I'll tell you what happened: months locked in a caged. Now he's back.

The dancing hamster, ronin, bereft of master, master only of the dancing hamster fu. None have seen the technique and lived.