Difference between revisions of "User:Ayin/New terrain graphics system proposal"

Revision as of 10:34, 15 October 2005

This page is a working document for a proposal for a complete rewrite of the terrain graphics system. It may be considered as a counter-proposal to the extended terrains proposal.

Motivations for the proposal

The current terrain-graphics system is a powerful, albeit complex, system whose purpose is to transform maps (which are, basically, 2-dimensional arrays containing 1-character terrains) into a list of graphics for each location in the map.

The base for the system, and the root of a terrain_graphics rule, is: "pattern of terrains => associated images". In my (Ayin ^(talk)) opinion, pattern-based rules are the way to go: those are simple to understand, and allow nearly anything.

However, the current system (see documentation here TerrainGraphicsWML, or, better, here) has several drawbacks, which I will try to detail below:

Very WML-intensive

The basic, pattern => images system, is quite hard to type effectively in WML.

One simple, standard rule takes about 20 to 50 lines of WML. Considering that completely defining a "castle" with a keep takes about 7 rules (using rotation symetries), and a basic transition takes 4 rules (again, using rotation symetries), this means about 200 lines of WML to completely define a transition.

To solve this problem, the WML macro system is used quite intensively. Considering that the terrain-graphics.cfg file only contains macros and comments, and is about 800 lines long, and considering each macro rule generates, more or less, 40 lines of WML, this amounts to many lines of WML for the engine. Some testing shown this amounts to about 13000 lines in Wesnoth 1.1-svn. This is about 1/4 of the WML cache.

The problem with this use of macros is that directly coding terrain_graphics rules is pretty much deprecated: it is recommended to use macros which re-use already-created rulesets instead of directly using new ones. We are more or less falling in the situation of Sendmail, where what was originally a "config file" became "program logic", and where the "config file" uses some macro system to transform higher-level macros into the actual low-level file which is then parsed by the compiled program.

Which leads to the following point:

@@ Line 8: / Line 8: @@
 However, the current system (see documentation here [[TerrainGraphicsWML]], or, better, [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml here]) has several drawbacks, which I will try to detail below:
+=== Very WML-intensive ===
+The basic, pattern => images system, is quite hard to type effectively in WML.
+One simple, standard rule takes about 20 to 50 lines of WML. Considering that completely defining a "castle" with a keep takes about 7 rules (using rotation symetries), and a basic transition takes 4 rules (again, using rotation symetries), this means about 200 lines of WML to completely define a transition.
+To solve this problem, the WML macro system is used quite intensively. Considering that the <tt>terrain-graphics.cfg</tt> file only contains macros and comments, and is about 800 lines long, and considering each macro rule generates, more or less, 40 lines of WML, this amounts to many lines of WML for the engine. Some testing shown this amounts to about 13000 lines in Wesnoth 1.1-svn. This is about 1/4 of the WML cache.
+The problem with this use of macros is that directly coding <tt>terrain_graphics</tt> rules is pretty much deprecated: it is recommended to use macros which re-use already-created rulesets instead of directly using new ones. We are more or less falling in the situation of Sendmail, where what was originally a "config file" became "program logic", and where the "config file" uses some macro system to transform higher-level macros into the actual low-level file which is then parsed by the compiled program.
+Which leads to the following point:
+=== Hard to understand ===