Difference between revisions of "User:Grzywacz"
(→Developement) |
|||
(8 intermediate revisions by the same user not shown) | |||
Line 12: | Line 12: | ||
=== GP2X port === | === 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... The game basically runs, but there still a few problems to solve. | + | 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: | What's been accomplished involves: | ||
− | * fixes to unmaintained tinygui interface, to make the game playable in 320x240 resolution; | + | * fixes to the unmaintained tinygui interface, to make the game playable in 320x240 resolution; |
* one-time caching without revalidation to greatly improve startup times | * one-time caching without revalidation to greatly improve startup times | ||
* sound-cache limiting to save on memory | * sound-cache limiting to save on memory | ||
Line 23: | Line 23: | ||
What's left: | What's left: | ||
* memory usage problems which make the game unplayable; | * 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 | + | GP2X has only 32 megs of OS-available RAM, about 24MB more 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; | * 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?! | 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; | + | * second CPU core usage - GP2X is based on a MMSP2 SoC, which has two ARM cores available; |
possibly off-load music decoding or some AI routines to the 940 core? | possibly off-load music decoding or some AI routines to the 940 core? | ||
=== Sound sources support === | === Sound sources support === | ||
− | |||
− | |||
"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. | "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. | ||
− | + | <tt>[sound_source]</tt> - creates a sound source | |
− | |||
− | <tt>[sound_source]</tt> | ||
''Available parameters:'' | ''Available parameters:'' | ||
Line 43: | Line 39: | ||
<tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly | <tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly | ||
− | <tt>id= | + | <tt>id=string</tt> - internal id used to manipulate this source |
− | <tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound | + | <tt>delay=numerical value</tt> - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play |
<tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being | <tt>chance=numerical value</tt> - a number from [0, 100] range, describing what's the chance of source being | ||
− | + | activated every second after the ''delay'' has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time anyway) | |
<tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded | <tt>check_fogged=boolean value</tt> = true or false; if true the source won't play if its location is fogged/shrouded | ||
Line 57: | Line 53: | ||
− | + | <tt>[remove_sound_source]</tt> - removes a sound source | |
+ | |||
+ | ''Available parameters:'' | ||
+ | |||
+ | <tt>id=string</tt> - id of the sound source to be removed | ||
+ | |||
+ | |||
+ | The current state of the volume calculation algorithm looks like: | ||
+ | |||
+ | :http://kolos.math.uni.lodz.pl/~grzywacz/current.png |
Latest revision as of 00:23, 21 March 2009
Why hello there! This site describes my involvement in the "Battle for Wesnoth" developement so far.
Contents
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 the 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 more 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 a MMSP2 SoC, which has two ARM cores available; possibly off-load music decoding or some AI routines to the 940 core?
Sound sources support
"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.
[sound_source] - creates a sound source
Available parameters:
sounds=list,of,comma,seperated,sounds - list of sounds associated with this source, played randomly
id=string - internal id used to manipulate this source
delay=numerical value - mininal delay (in ms) between two playbacks of source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play
chance=numerical value - a number from [0, 100] range, describing what's the chance of source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file 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)
[remove_sound_source] - removes a sound source
Available parameters:
id=string - id of the sound source to be removed
The current state of the volume calculation algorithm looks like: