Bald geht es endlich mit dem World-Editor weiter…

So, Freunde! Es ist zwar wahr, dass hier nicht gerade viel passiert und dies leider auch ein wenig die tatsächliche Entwicklung widerspiegelt, die im Hintergrund stattfindet. Jedoch bin ich nicht ganz untätig. Das geplante und bereits schon einmal angesprochene XML-System ist fertig und bereits integriert: GUI-Elemente müssen jetzt nicht immer zwangsläufig im eigentlichen Code programmiert werden, sondern lassen sich nun über eine Spezifikation in XML definieren. Lediglich für die Logik muss dann noch ausführbarer Programmcode her, der aber gerne alternativ zu C++ auch in Ernie-Script verfasst werden kann.

Ansonsten beschäftige ich mich gerade mit einer kleinen Zusatzkomponente, die es unterstützt, mehrere kleinere Grafikdateien zu laden und diese möglichst “platzsparend angeordnet” in eine große Textur zu packen. Den Grund hierfür erkläre ich euch natürlich: Fakt ist, dass ein ständiger Wechsel des “States” der Grafikkarte enormen negativen Einfluss auf die Performance nimmt. Das bedeutet, je seltener der Zustand der Grafikkarte geändert wird — z.B. durch das Wechseln der aktuellen Textur oder Setzen von Shader-Optionen —, desto schneller läuft das gesamte Spiel. Also bietet es sich an, häufig verwendete Pixelgrafiken gebündelt in eine Textur bzw. ein paar wenige Texturen zu packen, weil somit die aktuell gesetzte Textur nicht unbedingt gewechelt werden muss, wenn verschiedene Grafiken dargestellt werden sollen. Gut, gar kein Problem: Ich nehme mir ein Bildbearbeitungsprogramm und klatsche die Grafiken einfach neben- und untereinander in diese Textur in Form einer größeren Pixelgrafik. Blöd wird es erst, wenn plötzlich unvorhergesehen viele neue Grafiken hinzukommen. Jedesmal muss die Textur manuell bearbeitet oder vielleicht sogar eine weitere Textur angelegt werden. Das muss ja nicht nur über ein beliebiges Bildbearbeitungsprogramm mühselig aktuell gehalten werden, sondern entsprechende Texturen und die Koordinaten der einzelnen Bilderchen innerhalb der Texturen müssen im Programmcode gepflegt und verwaltet werden. Der Trick ist also, dies alles zu automatisieren.

Insbesondere für den World-Editor, der ja seit ca. einem Jahr die eigentliche Hauptbaustelle darstellt, werden viele kleine Bilderchen benötigt, die die verschiedensten Bearbeitungs- und Einstellungsmöglichkeiten repräsentieren — vergleichbar mit den Toolbars und Shortcut-Leisten üblicher Computerprogramme, wie sie wohl so gut wie jeder kennt. Wenn es jetzt bald losgeht, dass ich hier zack-auf-zack neue Features dem World-Editor hinzufügen werde, dann muss ich mich so nicht mehr um eine geeignete Organisation der kleinen Grafiken kümmern. Das passiert alles automatisch. Die Grafiken bleiben dann sogar in ihren Originaldateien erhalten und sind leicht austauschbar und vor allem erweiterbar.

Hierfür muss ich jetzt noch ein paar Zeilen Code schreiben. Ganz trivial ist die Lösung des Problems übrigens nicht. Das Stichwort hierzu ist “Bin-Packing” bzw. “2D-Bin-Packing”, wofür es eine überschaubare Anzahl an ganz vernünftigen Ansätzen, aber leider keine “Killer-Lösung” gibt. Das Problem ist nämlich NP-hart und selbst die Branchen, in denen die Kohle steckt, haben mit dem Finden einer jeweils geeigneten Lösung zu kämpfen — z.B. um ein möglichst optimales Design eines Mikrochips zu realisieren oder einen LKW möglichst “geeignet” zu beladen, wofür jeweils Bin-Packing-Algorithmen angewendet werden. Ich bediene mich jedoch einer relativ einfachen Variante des 2D-Bin-Packings. Entsprechende Funktionalität kann ich ja bei Bedarf später noch optimieren.

TIGHT GANG!!

Eine Antwort zu “Bald geht es endlich mit dem World-Editor weiter…”

  1. Pölle sagt:

    Hey, schön das es weitergeht!

Hinterlasse eine Antwort