A few days ago I got bored and decided to give the Wesnoth GUI2 transition, as described in this post a bit of help. In consequence, all of the following dialogs in Wesnoth trunk, after the release of version 1.9.2, have been converted to GUI2 and should be able to display languages such as English (Shavian alphabet) correctly.
Every confirmation dialog in the game with exception of the add-ons dependencies resolution window (revisions 47443, 47445, 47446, 47447, 47448, 47450, 47451, 47509.)
The gamemap labels editor dialog (revision 47482.)
Four list-type dialogs:
Selection of the next scenario with the :cl debug command (r47463)
Display resolution list in Preferences (r47469)
Theme selection in Preferences (r47472)
List of installed add-ons for removal (r47467)
This should be considered yet another step forward for GUI2 and the Pango-based text rendering in trunk, bringing us a tad closer to the much awaited… Wesnoth 1.10 release. 😉
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. 😉
Some may recall that during my review of Wesnoth 0.1 I found a mysterious package inside the 0.1 distribution named strategy-source.tar. On closer inspection, the contents turned out to predate the sources of the first version of Wesnoth released to the general public by at least four days. However, I didn’t try to compile or run the mysterious application in that opportunity.
We are now going to take a route back in time to codename “Strategy”, which is a prototype version of the same engine powering Wesnoth 0.1. For readability purposes, we’re going to dub it Wesnoth-00 and proceed with the review.
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!
UPDATE (2010-10-27): added direct link for the Mac OS X bundle download provided by Alarantalara.
UPDATE (2010-12-06): migrated files to SourceForge.net
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!
UPDATE (2010-12-06): migrated files to SourceForge.net
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.
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.
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 (2010-12-06): migrated files to SourceForge.net
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:
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.
