Mac OS X:wesnoth-rcx-0.2.1.dmg (Application image, 16.7 MiB)
SHA1 checksum: 221c0006ce8beed5d81f4a9637629a12d4fe0730
Contributed by Alarantalara.
New in this version
Shortly after 0.2.0 was released, it was brought to my attention that it wouldn’t compile against Qt versions older than 4.8.0, even though the documentation says it should work with version 4.6.0 and later. I quickly amended that and published a patch (found amongst the 0.2.0 downloads in the previous announcement) addressing those issues. That patch is obviously no longer necessary, since the compatibility changes are integrated in 0.2.1 and later. Furthermore, I now have easy access to a build environment using 4.6 to ensure such a situation does not occur again.
A well known issue at the time 0.2.0 was released was some rather excessive memory usage when zooming in, especially for large pictures. 0.2.1 solves this by using a more conservative approach for zooming; in a particular case this decreases memory usage from around 1.1 GiB to just around 50 MiB.
Wesnoth RCX now remembers the main window size and the preview background color each time. Additionally, it’s now possible to apply TC to a whole color palette in the Palette Editor dialog, using the new Recolor option.
Finally, a few minor interaction issues were fixed in this release, including the Add from List option (Palette Editor) being available and non-functional when no palettes are selected.
Feedback
Bugs and feature requests should preferably be posted to the issue tracker at Github so I don’t have a chance to forget about them.
Of course, as usual you can provide other kinds of feedback through the Wesnoth.org forum topic and this announcement post. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.
Mac OS X:wesnoth-rcx-0.2.0.dmg (Application disk image, 17.4 MiB)
SHA1 checksum: 2d8221a6002d37cc352cfa2a67938afd7b9596e3
Provided by Alarantalara.
Patch:qt-4.6-4.7-compatibility.patch (Source code patch, 6.5 KiB)
SHA1 checksum: e9e800c98bdb79c234d536277bfb5d3ea9014a89
You only need to apply this patch if you are building version 0.2.0 from source using Qt 4.6.x or 4.7.x. Run qmake -v in the console to see the Qt version in use.
The project page on this very site has been updated accordingly, and split from the main Wesnoth-TC page.
New in this version
One year and nearly eight months have passed since the last release, version 0.1.4. There was very little activity for most of the time until July this very year, although the primary release goals had already been long established.
The new built-in palette and color range editors allow creating and modifying these items for the game’s recoloring engine with ease, as well as generating WML definitions for your use in add-on production and testing. Various user interface improvements and additions, such as a Recent Files section and a Reload action, allow for a smoother workflow. The redesigned main window now supports scrolling large and zoomed-in images, as well as dragging any of the previews to other applications accepting graphic drops, such as the GIMP.
This version also sees the addition of menu options to change the preview background color, cleaner file output notifications, an enhanced Windows build process with embedded version and icon attributes, and a simple make install target for Linux/X11 users building from source. The included documentation has been improved in this release as well.
Known issues
Some of the known issues with this release are mentioned in the BUGS file included in the source code tarball; other issues have been fixed after the release, in the master branch in the public Git repository.
The unmodified 0.2.0 source code distribution will not build using Qt 4.6 or 4.7 without the patch provided in the Downloads section above. This issue was—rather unfortunately—discovered after the release was tagged. The fix has been committed to Git already.
Zooming in requires extremely large amounts of CPU time and memory, especially for images larger than 72x72 pixels at zoom levels greater than 200%. It’s advised that you avoid zooming in unless you have at least 2 GiB of RAM available.
Zooming does not preserve the current viewport, indiscriminately recentering it instead.
The preview background color choice is not persistent across re-runs. This has been solved in Git already.
The dialog shown by the Add from List option in the Palette Editor may have the help text cut off depending on your display and font configuration
Dragging previews is not always possible on Linux/X11, depending on the Qt 4 style engine in use. A workaround has been implemented for the Oxygen style (KDE workspace default), but other styles that allow dragging windows from empty areas may ‘steal’ Wesnoth RCX’s events.
Dragging previews to Windows Paint does not currently work, presumably because the application expects to get access to a file on disk. Since Wesnoth RCX does not store the recolored image on disk until the user requests it, this problem might be impossible to fix.
The Windows build might occasionally crash during the initial file open dialog, apparently whenever a directory takes too long to display. This does not seem to happen later during execution.
The Windows build might display occasional minor glitches with mouse-over decorations on buttons and radio/checkboxes when running on Windows XP with styles supporting them (e.g the default Luna style).
The Add from List button in the Palette Editor remains enabled at times when it cannot do anything useful (e.g. when there are no palettes to select and edit). This has been solved in Git already.
As usual, you can also provide other kinds of feedback through those two aforementioned channels. It would be nice to hear from you if you use this software, regardless of whether you liked it or not — any feedback is appreciated here.
Finally
One problem in terms of development and testing is that I do not currently own a Mac machine, nor do I really intend to. This means I have to rely on certain assumptions and avoid doing anything too crazy that is not guaranteed to work on all platforms or—in particular—widget style engines. So far this appears to have worked fine, thanks to Qt’s cross-platform design.
The Windows (Win32) build has been tested much better in that regard, since my current development machine also functions as a decent VirtualBox VM host. I have gone to rather great lengths this time to improve the build by adding some embedded information to blend better with the environment, and including the Qt library in the wesnoth-rcx.exe executable itself, thus removing the need for two DLLs in the distribution.
Testing on Windows and Mac OS X feels really important to me, given my target audience; most artists seem to prefer these mostly hassle-free operating systems, and I fully respect that choice. My goal is to reach as many artists as possible with a useful and powerful tool that does not get in the way of the creative process, unlike the Wesnoth game proper, so it’s important to ensure a minimum quality level for each release that is consistent across the three main supported platforms.
I have done a lot of work coding and testing this release on Linux (Debian wheezy), Windows XP, and Windows 7, and I hope there aren’t any showstoppers left in this version. However, as you can see above, there is still quite a lot left to do in terms of polishing. Depending on feedback, a new 0.2.1 release might be published in the upcoming weeks. However, many of the remaining bugs require more meticulous inspection and extensive design changes; those will not happen until 0.3.0.
In the meantime, go test and create, and have lots of fun!
Wesnoth-TC 1.5.1 has just been released... or maybe not. It has actually been tagged for more than 24 hours already.
This version is really just a bug-fix release, which is why it’s not 1.6.0. In fact, it only really addresses some build-time issues that have cropped up over the last couple of years.
Windows (Win32) binary:wesnoth-tc-1.5.1-win32.zip (383.6 KiB)
SHA1 checksum: b74f26ea3743917433be4f3ca0c0be1a5647b40b
Instructions
Both distributions come with a README file, and the source code distribution also includes an INSTALL file with detailed instructions for configuring, compiling and installing Wesnoth-TC. The Windows binary distribution doesn't require any installation besides unpacking it into an appropriate directory — which you may optionally add to PATH.
The past, and the future
Long ago, this came into existence. At the time, I needed a quick way to preview my own team-colored unit sprites without going through the hassle of starting/restarting Wesnoth (or its internal cache), loading a saved game, and creating units in debug-mode. That was my initial motivation for writing Wesnoth-TC, and since it was tailored to my specific needs, it was born as a console application. I later decided to publish and extend it, hoping that someone else would provide a good full-featured user interface for it.
Actual artists prefer using graphical user interface applications on Windows and Mac OS X, and with good reason. That’s the software interaction paradigm that suits visual types better for obvious reasons, and that’s why I took it upon myself to write a larger GUI front-end for Wesnoth-TC that could be built and run on the three major platforms from a single code-base.
That front-end quickly became an adaptation of the original back-end code. And thus Wesnoth RCX became an entirely separate project sharing little more than a bit of history with Wesnoth-TC. And most importantly, Wesnoth RCX became the first GUI (Qt 4) application I have ever written.
Over time, my needs and personal preferences have changed. Wesnoth-TC now feels largely inferior to RCX merely because of the lack of a native front-end for it. RCX has also recently gained visual palette and color range editing capabilities, which renders Wesnoth-TC’s definition file system somewhat obsolete. Furthermore, RCX has continued to compile and run correctly over time regardless of the Qt 4 version currently installed, whereas Wesnoth-TC has broken in a few occasions with newer development environments.
Wesnoth-TC truly feels like a relic now, one I don’t really want to continue developing at this time when I feel RCX is more fun to improve and work with. I had plans to eventually integrate a full-fledged implementation of the Wesnoth Image Path Functions mechanism, but that seems over-ambitious right now.
So, yeah, Wesnoth RCX is the future. Stay tuned for version 0.2.0, coming soon with more features and improvements.
I have just finished moving Wesnoth-TC and Wesnoth RCX to Github — in my humble uneducated non-expert opinion, a much nicer place to be than Gitorious, which still lacks native CIA.vc support after all these years. Instead, Github supports CIA.vc and a large amount of alternatives which I’ll probably never use.
The project page on this website has been updated accordingly. If you were tracking the repositories at Gitorious, you will not be able to get further updates unless you update your configuration to point to the new locations:
Updating client repositories is actually far easier than it sounds:
$ git remote set-url origin <new URL>
Afterwards, you should be able to fetch/pull as usual.
This switch actually began some time ago when I was considering resuming Wesnoth RCX’s development (which stagnated ‘some’ time ago too). It took a while, but I finally seem to be back on track, all thanks to my currently unannounced self-imposed campaign development break — a break that should allow me to get back to business soon enough, with the renewed energy and coder momentum I will seriously need in order to pull it off.
Wesnoth RCX 0.2.0 will probably be released before the end of this week, as soon as I make sure everything works as intended, which will be less trivial this time due to the new shiny features it packs. There’s also a couple of Windows-specific oddities that I want to tackle before releasing.
Oh, and in the meantime there will be an update regarding Wesnoth-TC’s future.
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.)
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.
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. 😉
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
