At long last, 2011 is coming to an end. In a few hours, we’ll have to dump our old calendars to replace them with new ones bearing the number 2012 in a big font size. Then the people who believe 2012 will be the end of life on Earth will begin to panic as we approach December again. Those nutcases.

This was a relatively calm and monotone year in what pertains to my personal life, so I’m not going to delve into details in this opportunity. However, I made some resolutions last New Year and it might be worth it to review them and check why I didn’t accomplish all of my goals.

• Learning Japanese: I got severely sidetracked after a while. I may still try again in the future, just because.
• Losing weight: I may have gained some a lot of weight during the course of the year. Oops. I did, however, stop drinking coffee, because my stomach started to reject (read: try to vomit) it after a while for some reason.
• Wesnoth RCX: Still halted. Frankly, there doesn’t seem to be enough interest amongst the Wesnoth community nowadays for this kind of tool, and for my own purposes Wesnoth-TC serves well as it is.
• Relearning C♯: Also sidetracked. It doesn’t seem worth it, in hindsight.
• Learning Lua: Accomplished according to certain definitions. I haven’t really learned more about the language than necessary, but I have indeed committed some Lua code to mainline Wesnoth, and several tasks of varying difficulty are accomplished with custom Lua-backed WML tags in After the Storm and Invasion from the Unknown as of this writing.
• Rei 2 IRC Bot: Stalled, due to lack of interest. There are also seem to be a few Irssi-specific problems with Perl 5.14, which is in the operating system I’m using at the moment, Debian wheezy.
• Website: Accomplished. In fact, in a few hours I’ll deploy a few minor changes to the code to optimize the blog template processing a bit.

One particular resolution deserves separate analysis, though:

Then there’s Wesnoth. I intend to finish the Second Act™ of After the Storm Episode I as soon as I may, even through the means of placeholders — I’m willing to do anything to rescue AtS out of Development Hell before the end of 2011.

I didn’t resort to unlawful methods to accomplish this goal as I originally feared, but it still happened! Granted, rather late.

During September and October I had a rather unexpected creativity and productivity spurt which culminated with the release of AtS version 0.5.0 with Episode I: Fear complete with 13 scenarios. More recently in December, we reached version 0.6.1 with 7 complete scenarios for Episode II: Fate. As of this writing, E2S8 and E2S9 are also complete in SVN trunk in Wesnoth-UMC-Dev, although it’s been suggested that the latter could use some spicing up. E2S10 is a work in progress since yesterday, and part of E2S12 was written already back in October, just not committed.

Thus, it could be said that after many difficulties, After the Storm broke out of Development Hell. Whether I’ll consider Episode III: Final (expected to be shorter, around 6 scenarios) part of the required line-up for version 1.0.0 is a matter I haven’t settled yet.

Once After the Storm is finished, I plan to take a rather long break from campaign development. That isn’t to say I’m out of ideas, since there is one character I want to explore in further detail in her own campaign. However, I may have my Wesnoth time taken up by mainline work after 1.10 is released depending on the situation then, since there’s a rather large technology gap in Wesnoth that needs to be solved.

Other than that, I haven’t really decided on any resolutions for 2012, so I’ll leave you with the one resolution of the moment:

...
screen #0:
  dimensions:    1280x800 pixels (338x211 millimeters)
  resolution:    96x96 dots per inch
...

(This information is utterly wrong. xdpyinfo reported the same screen dimensions on bluecore last year in spite of its screen being glaringly larger than reicore’s by a few milimeters.)

Don’t throw your shoes at me! I didn’t come to continue the overly long “display resolution” gag!

I have been thinking about some stuff to do during this year for a while, actually. It’s really hard to decide because I’m a person who runs into all sort of trouble while trying to get projects accomplished (including procrastination).

One thing I’m already doing is learning some Japanese, for no particular reason at all — although you’ve got to admit that having multiple languages in your curriculum is worth a bunch of coolness points. Espreon is helping me along the way with his own recently gained knowledge. It seems quite fun to learn a language in a non-Latin alphabet, if not a tad overwhelming at times, especially with kanji.

It’d be a good idea to lose some weight this year, too. My addiction to sugary stuff isn’t quite compatible with my heart condition! (Nor is coffee, but… meh.)

Then there’s Wesnoth. I intend to finish the Second Act™ of After the Storm Episode I as soon as I may, even through the means of placeholders — I’m willing to do anything to rescue AtS out of Development Hell before the end of 2011.

Wesnoth RCX’s development is halted right now due to lack of interest on my part to invest energy on writing the rest of the new functionality (i.e. definition of custom ranges and palettes), but I know that once I touch Qt Creator’s awesome interface I can’t stop working for a while — so I may eventually get some inspiration to redesign the main window, which should inevitably lead me to tinker around with the rest of the code.

C# was the first “major” programming language I learned, not counting Visual Basic. I have some fond memories of my first experiments with C#, but after I embarked upon learning and using C++ I kind of forgot about it. I have been considering the possibility of writing an IRC client of sorts using C# just for kicks, and to not forget this language in case I ever need it again. Why IRC? Because clients for this protocol are simple and challenging to implement, both at the same time!

I’ve already started to learn a bit of Lua for my work on the aforementioned Wesnoth campaign — in fact, there’s already some released code within it written in this language, particularly in scenario 5! I have plans to rewrite parts of Invasion from the Unknown in Lua to clean it up a little, thus paving the road for future maintenance work by me or other people (don’t forget that IftU is still abandoned!).

Another software project I intend to tackle in the short term is Rei 2. Sure, she’s doing well and her main command handlers are many and useful enough for channels such as ##shadowm and #wesnoth-umc-dev, but her dependence on Irssi’s core might well be a curse for one of our use cases: Shikadibot (the Second), which runs on a resource-limited VPS where every drop of RAM has got gold value. I’m already brainstorming a possible abstraction layer (codenamed “API 3”) which could allow the Irssi core to be swappable with a custom, native IRC client core (codenamed “Anya”). There’s really not much in the current Irssi-based implementation of the internal interfaces (“API 2”) that make a dependency switch unfeasible.

Finally, I’m not going to stop producing useless updates for my website! Dorset5 0001 is already a reality, although there’s still much I want to do before replacing the current layout. This time I have placed an emphasis on readability and elegance that I don’t think the previous revisions have lived up to so far.

• • •

All in all, I always have so many ideas floating in my mind that I rarely carry to realization, so this can’t be considered a definitive list. There are other possibilities I’m contemplating for the long term regarding my personal life, but that’s a much more volatile subject to discuss so I’m avoiding it for now.

A new feature release of Wesnoth RCX is now available!

• Source code: wesnoth-rcx-0.1.4.tar.gz (Gzip tarball, 64.2 KiB)
  SHA1 checksum: 8ca7f6354827c56aba4526f2f504d8db34f7acf0
• Windows package: wesnoth-rcx-0.1.4-win32.zip (Zip archive, 5.2 MiB)
  SHA1 checksum: 3832ddb798110f2e890aecc37519097e1e18e2b6
• Mac OS X binary: wesnoth-rcx-0.1.4.app.zip (Bundle, 14.9 MiB)
  SHA1 checksum: 60a5724d35b0bf64d02b4553ff9c1543d5964344
  This binary is kindly provided by Alarantalara from the forums.

The only major change in this version is the addition of zoom support in the user interface, so you can take a look at your team-colored pixel art at 100%, 200%, 400% and 800%, or even at 50%. No more levels are supported at the moment, and will probably never be unless you submit a patch — this is really just supposed to be a help tool, so if you need more exotic zoom levels use a real graphics manipulation tool such as Adobe Photoshop or the GIMP. And don’t forget you can also drag and drop images now!

There’s also a brand-new grayed-out menu for you to observe and admire. Only observe — don’t touch it.

As with the last time, the instructions for building the source are in the included INSTALL file in the distribution archive. This file is not present in the Win32 distribution for obvious reasons.

Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!

It’s almost over. Time flies even faster as we get closer to the end of 2010, and apparently there’s a lot to summarize despite we’re not in the finish line yet!

This has been a particularly difficult year for me in a more personal sense, and I’ve faced some trials I won’t speak about and then some, but I’ve also learned new things in the road — things that may be of greater use to me in the future. There’s really a lot that could be said about this year but I’ll restrict it to computer stuff to avoid boring the audience too much bore the audience as much as possible.

Long ago, Jetrel from the Battle for Wesnoth Project contacted me regarding possible extensions to the image path functors module of the game engine.

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.

Release early, release often, they say.

The source code, and a brand-new Windows binary for a new bugfix release of Wesnoth RCX are now available!

• Source code: wesnoth-rcx-0.1.3.tar.gz (Gzip tarball, 64 KiB)
  SHA1 checksum: 8da029389cda28adde02d51d054be7c1108a20d2
• Windows package: wesnoth-rcx-0.1.3-win32.zip (Zip archive, 5.2 MiB)
  SHA1 checksum: bb35cf5c11daaa9de16d67f512ca7bdd6292a0c5
• Mac OS X binary: morningstar.app.zip (Bundle, 12.7 MiB)
  SHA1 checksum: 66f9f0b4fdf447564a9fb3f73898ba8479402694
  This binary is kindly provided by Alarantalara from the forums.

The only important change in this version fixes a bug in 0.1.2 and earlier causing job output to be created out of sequence — file #1 and #2 would be red TC, #3 blue, #4 green, and so on.

As my Twitter followers can tell, I downloaded and installed the Qt4 SDK for Windows and successfully compiled and ran Wesnoth RCX on a virtual machine with Windows XP SP3. Some additional DLLs are included in the package, so it’s necessary to run the included morningstar.exe from the original folder after extraction. I don’t think I’ll bother with an installer this soon, since this is after all a work-in-progress and I can’t concentrate on programming and packaging at the same time.

I do hope however that the existence of a Windows (2000/XP and later) version of RCX will help spread the word and attract more testers and artists to it.

As with the last time, the instructions for building the source are in the included INSTALL file in the distribution archive. This file is not present in the Win32 distribution for obvious reasons.

Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!

The source code for a new revision release of Wesnoth RCX is now available.

• Version 0.1.2 (Gzip tarball, 60 KiB)
  SHA1 checksum: 060e45725711a4f4dca284af1ceec2a144042fe4

The main changes in this version include adding support for dropping files into the application’s window or shortcut, and allowing to open more compatible file formats: Windows Bitmap (BMP), and depending on Qt4’s configuration, Photoshop PSD and GIMP XCF — note that output is still solely in the PNG format for simplicity and it’ll remain so.

I sort of promised support for dragging images from RCX, but that won’t be possible yet because it’s not as trivial as drop support and I’m too lazy at the moment. I also made a few minor revisions in the UI, but you probably don’t care about that or any of this until I can offer Windows and Mac OS X binaries — unfortunately, we’re not quite there yet because I need your help for that. It’s not magic. I can’t make it work without an adequate development environment for each platform and, as you should know at this point, I don’t own any Mac machines.

The instructions for using the source code don’t follow this time. I know what you think , so it’s up to you to read the included INSTALL file in the distribution archive.

Feedback

Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!

Now working on drag-and-drop support for Wesnoth RCX. Dropping image files and actual image data already works with some simple and quickly crafted code thanks to Qt4’s power and simplicity. The next logical step is enabling RCX to drag the original and generated image data to other applications.

After that, RCX 0.1.2!

A new revision of codename “Morning Star” is available, this time with a preliminary production name — meet Wesnoth RCX 0.1.1.

• Version 0.1.1 (Gzip tarball, 32 KiB)
  SHA1 checksum: bdb9c31e6e43ca1bf985e1e4d390d96dbab19e1a

The main changes in this version include fixing the glitches with dragging the selection in the color ranges list view, making the window resizable again (this time the contents adjust to its size), and a few minor revisions here and there.

Compiling the sources

Since I’ve got no packagers to help at the moment, the only way to install for now is from source. Since I’ve been working only with Qt Creator so far, there’s no specific build recipe other than the project file (morningstar.pro), which you are expected to use to generate a Makefile using QMake.

To do this, just make sure you have Qt4’s development files and QMake installed (package qt4-qmake on Debian and Ubuntu), and type the command as follows:

$ qmake morningstar.pro

Note: If you have Qt3’s version of QMake installed, you may have to explicitly use qmake-qt4 instead to avoid confusing the generator and messing up the sources.

Once QMake generates the Makefile, just issue make and wait for compilation to finish. The binary morningstar will appear in the source dir, and you can now run it from there — no installation is required.

Git repository

There’s also a Git repository hosted at Gitorious.org, from which you can download the latest source code, follow the history, and switch releases according to tags.

• Morningstar in Wesnoth-TC
• Git clone (git):
  

  git clone git://gitorious.org/wesnoth-tc/morningstar.git

• Git clone (HTTP):
  

  git clone http://git.gitorious.org/wesnoth-tc/morningstar.git

Feedback

Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!

UPDATE: the bugs in 0.1.0 were so annoying I uploaded a fixed version 0.1.0.1 shortly afterwards. Enjoy!

At last, the first working version of codename “Morning Star” is available — this is the new Qt4 GUI for team-colorization and palette switching for Wesnoth sprites.

After a day or so of working on it, distributed amongst 4 days, version 0.1.0 is now ready for downloading from this very site for testing purposes, although it should be usable for production from now on as well. Just don’t blame me if it eats your precious input.

• Version 0.1.0.1 (Gzip tarball, 24 KiB)
  SHA1 checksum: 132d326d265b61ae7441a599f7dc10537c13bc8e

In all seriousness though, I want this application to become usable by the general audience after reaching version 1.0. Artists are naturally the intended target audience, although users who just want to recolor Wesnoth sprites to use as their forum avatar may also find a use in this tool. However, to achieve this, I need your feedback. Please try Morning Star out, report bugs, suggest features (within the scope of the project’s goal), and if you think you can help with anything else, tell me!

Don’t forget that Morning Star is also in need of a definitive name!

Compiling the sources

Since I’ve got no packagers to help at the moment, the only way to install for now is from source. Since I’ve been working only with Qt Creator so far, there’s no specific build recipe other than the project file (morningstar.pro), which you are expected to use to generate a Makefile using QMake.

To do this, just make sure you have Qt4’s development files and QMake installed (package qt4-qmake on Debian and Ubuntu), and type the command as follows:

$ qmake morningstar.pro

Note: If you have Qt3’s version of QMake installed, you may have to explicitly use qmake-qt4 instead to avoid confusing the generator and messing up the sources.

Once QMake generates the Makefile, just issue make and wait for compilation to finish. The binary morningstar will appear in the source dir, and you can now run it from there — no installation is required.

Git repository

There’s also a Git repository hosted at Gitorious.org, from which you can download the latest source code, follow the history, and switch releases according to tags.

• Morningstar in Wesnoth-TC
• Git clone (git):
  

  git clone git://gitorious.org/wesnoth-tc/morningstar.git

• Git clone (HTTP):
  

  git clone http://git.gitorious.org/wesnoth-tc/morningstar.git

Known issues at the time of release

Note: most of these issues have been fixed in version 0.1.0.1, uploaded around an hour after 0.1.0 for your convenience.

• Closing the Open dialog without selecting anything once an image is already loaded produces a bogus error message.
• The Open dialog doesn’t track the last visited directory path as it should, so it’ll always revert to the My Pictures location.
• Dragging the selection in the color ranges listbox doesn’t update the preview as it should.
• Image previews are not centered, and are not scrollable either.
• The main window may be resized but the contents won’t adapt to the new size.

After a burst of inspiration, I managed to finish implementing Morning Star’s most basic functionality: recoloring images!

Thanks to Qt4’s awesome high-level interface to images (using QImage objects), the recoloring logic turned out to be much shorter and easier to understand than Wesnoth-TC’s, which had to deal with libpng and all the storage format details with PNG files. Instead, Morning Star just needs to care about reading, comparing and writing 32-bit ARGB values.

The interface design is pretty much set in stone now for version 1.0, but there’s still a lot of functionality missing. Nonetheless, this is starting to look good and I should have a working version for releasing to the public very soon. Hopefully this time artists will like this tool.

Thanks to the power of Love Qt4, my long-delayed sister project to Wesnoth-TC, codenamed “Morning Star”, is finally commencing to materialize.

While I’m progressing slowly on this as always, partly due to my parallel work on Rei 2 IRC bot, this project is very likely to get completed soon thanks to Qt Creator, an awesome IDE designed for the development of Qt4-based software applications — with a familiar feel akin to Microsoft Visual Studio, which was incidentally involved in my early learning process with C#.

Morning Star is not a front-end to Wesnoth-TC as I initially planned. Instead, it is a whole new application built upon the same logic which will be oriented to the general audience so that artists can take advantage of its preview features, and even export recolored images, all without the need to use a command prompt, which is the main limitation of Wesnoth-TC right now.

I have not decided upon a name for Morning Star, so if anyone can propose an adequate formal name for this project, I’d appreciate suggestions.