One of those extensions, which I implemented just in time for Wesnoth 1.6, and later gave it a separate syntax of its own was palette-switching using the same secondary algorithm used by the game’s color range-based team-coloring code. The
~PAL() functor, originally implemented as an extension to
~RC(), was thus born.
Wesnoth RCX 0.2 is not out yet due to some heavy refactoring that’s in progress, but a major feature that it’s going to sport in this opportunity is the ability to define custom color ranges and palettes.
The aforementioned extension to the game engine, which I shortly merged into the command-line based Wesnoth-TC tool, was originated by a possibility Jetrel discussed with me on IRC, namely randomizing individual units’ hair colors (and other compatible traits) on recruit. This sure doesn’t sound like a major task from the C++ side, and in fact the only thing missing right now is a transparent mechanism for defining these variations in
[unit_type] nodes. However, it involves heavy revisions in the art department, to clear any traces of paintbrush strokes and sprites using excessive shades of a single color.
The goal: defining strict palette sets for recoloring. Above: Jetrel’s WIP revised baseframes for some of the elves.
Since trying artwork transforms like this in the game can easily become a tedious task (and not just because of the WML coding), Wesnoth RCX is soon going to step forward and provide artists with the ability to try out their own color ranges and palette sets and tweak them as required until achieving the wanted result. I hope that Wesnoth RCX will not just become the artists’ favorite tool, but more like an essential item for the mainline art development workflow.
Another couple of features are also going to feature in 0.2: zooming (suggested by artisticdude in the forums), and compete drag-n-drop support, so users can drag the transformed image into their favorite image editing application for further tinkering. I’m sure Mac users will especially like this new addition.