Grafikaddressierung

[BeRsErKeR]

Hallo,

in meinem Rollenspielprojekt denke ich gerade über mein System zur Grafikaddressierung bzw. -identifizierung nach.

Grundsätzlich sehe ich zwei Möglichen Grafiken zu identifizieren:

1. Über den Dateinamen
2. Über einen Index-Wert

Beides hat seine Vor- und Nachteile. Dateinamen sind (in meinem Projekt) eindeutig und sagen in der Regel auch etwas über die Grafik aus (z.B. Cursor.gfx). Allerdings sind Grafik-Dateinamen in Bezug auf Maps ziemlich ungeeignet, wenn man für jedes Tile eine zugehörig Grafik addressieren möchte. Dafür finde ich Indizes besser geeignet. Mit Dateinamen müsste man hier auf eine Art Mapping zurückgreifen.

Für die Addressierung über Indizes muss man allerdings auch eine Art Mapping erzeugen. Dabei sehe ich drei Varianten:

1. Man speichert den Index in der Grafikdatei
2. Man nutzt eine externe (Mapping-)Datenbank
3. Man generiert Indizes aus dem Dateinamen und/oder anderen Dateieigenschaften

Variante 3 ist mir ehrlich gesagt zu kompliziert (gerade in Hinblick auf Eindeutigkeit).

Momentan nutze ich Variante 1 und sie funktioniert ganz gut. Mich stört nur die Unflexibilität. Denn wenn ich 10 Grafiken für Schwerter habe (Index 1-10) und 10 Grafiken für Heiltränke (11-20) und füge dann ein weiteres Schwert ein, dann muss ich dafür einen freien Grafikindex (z.B. 21) wählen. Bei vielen Grafiken wird das schnell unübersichtlich und lässt sich nur begrenzt gut dokumentieren. Außerdem erfordert es händische Arbeit und ich mag Automatismen.


Die Frage ist nun welcher Weg eine gute Flexibilität bietet und sich gut automatisieren lässt. Wie Addressiert ihr Grafiken und vorallem wie verknüpft ihr diese mit Items, Gegnern, GUI-Elementen usw? Klar habe ich Datenbanken in denen ich Items und Monstern einen Grafikindex zuweise, aber wie gesagt, eine Zahl besitzt sehr geringe Aussagekraft. Möglicherweise doch Grafiknamen/Dateinamen nutzen? Oder textuelle Identifier?

Habt ihr Ideen oder Ratschläge in diese Richtung?


Ein Problem was ich z.B. auch habe: Viele Tilegrafiken für Maps werden automatisch generiert (und das sind hunderte). Es ist wirklich mühsam die alle händisch mit Indizes zu versehen, damit ich sie im Map-Editor zuordnen kann. Und werden es mal mehr Tiles oder kommen manuell erstellte Tiles dazu, so ist es unschön, wenn dort Index-Lücken durch andere Grafiken entstehen oder sich Zuordnungen ändern.

Bislang umgehe ich die meisten Index-Zuordnungsprobleme, indem ich für bestimmte Grafikarten festgelegte Index-Bereiche vorgebe (z.B. 1-100 = GUI-Grafiken, 101-200 = Item-Icons, usw). Das ganze ist aber auch sehr statisch und wenn ich Pech habe brauche ich irgendwann mehr Grafiken eines Bereiches als ich Indizes zur Verfügung habe. Und dann kann ich die ganzen Automatismen eh knicken.


Für Hinweise wäre ich sehr dankbar.

[Krishty]

Über was für Indizes sprechen wir hier? Brauchst du was, was die Engine intern zur Laufzeit verwendet (da würde ich beim Laden einfach nur ein int hochzählen und hätte einen tollen Index), oder etwas, was über die Laufzeit der Engine hinaus konsistent bleibt (GUID)?

Wie Addressiert ihr Grafiken und vorallem wie verknüpft ihr diese mit Items, Gegnern, GUI-Elementen usw?

• Per Zeiger und
• per Zeiger, der als Handle verkauft wird.
Ein per new allokierter Zeiger ist eine perfekte Hash-Funktion mit einem theoretischen Overhead von null und schlägt in der Praxis jede andere assoziative Datenstruktur um Größenordnungen, von der Implementierungszeit ganz ab.

Edit: Langsam dämmert es mir: Wenn du ein Tile lädst, möchtest du herausfinden, ob die Textur, die da in der Datei gefordert wird, schon geladen ist oder nicht – oder? Für den Fall: So lange das nicht öfter als zehntausendmal pro Sekunde vorkommt, set<string>.
Falls das zu langsam werden sollte (und bei logarithmischer Laufzeit bezweifle ich das), schreib einen Container, der die Strings nach Länge vergleicht und dann erst nach Inhalt, das erhöht am Anfang der Suche drastisch die Lokalität.

Gruß, Ky

[Jonsc1]

Ich weiss nicht ob das sonderlich effizient ist, aber ich hatte ein ähnliches Problem mit Meshes die ich lade. Wenn ich verschiedene Objekte in meiner "Welt" habe, die alle die gleiche grafische Representation benutzen (z.B. einen Stuhl), will ich natürlich nicht alles mehrfach laden, sondern all diese Objekte sollen die selben Vertex / Indexdaten nutzen.
Ich hab es so gemacht wie von dir beschrieben, nämlich eine std::map benutzt, als Schlüsselwert den absoluten Pfad zur Modelldatei, und als Eintrag einen Pointer auf eine mit new erzeugte Instanz einer Klasse CMesh, die die Geometriedaten repräsentiert. Die Klasse die das ganze handled hab ich CResourceManager genannt und ihr eine Funktion CMesh* CResourceManager::getMesh(std::string filepath) verpasst, die überprüft ob ein entsprechender Eintrag in der map existiert (-> das Mesh wurde bereits geladen) und dann den Pointer zurückliefert, oder das Mesh läd, in der Map den Pointer speichert und dann ebenfalls zurückliefert.

Wie gesagt, keine Ahnung ob das so effizient ist, das mögen die Profis hier beantworten, funktionieren tut es mit > 100.000 Objekten immernoch gut und schnell.

Edit:
Das setzt natürlich vorraus das die eigentlichen Geometriedaten nicht von der Objektklasse (die Objekte in der Welt repräsentiert) verändert wird, aber gerade bei "statischen" Texturdaten dürfte das ja nicht erforderlich sein.

[BeRsErKeR]

Über was für Indizes sprechen wir hier? Brauchst du was, was die Engine intern zur Laufzeit verwendet (da würde ich beim Laden einfach nur ein int hochzählen und hätte einen tollen Index), oder etwas, was über die Laufzeit der Engine hinaus konsistent bleibt (GUID)?

Ja es geht mir um eine Art GUID, die global konsistent ist. Im Map-Editor will ich also eine Grafik genauso addressieren können wie im Spiel selbst.

Wie Addressiert ihr Grafiken und vorallem wie verknüpft ihr diese mit Items, Gegnern, GUI-Elementen usw?

• Per Zeiger und
• per Zeiger, der als Handle verkauft wird.
Ein per new allokierter Zeiger ist eine perfekte Hash-Funktion mit einem theoretischen Overhead von null und schlägt in der Praxis jede andere assoziative Datenstruktur um Größenordnungen, von der Implementierungszeit ganz ab.

Mit addressieren meine ich "in einem Pool aus Grafiken finden". Mich interessiert dabei nicht unbedingt der Code, sondern die logische Herangehensweise. Ich rede also nicht davon, dass ich eine Grafik als Pointer in einer Item-Instanz ablege, sondern woher das Item weiß, welche Grafik mit ihm assoziiert ist. Items, Monster usw werden in Datenbanken angelegt. Bislang gibt es dort einfach eine Spalte "GrafikID" mit einer Ganzzahl, die die Grafik identifiziert. Es sind alles in allem aber nun schon an die 20 Datenbanken mit teilweise bis zu 60 Einträgen und da noch einen Überblick über benutzte und freie Grafikindizes zu haben ist echt schwer und irgendwie keine tolle Lösung.

Edit: Langsam dämmert es mir: Wenn du ein Tile lädst, möchtest du herausfinden, ob die Textur, die da in der Datei gefordert wird, schon geladen ist oder nicht – oder? Für den Fall: So lange das nicht öfter als zehntausendmal pro Sekunde vorkommt, set<string>.
Falls das zu langsam werden sollte (und bei logarithmischer Laufzeit bezweifle ich das), schreib einen Container, der die Strings nach Länge vergleicht und dann erst nach Inhalt, das erhöht am Anfang der Suche drastisch die Lokalität.

Naja zunächst einmal ist entscheidend dem Spiel oder MapEditor zu verklickern, _WELCHE_ Grafiken er laden muss und wie sie addressiert werden (Dateiname oder Index, und falls Index, wie wird er generiert/ermittelt). Wenn ich neue Grafiken hinzufüge möchte ich nicht händisch die Grafik in eine Liste eintragen müssen oder händisch einen freien Index raussuchen und zuweisen.



Mal ein Beispiel wie es momentan bei mir ist:

Ich habe z.B. die Grafik "GUIBackground.gfx" und "Schwert.gfx". Erstere wird als Hintergrund für alle GUI-Elemente benutzt. Letztere ist das Bild eines Items.

Die Grafiken müssen nun manuell im Code durch

Code: Alles auswählen

GraphicManager->AddGraphic("GUIBackground.gfx");
GraphicManager->AddGraphic("Schwert.gfx");

geladen werden. Bislang besitzen Grafiken einen internen Index. "Schwert.gfx" könnte z.B. den Index 202 haben und "GUIBackground.gfx" den Index 1 (diese Werte sind in der gfx-Datei gespeichert und ich gebe sie händisch beim Konvertieren/Erstellen der Grafik an).

Ich kann nun mit GraphicManager->GetGraphic(202) an das Bild für das Schwert gelangen. Soweit so gut.

Problematisch finde ich eher, dass es kein Mapping gibt. Sagen wir mal ich brauche die Grafik für einen Dolch. Woher kenne ich den Index? Ich muss jedesmal in die Item-Datenbank gucken und den Grafikindex raussuchen. Ein Identifier wie "DaggerGfx" oder ähnliches wären hier eindeutiger.

Und auch das Wissen, welche Grafiken geladen werden müssen fehlt. Bislang lege ich Listen für z.B. alle TileGrafiken oder alle GUIGrafiken an und lasse dann alle Dateien dieser Listen laden.


Ich suche nun einfach eine schöne Lösung, bei der ich so wenig manuellen Aufwand wie möglich habe, mit applikationglobal konsistenten Grafik-GUIDs und einer möglichst trivalen und platzsparenden Speicherung (der Identifier) für das Mapformat.

Und das ganze System sollte halt so funktionieren, dass ich beliebige IDs nutzen kann und es keine ID-Überschneidungen geben kann.

Ich weiss nicht ob das sonderlich effizient ist, aber ich hatte ein ähnliches Problem mit Meshes die ich lade. Wenn ich verschiedene Objekte in meiner "Welt" habe, die alle die gleiche grafische Representation benutzen (z.B. einen Stuhl), will ich natürlich nicht alles mehrfach laden, sondern all diese Objekte sollen die selben Vertex / Indexdaten nutzen.
Ich hab es so gemacht wie von dir beschrieben, nämlich eine std::map benutzt, als Schlüsselwert den absoluten Pfad zur Modelldatei, und als Eintrag einen Pointer auf eine mit new erzeugte Instanz einer Klasse CMesh, die die Geometriedaten repräsentiert. Die Klasse die das ganze handled hab ich CResourceManager genannt und ihr eine Funktion CMesh* CResourceManager::getMesh(std::string filepath) verpasst, die überprüft ob ein entsprechender Eintrag in der map existiert (-> das Mesh wurde bereits geladen) und dann den Pointer zurückliefert, oder das Mesh läd, in der Map den Pointer speichert und dann ebenfalls zurückliefert.

Wie gesagt, keine Ahnung ob das so effizient ist, das mögen die Profis hier beantworten, funktionieren tut es mit > 100.000 Objekten immernoch gut und schnell.

Nun ja prinzipiell mache ich das so schon. Ich habe wie gesagt einen GraphicManager, der alle Grafiken lädt und verwaltet. Intern nutzt dieser auch eine std::map. Dabei ist der Key der Grafikindex und die Value ein Pointer auf das Grafik-Objekt. Die Frage ist halt, ob ich das auch mit dem Dateinamen als Key machen sollte, wobei dann wieder das Problem im MapEditor auftritt. Ich möchte nicht pro Tile einen langen Pfad speichern, sondern einen Integerwert.


Entscheidend wäre ja z.B. auch, dass der MapEditor weiß, welche Grafiken denn nun wirklich TileGrafiken sind. Der soll ja nicht die ItemGrafiken als TileGrafik anbieten. Hier könnte man z.B. auch über einen Text-Identifier wie "Map_Tile000" arbeiten, und sieht anhand des Prefixes dann, dass es sich um eine TileGrafik handelt. Bislang habe ich einen ID-Bereich für TileGrafiken von 3600-4000. Aber was ist, wenn ich mal mehr als 400 TileGrafiken hab? Sehr unflexibel.


Hoffe ihr versteht worauf ich hinaus will. Ich habe zwar ein funktionierendes System. Allerdings merke ich einfach, dass es sehr unflexibel ist und so langsam an seine Grenzen stößt. Trotzdem möchte ich auch bestimmte Vorteile, wie die platzsparende Speicherung, nicht verzichten und dennoch einen gewissen Grad an Eindeutigkeit und Zuordbarkeit erhalten.

[Krishty]

Okay, jetzt verstehe ich.

Beides hat seine Vor- und Nachteile. Dateinamen sind (in meinem Projekt) eindeutig und sagen in der Regel auch etwas über die Grafik aus (z.B. Cursor.gfx). Allerdings sind Grafik-Dateinamen in Bezug auf Maps ziemlich ungeeignet, wenn man für jedes Tile eine zugehörig Grafik addressieren möchte. Dafür finde ich Indizes besser geeignet. Mit Dateinamen müsste man hier auf eine Art Mapping zurückgreifen.

Was du mit Indizes machst bzw machen würdest (wenn du wüsstest, was du machen sollst (was du nicht tust, sonst würdest du nicht hier fragen)), ist ja auch Mapping – und was du findest, ist kein Argument. 2:-2 für Namen – eindeutig und menschenlesbar vs schwer auszutüfteln und unlesbar. Müssen ja keine Dateinamen sein; Dagger reicht ja, damit das Programm nach textures\Dagger.png sucht.

Ich kann nicht ansatzweise nachvollziehen, wie man überhaupt auf die Idee kommt, es anders zu machen … ;)

Entscheidend wäre ja z.B. auch, dass der MapEditor weiß, welche Grafiken denn nun wirklich TileGrafiken sind. Der soll ja nicht die ItemGrafiken als TileGrafik anbieten.

textures\items\Dagger.png?

[Despotist]

An deiner Stelle würde ich alle Grafiken in einer Datenbank ablegen. Wenn du derer 20 hast wird es nur unnötig kompliziert und ich sehe keinen Vorteil darin. Eher wäre es sinnvoll wenn du einen Itemtyp dazu speichern würdest also zb bei Schwert "Waffe", bei Schild "Rüstung", bei Heiltrank "Alchemie" und bei einem Waldtile "Terrain".

Zum festlegen und beschreiben der Infos könntest du dir mal XML als beschreibende Sprache anschauen. Da kannst du neben Werten wie Preis, Schaden, Dateiname usw. auch den Index fest vergeben wenn du das möchtest.

Aber du kannst auch in einem zusätzlichen Editor(fenster) zb. eine neue Grafik für Schwert hinzufügen, dann nach Typ sortieren und alle Indizes neu vergeben (einfach hochzählen). Dass damit früher gespeicherte Level/Spiele unter Umständen unbrauchbar werden sollte klar sein.

Weiterhin ist es nicht nötig dass die Indizes durchgehend sind wenn du eh eine Map benutzt (bei einem Arrayindex wäre das anders). Du könntest zb 1000-1999 für Schwerter vorsehen, 2000-2999 für Äxte usw. . Da solltest du genug Platz zum einfügen haben. Und wenn du eine Grafik einfügst gibst du nur den Typ (also zb Schwert/Waffe) an und der Editor fügt selbst den nächsten freien Index dieser Kategorie dafür ein.

Weiterhin kannst du ja die GetTexture Methode überladen so dass sie dir einmal mit dem Index die Textur zurück gibt und einmal mit dem Namen falls die wirklich eindeutig sind (Dateiendung würde ich auch weglassen).

[BeRsErKeR]

Okay, jetzt verstehe ich.

Beides hat seine Vor- und Nachteile. Dateinamen sind (in meinem Projekt) eindeutig und sagen in der Regel auch etwas über die Grafik aus (z.B. Cursor.gfx). Allerdings sind Grafik-Dateinamen in Bezug auf Maps ziemlich ungeeignet, wenn man für jedes Tile eine zugehörig Grafik addressieren möchte. Dafür finde ich Indizes besser geeignet. Mit Dateinamen müsste man hier auf eine Art Mapping zurückgreifen.

Was du mit Indizes machst bzw machen würdest (wenn du wüsstest, was du machen sollst (was du nicht tust, sonst würdest du nicht hier fragen)), ist ja auch Mapping – und was du findest, ist kein Argument. 2:-2 für Namen – eindeutig und menschenlesbar vs schwer auszutüfteln und unlesbar. Müssen ja keine Dateinamen sein; Dagger reicht ja, damit das Programm nach textures\Dagger.png sucht.

Ich kann nicht ansatzweise nachvollziehen, wie man überhaupt auf die Idee kommt, es anders zu machen … ;)

Entscheidend wäre ja z.B. auch, dass der MapEditor weiß, welche Grafiken denn nun wirklich TileGrafiken sind. Der soll ja nicht die ItemGrafiken als TileGrafik anbieten.

textures\items\Dagger.png?

Wie gesagt finde ich Identifier wie "Dagger" usw auch besser. Die Vorteile von Ganzzahl-Indizes sind aber:

1. Speichern als 16-Bit oder 32-Bit Wert
2. Man kann alle Grafiken von Index X bis Y laden

Gerade Punkt 1 ist für meinen Map-Editor recht hilfreich, da das Mapformat recht einfach bleibt. Ich könnte allerdings auch eine Art mapinternes Mapping im Header der Mapdatei speichern, wo ich lokal den globalen Text-Identifiern für Grafiken lokale Ganzzahl-Indizes zuweise, die ich dann für die Tiles nutze.

Die Abbildung von Identifier -> Dateiname finde ich eine gute Idee. Ich denke mal ich nutze eine Mischung aus Grafiktyp und Grafikname: "Item_Dagger" oder "GUI_Background", was dann zu "items/dagger.gfx" und "gui/background.gfx" wird. Dadurch kann ich die IDs direkt aus den Dateinamen erzeugen und andersrum.

An deiner Stelle würde ich alle Grafiken in einer Datenbank ablegen. Wenn du derer 20 hast wird es nur unnötig kompliziert und ich sehe keinen Vorteil darin. Eher wäre es sinnvoll wenn du einen Itemtyp dazu speichern würdest also zb bei Schwert "Waffe", bei Schild "Rüstung", bei Heiltrank "Alchemie" und bei einem Waldtile "Terrain".

Ich glaube da hast du mich falsch verstanden. Nicht die Grafiken sind in Datenbanken angelegt, sondern Items und Monster, welche GrafikIndizes referenzieren. Ein Item hat z.B. die Werte "Abwehr", "Angriff", "Gewicht", "Name" und eben auch "GrafikID".

Zum festlegen und beschreiben der Infos könntest du dir mal XML als beschreibende Sprache anschauen. Da kannst du neben Werten wie Preis, Schaden, Dateiname usw. auch den Index fest vergeben wenn du das möchtest.

Ich mag XML nicht und denke für eine normale Item-Datenbank ist eine Excel-ähnliche Datenbank ausreichend. Zumal sie sehr viel einfacher zu lesen ist.

Aber du kannst auch in einem zusätzlichen Editor(fenster) zb. eine neue Grafik für Schwert hinzufügen, dann nach Typ sortieren und alle Indizes neu vergeben (einfach hochzählen). Dass damit früher gespeicherte Level/Spiele unter Umständen unbrauchbar werden sollte klar sein.

Das ist ja das Problem. Genau das will ich ja vermeiden, dass bei neuen Grafiken, Items, Maps, usw sich Zuordnungen ändern. Die Grafik GUI_Background.gfx soll _IMMER_ den gleichen Identifier haben.

Weiterhin ist es nicht nötig dass die Indizes durchgehend sind wenn du eh eine Map benutzt (bei einem Arrayindex wäre das anders). Du könntest zb 1000-1999 für Schwerter vorsehen, 2000-2999 für Äxte usw. . Da solltest du genug Platz zum einfügen haben. Und wenn du eine Grafik einfügst gibst du nur den Typ (also zb Schwert/Waffe) an und der Editor fügt selbst den nächsten freien Index dieser Kategorie dafür ein.

Nun ja bei mir müssen die Indizes auch nicht durchgehend sein, aber wo zieht man die Grenzen? Ein Bereich von 1000 mag ausreichen. Aber wenn ich da an Tile-Grafiken denke könnten auch 5000 vielleicht knapp werden. Wie gesagt ist mir das etwas zu unflexibel.

Weiterhin kannst du ja die GetTexture Methode überladen so dass sie dir einmal mit dem Index die Textur zurück gibt und einmal mit dem Namen falls die wirklich eindeutig sind (Dateiendung würde ich auch weglassen).

Daran hab ich auch schon gedacht. Ich denke ich werde einen oben beschriebenen Text-Identifier nutzen. Ob ich nun dennoch noch einen Integer-Index anbiete muss ich überlegen. In den Datenbanken könnte ich jedenfalls per Identifier Grafiken referenzieren. Das wäre schonmal eine Verbesserung.


Nachtrag: Ich denke ich verwerfe die ganzzahligen Grafikindizes völlig und nutze nur die Zuordnung über die Identifier der Form "Typ_Name". Das lokale ID-Mapping für Maps halte ich aber für sinnvoll, da die eigentlichen Tiledaten dann recht kompakt bleiben und einfach zu laden sind. Das Mapping muss ich dann nur beim Speichern und Laden berücksichtigen und in der Regel nutzt man pro Map eh nur so 20-30 verschiedene Tiles, wodurch das Extramapping im Mapheader nicht allzu groß werden dürfte.

Danke erstmal für die Anregungen. Mit dieser Lösung kann ich ganz gut leben.

[BeRsErKeR]

Entscheidend wäre ja z.B. auch, dass der MapEditor weiß, welche Grafiken denn nun wirklich TileGrafiken sind. Der soll ja nicht die ItemGrafiken als TileGrafik anbieten.

textures\items\Dagger.png?

Nochmal als Nachtrag. Das ging bislang nicht, da nach dem Laden nur noch die ID blieb. Das heißt es gab keine Möglichkeit festzustellen wie die Datei hieß.

Ich muss auch anmerken, dass es keinerlei Ordnerstruktur gibt. Alle Dateien befinden sich in Packages (pak-Dateien). Diese sind ein eigenes Format von mir und ermöglichen keinerlei Hierarchie. Daher müssen Dateinamen auch eindeutig sein. Vielleicht auch nicht gerade schön, aber das Projekt existiert auch schon sehr viele Jahre und Zeit für alle möglichen schönen Feature hatte ich leider nicht. Ich nutze deshalb in der Regel Dateinamen wie "GUI_Background.gfx" oder "MO2D_Tree.gfx" usw (wobei MO2D für MapObjekt2D steht).

Deine Idee lässt sich mit einem passenden Identifier ála "Item_Dagger" natürlich dennoch umsetzen.

[Krishty]

Wie gesagt finde ich Identifier wie "Dagger" usw auch besser. Die Vorteile von Ganzzahl-Indizes sind aber:
1. Speichern als 16-Bit oder 32-Bit Wert
[…]
Gerade Punkt 1 ist für meinen Map-Editor recht hilfreich, da das Mapformat recht einfach bleibt. Ich könnte allerdings auch eine Art mapinternes Mapping im Header der Mapdatei speichern, wo ich lokal den globalen Text-Identifiern für Grafiken lokale Ganzzahl-Indizes zuweise, die ich dann für die Tiles nutze.

Okay; wie groß der Mehraufwand in deinen Dateien ist, kommt darauf an, ob du wahlfreien Zugriff brauchst.
Falls nicht, ist das Parsen eines Strings variabler Länge nichts, wodurch das Format jetzt unendlich schwieriger zu lesen oder zu schreiben ist.
Falls doch, benutz entweder die Indizes-im-Header-Methode oder limitier die Identifier auf feste 32 Zeichen; dann musst du aber auch daran denken, dass die Toolchain keine Maps zulässt, bei denen die Indizes überlaufen könnten oder bei denen der Artist mehr als 32 Zeichen benutzt.

Ich muss auch anmerken, dass es keinerlei Ordnerstruktur gibt. Alle Dateien befinden sich in Packages (pak-Dateien). Diese sind ein eigenes Format von mir und ermöglichen keinerlei Hierarchie.

Genau die falsche Auslegung von „Keep it simple“ ;)

[BeRsErKeR]

Wie gesagt finde ich Identifier wie "Dagger" usw auch besser. Die Vorteile von Ganzzahl-Indizes sind aber:
1. Speichern als 16-Bit oder 32-Bit Wert
[…]
Gerade Punkt 1 ist für meinen Map-Editor recht hilfreich, da das Mapformat recht einfach bleibt. Ich könnte allerdings auch eine Art mapinternes Mapping im Header der Mapdatei speichern, wo ich lokal den globalen Text-Identifiern für Grafiken lokale Ganzzahl-Indizes zuweise, die ich dann für die Tiles nutze.

Okay; wie groß der Mehraufwand in deinen Dateien ist, kommt darauf an, ob du wahlfreien Zugriff brauchst.
Falls nicht, ist das Parsen eines Strings variabler Länge nichts, wodurch das Format jetzt unendlich schwieriger zu lesen oder zu schreiben ist.
Falls doch, benutz entweder die Indizes-im-Header-Methode oder limitier die Identifier auf feste 32 Zeichen; dann musst du aber auch daran denken, dass die Toolchain keine Maps zulässt, bei denen die Indizes überlaufen könnten oder bei denen der Artist mehr als 32 Zeichen benutzt.

Nunja es gibt bis zu 768 Tiles und 5 Layer. Das heißt es wären dann 3840 Strings pro Map. Das bläht nicht nur die Maps auf sondern verlangsamt das Laden von Maps auch.

Ich muss auch anmerken, dass es keinerlei Ordnerstruktur gibt. Alle Dateien befinden sich in Packages (pak-Dateien). Diese sind ein eigenes Format von mir und ermöglichen keinerlei Hierarchie.

Genau die falsche Auslegung von „Keep it simple“ ;)

Das Projekt dient auch dazu verschiedenste Dinge zu üben oder mal gesehen zu haben. Die pak-Dateien entstanden aus Interesse, weil ich soetwas mal umsetzen wollte. Allerdings halt recht simpel, daher keine Ordnerstruktur. Viele Elemente entstanden aus interessiertem Ehrgeiz. Gerade deshalb versuche ich nun einige Verbesserungen vorzunehmen. Wie eben die Grafikindizes. ;)

[Krishty]

Okay, ich würde auch eine String-Tabelle an den Anfang der Datei schreiben und daraus indizieren. Dann hast du quasi keine Änderung am Dateiformat außer der zusätzlichen Indirektion zum tatsächlichen Namen.

Und naja, PAKs bin ich eigentlich Feind. Gaaanz am Ende, wenn man released, kann man seine Sachen vielleicht in einem Archiv zusammenfassen und zur Laufzeit transparent entpacken, aber für alles andere ist eine gewöhnliche Ordnerstruktur mehr als ausreichend. Von so Sonderfällen abgesehen wie, wenn man 15.000 Dateien auf 80 MiB presst und dann der NTFS-Sektor-Overhead so viel Platz ausmacht wie die Nutzdaten an sich (auch schon gesehen).

[BeRsErKeR]

Und naja, PAKs bin ich eigentlich Feind. Gaaanz am Ende, wenn man released, kann man seine Sachen vielleicht in einem Archiv zusammenfassen und zur Laufzeit transparent entpacken, aber für alles andere ist eine gewöhnliche Ordnerstruktur mehr als ausreichend. Von so Sonderfällen abgesehen wie, wenn man 15.000 Dateien auf 80 MiB presst und dann der NTFS-Sektor-Overhead so viel Platz ausmacht wie die Nutzdaten an sich (auch schon gesehen).

Ich mag PAKs. Nicht wegen der Komprimierung, sondern weil ich alles schön kompakt in 5-10 Dateien habe und nicht Unmengen an Ordnern brauche. Ist wohl Geschmackssache.

[Schrompf]

PAKs sind wohl am Ende gut, wenn man ausliefern möchte. Bis dahin macht aber allein die Versionsverwaltung bereits einen Strich durch die PAK-Rechnung.

[eXile]

Ich mag PAKs. Nicht wegen der Komprimierung, sondern weil ich alles schön kompakt in 5-10 Dateien habe und nicht Unmengen an Ordnern brauche. Ist wohl Geschmackssache.

Anmerkung: Bereits Quake benutzte ein solches Format, und das war nichts anderes, als eine zip-Datei auf 0% Kompressionsrate -- dort hatte man also durchaus eine Ordnerstruktur zur Verfügung.

[BeRsErKeR]

@Schrompf: Da hast du natürlich recht. Aber das Projekt ist ein 1-Mann-Projekt und vorallem im Programmierbereich wird es das auch immer bleiben. Ich nutze dennoch lokal hg und muss aber dazu sagen, dass während der Entwicklungsphase alle Dateien in Ordnern untergebracht sind. Über Shell-Scripts werden dann alle Dateien verpackt und mit der Executable in einen Release-Ordner gepackt. Das heißt ich nutze schon noch normale Ordnerstrukturen während der Entwicklung, allerdings lädt das Spiel selbst dann die generierten PAKs. Ich kann aber dennoch alle Grafiken, Datenbanken usw einzeln bearbeiten und mit hg/git/usw verwalten.

@eXile: Da ich selbst an einem QuakeIII Mod beteiligt bin und jahrelang gemappt habe, ist mir das durchaus bewusst. Um ehrlich zu sein stammt die Idee sogar von Quake. Allerdings wollte ich was eigenes machen, wegen des Lerneffektes.