User:Grzywacz

Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.

Translation & internationalisation

I was maintaining the Polish translation of "Battle for Wesnoth" for more than 1.5 year, starting spring 2005. In that time, with enormous help of a few people (mentioned in credits), we managed to complete the translation of all the mainline strings for 1.0.2 and 1.2 releases. We've started with basically nothing (barely ~5% completed at the beginning makes me wonder why previous translators even appear in the credits).

Developement

I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:

GP2X port

A port of BfW to Gamepark Holding's GP2X handheld console. The project is currently stalled due to lack of interest on my part and broken hardware... The game basically runs, but there still a few problems to solve.

What's been accomplished involves:

* fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; 
* one-time caching without revalidation to greatly improve startup times
* sound-cache limiting to save on memory
* joystick mouse support, to move mouse cursor using GP2X's stick
* fixed image resize script, used to downscale BfW graphics on install (saves memory and cpu cycles)

What's left:

* memory usage problems which make the game unplayable; 
  GP2X has only 32 megs of OS-available RAM, about 24MB can be accessed with paeryn's hardware SDL lib
* drawing speed - using doublebuffering and hardware blitter don't go well with Wesnoth's display model; 
  maybe the OpenGL branch is a better base for this port?!
* second CPU core usage - GP2X is based on MMSP2 SoC, which has two ARM cores available; 
  possibly off-load music decoding or some AI routines to the 940 core?

Sound sources support

My pet-project waiting for some free time. 8)

"Sound sources" is a general name for a mechanism, which makes it possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain patches. One has complete control over them with the WML.

Tags implemented in trunk (for testing purposes only):

[sound_source]

Available parameters:

sounds=list,of,comma,seperated,sounds - list of sounds associated with this source, played randomly

id=numerical value - internal id used to manipulate this source

delay=numerical value - mininal delay (in ms) between two playbacks of source's sound

chance=numerical value - a number from [0, 100] range, describing what's the chance of source being acticvated every second (note that it cannot play more than once at the same time anyway)

check_fogged=boolean value = true or false; if true the source won't play if its location is fogged/shrouded

x=list,of,numerical,values a list of x coordinates associated with this sound source (must match y list)

y=list,of,numerical,values a list of y coordinates associated with this sound source (must match x list)

As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.