User:Ayin/New terrain graphics system proposal - Revision history

Ayin: /* Hard to understand */

2005-10-16T12:17:50Z

‎Hard to understand

Ardonik: /* Quite a complex system */ multiplicated -> multiplied

2005-10-15T23:57:31Z

‎Quite a complex system: multiplicated -> multiplied

Darth Fool: /* Hard to understand */

2005-10-15T19:05:19Z

‎Hard to understand

Ayin: /* Sanitize the vertical layering code */

2005-10-15T13:20:04Z

‎Sanitize the vertical layering code

Ayin: /* Module API */

2005-10-15T12:47:49Z

‎Module API

Ayin: /* Part 2: Use modular terrain graphics code */

2005-10-15T12:46:11Z

‎Part 2: Use modular terrain graphics code

Ayin: /* Module API */ - first draft

2005-10-15T12:45:37Z

‎Module API: - first draft

Ayin: /* Use modular terrain graphics code */

2005-10-15T12:20:26Z

‎Use modular terrain graphics code

Ayin: /* Make terrain_graphics WML driven by terrain WML */

2005-10-15T11:31:12Z

‎Make terrain_graphics WML driven by terrain WML

Ayin: skeleton of the proposal

2005-10-15T11:22:06Z

skeleton of the proposal

@@ Line 56: / Line 56: @@
 * 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?)
-I've been starting to thing the problem is that the system is too powerful, and that going all-WML may not necessarily be a good idea. Being generic is good, being too generic may prove harmful.
+I've been starting to think the problem is that the system is too powerful, and that going all-WML may not necessarily be a good idea. Being generic is good, being too generic may prove harmful.
 ==Proposals==

@@ Line 44: / Line 44: @@
 :*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:
+: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 multiplied 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

@@ Line 53: / Line 53: @@
 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. For a long time I ([[User:Ayin|Ayin]] <sup>[[User_talk:Ayin|(talk)]]</sup>) was the only one to actually commit changes in this part.  There has only been one other commit, made by Darth Fool for use with the ruins graphics.  He has promptly forget everything he knew about terrain WML and continues to point people at Ayin when questions are asked of him.
 * 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?)

← Older revision		Revision as of 13:20, 15 October 2005
Line 203:		Line 203:
	}		}

−	===Sanitize the vertical layering code===	+	===Part 3: Sanitize the vertical layering code===
		+
		+	The vertical layering system, using x,y coordinates for the "base point" of a vertical item, is more complicated than necessary. The following points must be taked into account:
		+
		+	* Only y-layering is important. x-layering was only used when rotating rules, which, according to part 2, will be directly managed by modules.
		+	* The "pixel size" of a tile, and x-layering of images, are totally unrelated concepts. There is no need for 72 layers per hexes. 3, 5, or 7 layers should be enough.
		+	* Calculating the rectangular coordinates of a point in a hex-system is a pain. Coordinates should be expressed relatively to hexes, not in cartesian coordinates.
		+	* The "backside" layer of an hex should '''always''' be '''in front''' of the "frontside" layer of hexes behind it. This rule should save us many headaches about graphic glitches.

@@ Line 157: / Line 157: @@
 ====Module API====
-This is a proposal for a terrain_graphics module API.
+This is a proposal for a terrain_graphics module API. Modules should, ideally, be very short, independant fragments of C++ code.
    ''// Represents an image set as defined in the [terrain_graphics] WML, and handling probs''

← Older revision		Revision as of 12:46, 15 October 2005
Line 92:		Line 92:

	===Part 2: Use modular terrain graphics code===		===Part 2: Use modular terrain graphics code===
		+	====Basics====

	If only coders can modify the rulesets which build terrains, that's OK, but then, there's no point anymore to define rulesets using WML then.		If only coders can modify the rulesets which build terrains, that's OK, but then, there's no point anymore to define rulesets using WML then.

← Older revision		Revision as of 12:45, 15 October 2005
Line 155:		Line 155:

	====Module API====		====Module API====
		+
		+	This is a proposal for a terrain_graphics module API.
		+
		+	''// Represents an image set as defined in the [terrain_graphics] WML, and handling probs''
		+	''// and animations transparently''.
		+	''// operator+(const std::string&) is defined, to add a suffix to animated or probabilized images.''
		+	class imageset;
		+
		+	class terrain_pattern;
		+
		+	class module
		+	{
		+	public:
		+	module(gamemap& map, imageset& set);
		+
		+	virtual void fill_terrains_for(const gamemap::location&)
		+	protected:
		+	const gamemap& map() const;
		+	void insert_image_flat(int layer, imageset&) const;
		+	void insert_image_vertical(pos, imageset&) const;
		+
		+	bool tile_matches(const gamemap::location& loc, const terrain_pattern& pattern);
		+	const gamemap::location adjacent_tile(const gamemap::location& loc, int position);
		+
		+	imageset& image_basename() const; ''// Corresponds to image_basename in the WML''
		+	std::vector<terrain_pattern> terrain_types; ''// Corresponds to terrain_types in the WML''
		+
		+	std::string corner_name(int corner);
		+	std::string edge_name(int edge);
		+	}
		+
		+	''// Sample code for the "wall" module''
		+	module_wall : public module
		+	{
		+	public:
		+	virtual void fill_terrains_for(const gamemap::location& loc)
		+	{
		+	for (int i = 0; i < 6; ++i) {
		+	if (tile_matches(loc, tile_terrain_types[0]) &&
		+	tile_matches(ajacent_tile(loc, i), terrain_types[1]) &&
		+	tile_matches(adjacent_tile(loc, i+1), terrain_types[2])) {
		+
		+	insert_image_vertical(i, image_basename() + corner_name(i));
		+	}
		+	}
		+	}

	===Sanitize the vertical layering code===		===Sanitize the vertical layering code===

@@ Line 91: / Line 91: @@
 The <tt>terrain_graphics</tt> rules would not apply on terrain characters anymore, but would, instead, apply on symbols like "grassland", "forest", "village", etc.
-===Use modular terrain graphics code===
+===Part 2: Use modular terrain graphics code===
 ===Sanitize the vertical layering code===

← Older revision		Revision as of 11:22, 15 October 2005
Line 55:		Line 55:
	* 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?)
		+
		+	I've been starting to thing the problem is that the system is too powerful, and that going all-WML may not necessarily be a good idea. Being generic is good, being too generic may prove harmful.
		+
		+	==Proposals==
		+
		+	===Make terrain_graphics WML driven by terrain WML===
		+
		+	===Use modular terrain graphics code===
		+
		+	===Sanitize the vertical layering code===