View source for User talk:Ayin/New terrain graphics system proposal

===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.


===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.)
[[user:zslevi]]