User:Grzywacz - Revision history

Grzywacz at 00:23, 21 March 2009

2009-03-21T00:23:43Z

2009-03-21T00:19:34Z

‎Tags implemented in trunk (for testing purposes only):

2007-03-20T16:31:43Z

‎Tags implemented in trunk (for testing purposes only):

2007-03-20T16:31:14Z

‎Tags implemented in trunk (for testing purposes only):

2007-03-20T16:29:18Z

‎Tags implemented in trunk (for testing purposes only):

2007-02-16T21:35:00Z

‎GP2X port

2007-02-16T21:32:27Z

‎GP2X port

2007-02-16T21:26:14Z

‎Tags implemented in trunk (for testing purposes only):

2007-02-16T21:23:40Z

‎GP2X port

2007-02-02T21:21:46Z

‎Developement

@@ Line 30: / Line 30: @@
 === 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.
@@ Line 60: / Line 58: @@
 <tt>id=string</tt> - id of the sound source to be removed

← Older revision		Revision as of 00:19, 21 March 2009
Line 34:		Line 34:

	"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.
−
−	~~===== Tags implemented in trunk (for testing purposes only): =====~~

	<tt>[sound_source]</tt> - creates a sound source		<tt>[sound_source]</tt> - creates a sound source

@@ Line 57: / Line 57: @@
-<tt>[sound_source]</tt> - removes a sound source
+<tt>[remove_sound_source]</tt> - removes a sound source
 ''Available parameters:''
 <tt>id=string</tt> - id of the sound source to be removed

@@ Line 43: / Line 43: @@
 <tt>sounds=list,of,comma,seperated,sounds</tt> - list of sounds associated with this source, played randomly
-<tt>id=numerical value</tt> - internal id used to manipulate this source
+<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 if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play
@@ Line 61: / Line 61: @@
 ''Available parameters:''
-<tt>id=numerical value</tt> - id of the sound source to be removed
+<tt>id=string</tt> - id of the sound source to be removed

@@ Line 37: / Line 37: @@
 ===== Tags implemented in trunk (for testing purposes only): =====
-<tt>[sound_source]</tt>
+<tt>[sound_source]</tt> - creates a sound source
 ''Available parameters:''
@@ Line 57: / Line 57: @@
-As for now, these are usable only for testing purposes. A richer implementation as discussed with zookeper is on the way.
+<tt>[sound_source]</tt> - removes a sound source

@@ Line 15: / Line 15: @@
 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
   * sound-cache limiting to save on memory
@@ Line 23: / Line 23: @@
 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
+    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?!

@@ Line 26: / Line 26: @@
   * 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;
+  * 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?

@@ Line 45: / Line 45: @@
 <tt>id=numerical value</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
-acticvated every second (note that it cannot play more than once at the same time anyway)
+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

@@ Line 12: / Line 12: @@
 === 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:

@@ Line 8: / Line 8: @@
 == Developement ==
-I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects began to evolve:
+I've started my developement with a few patches, mainly bugfixes. Later on, 2 medium-size projects have begun to evolve:
 === GP2X port ===