I know people in the northern hemisphere are going to freeze very soon as winter approaches, but I know I’ll still envy them in a few weeks when local temperatures start going over 32°C.

In retrospect, that was probably the dumbest comment I’ve ever made about weather. Right now I’m freezing at home with temperatures below 10°C at night, when it’s supposed to be hot and sunny since it’s summer spring...

Oh, and I’ve apparently caught a cold again. This is like the tenth time this year or something.

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!

Random netizens may have stumbled upon my blog and read what I have had to say about the free Radeon KMS drivers on Linux at different points of their development, or about Linux support for the HP Pavilion dv5-1132la. I’ve got to admit, ashamed, that I’ve failed to do the research (or RT*M) multiple times, resulting in misinformation (or misleading theories) being posted and spread from there.

Here I clarify a couple of things based on what I have learned with time and experience.

Espreon’s laptop may have been damaged by other unexpected conditions.

Talking with the people at the #radeon IRC channel on freenode, I have learned that it’s possible for bad userland drivers to lockup the GPU by sending bad commands, and cause it to overheat to death. In this case, Espreon was trying out the Mesa/Gallium3D ATI R300 drivers, which were clearly labeled as experimental at that time. A simple bug in such work-in-progress may have caused a lock condition as mentioned, damaging the circuitry since Espreon didn’t shut down the laptop like I did. In my case, I may have saved my laptop because I allowed the GPU to cool down before continuing.

Still, in both cases we were using work-in-progress drivers. Right now KMS is very stable and I have been using KMS-enabled kernels since around the time Linux 2.6.35 was released. Performance is not comparable to UMS for various reasons — as a result, where UMS was slow, KMS is fast; where UMS was fast, KMS is slow or faster, etc. Things may change once the Mesa/Gallium3D ATI R600 driver becomes usable for production. Until then, I’m sticking to Mesa DRI/DRI2 ATI R600 with KMS-enabled kernels.

The HP Pavilion dv5-1132la no longer requires a patched ACPI DSDT blob for getting thermal zone readings on Linux.

Since around Linux 2.6.28, I had kept a patched DSDT blob compiled into the kernel to override the system’s table at boot, tainting the kernel each time. This was a bad idea for various reasons, including limiting my ability to extend the system specs without repatching and recompiling a new blob. Unbeknownst to me, a workaround for broken ACPI configurations of this kind was already merged into the mainline kernel. I only figured this out after accidentally making a 2.6.35 build without the DSDT.

It’s time to continue with our journey into the past to unveil the mysteries of the Battle for Wesnoth Project and its history. This time, we’ll take a look at the third major version of Wesnoth ever released, which succeeds versions 0.1, 0.2 and 0.2.1.

I have not been able to find a package for Wesnoth 0.2.1, but it also happens to be the first version to have changelog entries which can be found even nowadays in SVN trunk:

Version 0.2.1:
 * many redraw bugs fixed
 * new scenarios added
 * many new graphics added that were contributed by Paco
 * infinite recall bug fixed
 * recalling now costs 20 gold pieces. Gold from previous scenarios carries over,
   and there is a bonus for finishing a scenario early
 * better transitions between tiles added (graphics for this not complete though)

Nonetheless, Wesnoth 0.3 — packaged on July 29th 2003 and including a lot of hidden files created by vi/vim and other applications — includes more changes than the changelog entries in SVN would lead us to believe.

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!

With the intention of documenting the oldest Battle for Wesnoth development releases from the 0.x line, I started the Wesnoth Evolution series, which so far comprises the following articles, in chronological order:

1. Wesnoth Evolution: 0.1
2. An interview with Dave, where I ask David White a.k.a. Sirp about Wesnoth 0.1 and the mysterious project codenamed “strategy”.

It’s been a long time, but I have decided to stop procrastinating and fire the time machine again to take a look at Wesnoth 0.1’s immediate successor, version 0.2. This is just the beginning of an amazing journey which, with luck, time and patience, will lead us back to Wesnoth 1.8 from the perspective of a long-time player, UMC author and mainline developer.

As in the last installment, I’ll use a cross-compiled (Mingw32) version of Wesnoth 0.2 for Windows on Linux/Wine. The distribution's contents timestamp is 2003-07-13 09:31 UTC. Both this distribution and 0.1's include many hidden .swp files (vi/vim temporary working files) so it’d seem Dave packaged 0.2 in middle of coding work.

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.

My collaborators know well that I often refer to Mozilla’s current flagship browser as “Failfox”. Many have read what I’ve got to say about several versions of Mozilla Firefox before. A few also know my stance on the foundation’s trademark policies and their sole existence.

Yet I can’t bring myself to hate this awesome browser that’s still superior to Google Chrome in user interface design as far as I am concerned.

After switching to Iceweasel/Firefox 3.6 from Debian experimental a couple of months ago — after learning of its status at the website of one of the maintainers’ — I have had a pleasing and stable experience with Firefox that I’d not had since 3.0 was released. Now I’m also beta-testing Firefox 4 for Windows on my XP SP3 virtual machine, and awaiting the future stable release.

I thought I’d clarify this for those who might have thought I was yet another Firefox-hater, based on my previous rants. Of course, it’s a bit jarring that it took Mozilla and/or Debian so long to stabilize Firefox on amd64 systems, but I guess you can’t ask for more — it mostly is, after all, a volunteer-driven effort, and amd64 builds had not appeared before in the official FTP server until the Firefox 4 betas, for some reason.

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.