Google Highly Open Participation Contest

Today, Google announced its Highly Open Participation Contest, a follow-up to the greatly successful Summer of Code program aimed at pre-university students! This is a pilot edition of a program, which requires students to complete tasks prepared by various open source organizations. In contrary to SoC, however, not all tasks are coding-oriented, so that they can provide a good introduction to the open source world for students, who are not (yet!) programming gurus. You can find more detailed information on the project’s FAQ page.

There are prizes for successful students, with a small monetary award for completing at least 3 tasks, and a Grand Prize for the best ones. GHOPC starts today, so don’t miss it!

P.S. spread the word.

Migration completed

Migration of my blog from the dying jabba.pl site is now finished. I decided to keep the most important posts written in English on this blog for future reference. From now on, expect fresh content only.

As a side note, I used Python to make the migration process a little bit more enjoyable – with a short program capable of parsing XML dumps of my posts and sending them to WordPress via MetaWeblog XMLRPC API. It was also a good opportunity to refresh my Python skills, as I spent the last 3 months doing mostly simple C++, shell scripting and makefiles… Blah.

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-gl

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

Getting ready

(This post was migrated from my previous blog. Originally published: 2007-04-17 15:54:17)

Since the real coding is supposed to start on May 28th, I still have some time to read the code, get better understanding of it and prepare necessary tools. Turns out I’m going to use Eclipse along with PyDev extension to write my project, but I may have to buy additional 512 megs of ram to feed this beast. Also, I’ve recently discovered that using two monitors instead of one makes Eclipse much more usable. Finally, all the handynavigators, outliners and consoles don’t take all the space needed for code display:

Another cool tool I’m going to be using a lot is Mercurial distributed SCM. Too bad it doesn’t integrate all that well with Eclipse.

As I’m about to write a XMPP bot, I have to find the best pythonic XMPP library out there. So far, there has been three interesting candidates: Twisted Words, pyxmpp and a new event-driven library SleekXMPP, recommended by Kevin Smith himself. All of these have very sparse docs, though, which is not good news…

On the Moin front, I have to figure out how to glue the code responsible for sending notifications with the current system of actions. The most elegant solution requires implementation of a notification framework, as suggested by Thomas Waldmann, but I’m tempted to leave this for future refactoring, when the bot part is ready.

Just FYI, a step-by-step progress report and feature list is maintained at the project’s page.

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.

Planet SoC

(This post was migrated from my previous blog. Originally published: 2007-05-09 18:30:36)

I’ve just registered my blog with Planet SoC, a site which aggregates feeds from blogs of various people related to Summer of Code. Let’s see this post gets picked up.

In the mean time, it’s been decided that xmlrpc will be used for communication between the notification bot and wiki, mainly because MoinMoin already has a working xmlrpc interface, and it’s a well-known protocol, with good support from Python’s standard library.

I’ve also started to work on the jabber bot itself, so expect an update on this subject Soon™. Once it has the basic XMPP-related functionality (messaging, roster, presence) working well, I’ll try to connect it with Wiki, which is the very core of my task.

1st notification

(This post was migrated from my previous blog. Originally published: 2007-06-01 21:39:44)

It’s time for a quick update on my Summer of Code project progress. Four days have passed since the official start of coding, on May 28th, and yesterday the simplest usage scenario actually worked. Notification, that is:

On the screenshot above you can see a message from my notification bot, sent when a page I’m subscribed to was changed. The message is exactly the same for both email and Jabber notification, so i18n Just Worked™ without any additional changes. The code to make it happen was (and still is!) crude, with some hardcoded values here and there, but I feel it’s a good base for further development.

MoinMoin (note the new, funny domain) used to have no event system. Notifications of page changes used to be sent via email from within the PageEditor class itself, on page save. I’ve created a simple, plugin-based eventing “framework”, using the Observer pattern, and moved the notification code there. Then, using standard Python’s xmlrpclib module, added a tiny bit of code, that communicates with the notification (Jabber) bot.

The bot itself consists of three components, running in separate threads, which communicate through shared Queue objects. One of them is responsible for receiving and handling XML RPC requests, second one does all the work related to Jabber/XMPP communication, and third one will, in the near future, perform editing actions on wiki.

Back to coding…