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

From The Battle for Wesnoth Wiki
m
m
Line 51: Line 51:
 
===Hard to understand===
 
===Hard to understand===
  
Overall, the system has many possibilities, which have successfully been used to expand the graphics possiblities on Wesnoth. However, it looks like that few (no) people understand it enough to use it effectively, and that the only solution, for graphics designers, to implement new ideas or to fix glitches is to ask me, on IRC, how to do it. As said above, the system is split in two parts:
+
Overall, the system has many possibilities, which have successfully been used to expand the graphics possiblities on Wesnoth. However, it looks like that few (no?) people understand it enough to use it effectively, and that the only solution, for graphics designers, to implement new ideas or to fix glitches is to ask me, on IRC, how to do it. As said above, the system is split in two parts:
  
 
* A WML part which can be considered program logic, which is quite complex. I ([[User:Ayin|Ayin]] <sup>[[User_talk:Ayin|(talk)]]</sup>) was the only one to actually commit changes in this part.
 
* A WML part which can be considered program logic, which is quite complex. I ([[User:Ayin|Ayin]] <sup>[[User_talk:Ayin|(talk)]]</sup>) was the only one to actually commit changes in this part.
 
* A WML-macro parts which is more-or-less accessible to artists, but which still retains a large part of black magic. (For example: "<tt>{TERRAIN_ADJACENT_CORNER_PROB  K      q      !NQqCK    56,76 sunken-ruinkeep3-wall-1 25}</tt>": who know what those "56,76" numbers mean? And what would happen if those were changed?)
 
* A WML-macro parts which is more-or-less accessible to artists, but which still retains a large part of black magic. (For example: "<tt>{TERRAIN_ADJACENT_CORNER_PROB  K      q      !NQqCK    56,76 sunken-ruinkeep3-wall-1 25}</tt>": who know what those "56,76" numbers mean? And what would happen if those were changed?)

Revision as of 11:13, 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.

This is a bad thing.

Relatively slow

Although there have been many optimizations in this way, rebuilding the list of terrain graphics (when, for example, a terrain has changed) still is pretty slow on older computers.

Quite a complex system

The pattern => images system is something very simple, conceptually. However, to be able to properly generate terrain graphics, the following subtelties must be taken into account:

Rule overlapping
The main problem with this approach is to specify precedence, and mutual-exclusiveness, of rules. For example, rules can be mutually-exclusive:
  • on an hex (only one rule of this "kind" can apply on a given hex)
  • on a hex border (only one rule of this "kind" can apply on a given hex border)
  • or on a hex corner (only one rule of this "kind" can apply on a given hex corner)
Furthermore, some rules have to be independant one from the other (for example, rules defining the base terrains and transitions, and rules defining the overlay graphics, are totally independant), and some rules are mutually exclusive (for example, all rules defining base terrain transitions are mutually exclusives on hex borders, all rules defining base terrains are mutually exclusive on hexes, all rules defining some kind of castle-like fence are mutually exclusive on hex corners).
To solve this problem, a rule may apply "flags" on some hexes, and check for the presence, or absence, of flags before being applyied.
Image ordering and adjustment
Images will necessarily have to overlap. The overlapping order of images is the source of many potential graphical glitches. A simple, layer-based mode to specify the overlapping order of images is not enough, nor is the "drawing in the order the rules are defined" solution.
The current system uses an ordering model based on 2 different shapes for images:
  • Images representing terrains layered over the floor. Those use a simple layer-based model
  • Images representing terrains standing vertically on the floor. Those have x,y coordinates, and are layered in the logical order. Specifying those coordinates seems quite hard to many terrain developers.
Using symetry properties
Most rules (hopefully) have 6-way rotational symetry properties. If they had not, the already huge amount of WML used would actually have to be multiplicated by 6. However, defining template-like rules which spawn 6 actual, rotated rules is not trivial:
  • The rule itself can be rotated, but not the images themselves. Said images must have different filenames. The rule rotation must then have a way to specify the name of those files.
  • Same for flags and rule overlapping
  • Same (worse?) for layering of "vertical" images.

Hard to understand

Overall, the system has many possibilities, which have successfully been used to expand the graphics possiblities on Wesnoth. However, it looks like that few (no?) people understand it enough to use it effectively, and that the only solution, for graphics designers, to implement new ideas or to fix glitches is to ask me, on IRC, how to do it. As said above, the system is split in two parts:

  • A WML part which can be considered program logic, which is quite complex. I (Ayin (talk)) was the only one to actually commit changes in this part.
  • A WML-macro parts which is more-or-less accessible to artists, but which still retains a large part of black magic. (For example: "{TERRAIN_ADJACENT_CORNER_PROB K q  !NQqCK 56,76 sunken-ruinkeep3-wall-1 25}": who know what those "56,76" numbers mean? And what would happen if those were changed?)