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

Zslevi at 12:46, 5 July 2009

2009-07-05T12:46:31Z

Zslevi: macro

2009-07-05T12:40:04Z

macro

Eleazar: Eleazar: Some other ideas for terrain modules

2005-11-16T14:16:30Z

Eleazar: Some other ideas for terrain modules

New page

===Eleazar: Some other ideas for terrain modules.===

* A "flat" version of whatever replaces "terrain-adjacent-corner" This would be useful in the new canyon and in transitions such as water-water where a long transition is desired. (Normal transitions can't overlap the tile that spawns them.

* A 90 degree wall module. For use with interiors. Apparently it's nearly possible to make 90 degree walls with "terrain-adjacent-corner" but it's extremely awkward, and produces glitches if not aligned correctly.

===Also===
as we develop more terrains it's extremely likely that most new terrains will simply be graphic revisions of the same old terrain. A new Fall forest may need to transition and layer in exacly the same way as the default forest. A way to make it even more strongly aliased to the original terrain, so that little would have to be added to terrain graphics.cfg would be helpful and also prevent graphic desigers from introducing errors, which will become more likely as the terrains multiply.

← Older revision		Revision as of 12:46, 5 July 2009
Line 17:		Line 17:

	I don't see how it's bad. E.g. the Prolog programming language is based on that concept, and it works fine. (But I could mention lisp macros as well.)		I don't see how it's bad. E.g. the Prolog programming language is based on that concept, and it works fine. (But I could mention lisp macros as well.)
		+	[[user:zslevi]]

← Older revision		Revision as of 12:40, 5 July 2009
Line 8:		Line 8:
	===Also===		===Also===
	as we develop more terrains it's extremely likely that most new terrains will simply be graphic revisions of the same old terrain. A new Fall forest may need to transition and layer in exacly the same way as the default forest. A way to make it even more strongly aliased to the original terrain, so that little would have to be added to terrain graphics.cfg would be helpful and also prevent graphic desigers from introducing errors, which will become more likely as the terrains multiply.		as we develop more terrains it's extremely likely that most new terrains will simply be graphic revisions of the same old terrain. A new Fall forest may need to transition and layer in exacly the same way as the default forest. A way to make it even more strongly aliased to the original terrain, so that little would have to be added to terrain graphics.cfg would be helpful and also prevent graphic desigers from introducing errors, which will become more likely as the terrains multiply.
		+
		+
		+	===Macro===
		+
		+	"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. "
		+
		+	I don't see how it's bad. E.g. the Prolog programming language is based on that concept, and it works fine. (But I could mention lisp macros as well.)