Difference between revisions of "User:Ayin/New terrain graphics system proposal"
m (→Motivations for the proposal: - very WML-intensive) |
m (→Motivations for the proposal: - Complex system) |
||
Line 19: | Line 19: | ||
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. | 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. | ||
− | + | This is a bad thing. | |
− | === | + | === 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. |
Revision as of 10:59, 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.
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.