planetmaker schrieb:Weil es sachlich falsch ist - und wir wollen den Leuten doch keinen Unfug beibringen?

Natürlich nicht, daher werde ich für´s Publikum etwas weiter ausholen.

planetmaker schrieb:* Es gibt die grf-specs die beschreiben wie eine grf-Datei beschaffen zu sein hat.
* Es gibt die Sprache nfo (die sich sehr nahe an den grf-specs in ihrer hexadezimalen Herangehensweise orientiert). Ihr Compiler ist grfcodec

Da bringst du etwas durcheinander.

Zunächst ist richtig dass die "grf-specs" das Format einer grf-Datei beschreiben. Diese ist (in "Format 1") einfach eine lineare Anordnung sogenannter "sprites" (im neueren "Format 2" sind die im folgenden erwähnten zwei Arten von "sprites" voneinander getrennt).

Heute unterscheiden wir "real sprites", das sind in bestimmter Weise kodierte bzw komprimierte Spielgrafiken (wie in TTD), und - neu seit TTDPatch - "pseudo sprites". Diese kodieren keine Grafiken sondern sind Anweisungen und Daten die von TTDPatch und OTTD interpretiert und/oder an die jeweiligen internen Datenstrukturen zugewiesen werden, bzw mit ihnen verknüpft werden.

Diese Anweisungen und Daten stellen einen byte code dar, der durch die "Sprache" nfo beschrieben wird. Diese hat aber erst einmal gar nichts mit den "grf-specs" zu tun, die ja lediglich den Aufbau einer grf-Datei beschreiben. In der Tat gab es das grf-Format bereits vor der Entwicklung von nfo. Man konnte schon damals mit grfcodec die originalen TTD grf-Dateien dekodieren, die lediglich die Spielgrafiken (sowie einige Farbtabellen und Reliefs) enthielten. Und man konnte (geänderte) Grafiken wieder in eine grf-Datei kodieren.

Der später von TTDPatch eingeführte nfo code ("pseudo sprites") wird von grfcodec einfach in die grf-Datei eingefügt, dazu braucht es überhaupt keine "compiler"-Funktionalität.

planetmaker schrieb:* Es gibt die Sprache nml mit dem Compiler nmlc. Die Gemeinsamkeiten mit nfo beschränken sich auf die *gemeinsame* Grundlage beider Sprachen: die grf-specs.

Eben nicht, denn die grf-specs spezifizieren lediglich das Format einer grf-Datei, der "compiler" hingegen, was o.e. "pseudo-sprites" betrifft, übersetzt ganz einfach nml-Syntax in nfo. Ausserdem erledigt er (in nmlc) noch die Kodierung der Grafiken und schreibt beides zusammmen direkt in die zu erstellende grf-Datei, unter Beachtung des grf-Formats.

Weder die eine noch die andere der beiden zuletzt erwähnten Teilaufgaben rechtfertigen allerdings mMn die Bezeichnung "compiler" für das ausführende Programm. Und in Bezug auf die Umsetzung von "Hochsprache" zu nfo tun der nmlc "compiler" und m4nfo exakt dasselbe. Wie gesagt, in m4nfo ist lediglich die Grafik-Kodierung sowie die anschliessende Speicherung von nfo und kodierter Grafik in grfcodec ausgelagert. Wie gesagt, aus guten Effizienzgründen.

planetmaker schrieb:* Für jede Sprache (nfo, nml, ...) kann man sich immer einen beliebigen Macro-Prozessor nehmen und dann lustig dazu passend Macro-Sammlungen programmieren, die das Schreiben des Codes in der jeweiligen Sprache hoffentlich vereinfachen.

Ich weiss nicht worauf du hinauswillst, es gibt ja verschiedene Interpretationen des Begriffs "Makro", zB als feste (oder parametrisierte) Befehlsfolge in der SW-Entwicklung, oder als Zusammenfassung fester Benutzereingaben in Anwendungsprogrammen. m4nfo ist allerdings in M4 geschrieben, was eine Turing-vollständige Programmiersprache darstellt, nicht zu vergleichen mit "beliebigen Macro-Prozessoren" (wie zB CPP), deren Funktionsumfang nicht über reinen Textersatz hinausgeht (was dir möglicherweise nicht bekannt ist). Das bedeutet nun nicht, dass m4nfo M4 nicht für reinen Textersatz benutzt, das tut es sehr wohl, zB für "templating".

planetmaker schrieb:Den Output des entsprechenden Präprozessors füttert man dann den eigentlichen Compiler.

In der Tat, das ist allgemein bekannt und muss nicht extra erwähnt werden.

planetmaker schrieb:Eine Art von Macro-Sammlung oder gar Code-Generator nutzt fast jeder, der ein NewGRF-Projekt gewisser Größe betreut.

Mag sein. Aber auch hier will mir die Relevanz dieser Aussage im gegebenen Kontext nicht recht einleuchten.

Gruß
Michael