First success

(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:

• Mouse emulation with a joystick (I’ve already written a proof-of-concept code for that, and all is left is integration with the game)
• Correctly compiled SDL_mixer library, so that it doesn’t segfault in Mix_OpenAudio() function
• An option to turn automatical verification and generation of game configuration files cache off

I’ll try to solve these whenever I have some free time.

Joymouse

(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.

Wesnoth @ gp2x (again)

(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 usage

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.

Scaling bugs

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…

Progress report on Wesnoth for GP2X

(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.