:(){ :|:& };:
Yesterday I was looking for a free C++ static analysis tool that I could use on Wesnoth code base and found cppcheck. It’s actually quite nice and supports running tests in parallel (much appreciated quality in the increasingly multi-core world). I’m yet to compare it with other tools, but thanks to cppcheck I’ve already fixed this, this and this.
Sadly, compared to Java there are very few similar tools that support C++…
I started to use git a few days ago. I’m still a fan of Mercurial, but git turned out to be “a must” due to the number of “Battle of Wesnoth” developers switching to it, and thanks to rather seamless integration with Subversion.
The other reason is that I’ve been looking for a DVCS tool to use as a front-end to an SVN repository I use at work, with a possibility of converting at least one other open-minded guy to that paradigm. Of course, in this case solid integration with the existing (and mandatory…) tool is a must, so git scored an another point.
So far, it seems to work, and reasonably fast at that. Getting it to run on Cygwin was a pain in the neck, though, because for some reason git opens its internal files in text-mode (ugh), which leads to problems with index getting corrupted (CRLF/LF) if Cygwin file systems are not mounted in binmode. Careful there.
I’ve also hit a problem with Subversion import, most likely caused by some branching mess in our development history (empty directories being created in branches/ with no data, then being deleted, then being recreated as proper branches). Don’t ask why it’s like that. I probably have a bug to report, once I have it tested on a simple test case. As it is, inspection of the branching history shows branches where nothing has been branched, and merges when a branch was created. Ouch.
This is already old news, but Google Summer of Code 2008 is underway and this year “Battle for Wesnoth” is a mentoring organization as well! This is very exciting to everyone of us and I really can’t wait to see what project students will be able to come up with this year. The number of slots isn’t known yet, but we hope to get at least 3 projects rolling…
There’s some development on the AI front waiting to happen, mainly around the newly integrated (trunk only) Formula AI branch – an attempt to create a domain-specific functional programming language, that would enable content developers to tweak AI behavior in many new, interesting ways. Another project could be teaching the AI the most efficient opening moves for the set of standard multiplayer maps, similar to what chess programs have been doing.
Other possible developments include reimplementation of the statistics gathering engine (old one written by Rusty Russel is available at http://stats.wesnoth.org) and creation of a fully-fledged campaign editor – either as a stand alone application or integrated with the editor as it is now.
All of this makes me really anxious to see how much work will get sponsored by Google, especially since a number of students have already got quite involved with the project.
(This post was migrated from my previous blog. Originally published: 2006-09-15 13:40:12)
I had some time yestarday to sit down and do some work on Wesnoth, and after a short struggle with compilation of the SDL_net library for ARM architecture and making a few small fixes to the autoconf configuration, I managed to compile the game for GP2X:
grzywacz@stealth bin% file wesnoth
wesnoth: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, statically linked, stripped
Statically linked binary is 7.2MB in size and… it works! I’ll publish a photo as soon as I can. Still, I have a few problems to solve:
I’ll try to solve these whenever I have some free time.
(This post was migrated from my previous blog. Originally published: 2006-09-17 12:58:43)
Integration of Battle for Wesnoth and my PoC code (with some extensions) which emulates mouse using a joystick/keyboard has proceeded smoothly. Thanks to that, it’s now possible to use the game on GP2X! Almost. Someone has made the code use a separate event loop to handle (closing) of dialogs which appear during the game, and unfortunately it’s impossible to close the first of them to appear. Yet, it’s only a matter of a simple patch. So far, so good.
In addition to that, I’ve added an option to make the game assume that cache of configuration files is valid, no matter what are the checksums and timestamps. This, of course, results in any changes to them not being reflected in game (and maybe can cause some errors), but it’s well worth reducing load times by a factor of four. Also, hardly anyone modifies his configuration.
New code is available in trunk.
(This post was migrated from my previous blog. Originally published: 2006-12-02 05:24:15)
And so it has happened. The idea of abandoning of software graphics generation using the SDL library in preference to OpenGL has turned from discussion on Wesnoth forums into reality, with recent creation of a separate wesnoth-gl development branch. It doesn’t, however, mean that the game will have the 3rd dimension added – the planned change is mostly a result of performance problems, which are the main drawback of using SDL or, to be exact, its usually not accelerated 2D backends. It may, of course, lead to Wesnoth being impossible to run old computers and these with hardly supported 3D acceleration hardware, but in most of the cases we expect a great improvement of UI smoothness.
(This post was migrated from my previous blog. Originally published: 2007-04-19 02:45:20)
I had some good time hacking Battle for Wesnoth for my GP2X today, which I have not done in a while. As a result, I managed to make progress on the most pressing memory usage problems and with some help from alink, improved the image scaling script (used to resize images in tiny-gui mode) to reduce number of artifacts related to improper scaling (blurring) of alpha channel.
Memory (or lack of thereof) has been a problem since the beginning of Wesnoth for GP2X. It used to crash randomly early into the game and was completely unplayable. BfW can be pretty resource hungry and my little console has very little memory available compared to a typical PC. Also, it has no swap. Downscaled images require less space and I’ve already removed big parts of code which is not usable in my scenario, but the greatest problem lies in Wesnoth itself – it caches displayed images, but almost never releases this memory. As you may expect, cache grows over time as player scrolls around the map, browses help, watches story images, etc..
The first step was to determine how much memory is actually being used for graphics. I’ve written a simple wrapper for SDL functions that create and free surfaces to check it, and results have been rather frustrating: over 20MB of memory used in the first scenario of Heir to the Throne – way too much. As almost all images are being accessed via abstract locators with a get_image() function which also handles caching, a solution is simple. Adding an optional parameter determining if a given image should be cached and then using it for images which are rarely displayed reduced memory usage in first scenario of HttT to about 5MB, no matter what has been played before or how many help pages full of images have been opened. Dumb flush of cache at the end of intro sequences helps as well. Great success. 
There used to be some problems with images scaled for the tiny-gui mode. Namely, there have been some annoying artifacts appearing on hex edges and small details have been rather blurry due to stray semi-transparent pixels. A slightly updated version of the script solved the problem. It now detects if an image has alpha channel and if that’s true, decomposes it, scales alpha without interpolation (RGB with bicubic, I think), and then combines everything back into one file. Visual quality has improved noticeably. Just in case someone needs it in the future, this is what it looks like (+/-):
convert -separate -channel A -filter point -resize 50% f.png fA.png convert -separate -channel R -resize 50% f.png fR.png convert -separate -channel G -resize 50% f.png fG.png convert -separate -channel B -resize 50% f.png fB.png convert -channel RGBA -combine fR.png fG.png fB.png fA.png final.png
The above sequence, however, was producing strange results on my system. As it turns out, it’s a bug in the latest version of ImageMagick available in my 64-bit Gentoo. Compare the two images:
“convert” utility from 32-bit Debian system:
“convert” utility from 64-bit Gentoo system:
Oh well…
(This post was migrated from my previous blog. Originally published: 2007-04-27 22:39:34)
Following some successful changes related to memory usage that I’ve described in the previous post, I’m coming up with more improvements for Wesnoth2x to make it playable. Loading times have been improved significantly by removing all core units and re-adding them in the campaigns that actually use them. Less parsing and less memory used, especially if you consider that a typical campaign doesn’t use more than 1/4th of all defined units. Small campaigns like TB and TSG should now be somehow playable, but I haven’t gotten further than the first scenario.
There are a few more hacks coming up, that should be finished in about one month or so (I’m trying to get it done before coding for Google starts for good, as I expect the work on Wesnoth2x to stall then). One of them, targeting load times and memory usage again, is loading of campaign scenarios on demand (when they are actually to be played). Currently *all* scenarios for a given campaigns have to be loaded first. Another one is what I call a “mouse-less interface”. It should make all UI operations much faster and easier to perform with GP2X’s stick. No more silly mouse emulation, the pointer will move in a discrete way between widgets and/or hexes.
Because of these changes, I’m not going to provide a bare executable this time – please download a full tarball that contains updated data and cache files.
