Ich verstehe nicht ganz dein Problem. Du kannst die Tilemap im Spiel doch verändern, auch während sie angezeigt wird.
Gibt die die ID des Tiles im Tileset zurück, welche an der Position x/y im Layer z liegt. Du kannst diese ID natürlich auch neu setzen.
Das geht sowohl mit Autotiles, wie auch mit normalen Tiles.
vielen Dank für die Information, das habe ich noch nicht gewusst, allerdings muss ich sagen, dass meine ersten Tests mit dieser Methode leider enttäuschend waren.Zitat von -KD-
Ein bereits bestehendes Tile in ein Autotile umzuwandeln bringt leider nicht den gewünschten Erfolg. (Betrachtet bitte hierfür den angehängten Screenshot)
Das Autotile passt sich nicht der Umgebung an.
Außerdem dienen diese Fragen nicht nur ausschließlich praktischem Nutzen, ich interessiere mich auch sehr für die reine Theorie dahinter.
Ich würde einfach aus Prinzip nicht nur gerne etwas programmieren sondern auch etwas programmieren können.
Autotiles werden mehr oder weniger wie normale Tiles behandelt. Du musst ihre Umgebung schon manuell anpassen. Es gibt afair auch Scripte, die das können. Wenn du es selbst machen willst, dann probier mal die verschiedenen Tile-IDs aus und untersuche den Mechanismus, der hinter der Erstellung der Autotiles steckt.
Aber jedes Tile als einzelnes Objekt mit eigenem Sprite ist aber keine Lösung. Zum einen werden in Ruby Objekte nicht gerade sonderlich effizient angelegt (vor allem in Ruby 1.8), zum anderen kommt auch die RGSS mit zu vielen Sprites nicht klar. Hier bietet sich die Vorgehensweise an, die die RGSS selbst intern vermutlicht verwendet:
- ein Bitmap pro Tile
- bei Autotiles wird für jede Kombinationsmöglichkeit ein Bitmap erzeugt (ist erstmal viel, aber man kann ja auch davon ausgehen, dass jede Möglichkeit mindestens einmal auf der Map gebraucht wird)
- die Tilemap wird aus Streifen von Sprites zusammengesetzt. Jeweils ein Streifen von 32 Pixeln Höhe wird per Blocktransfer aus den Bitmaps erzeugt und mit einem Sprite angezeigt. Du bräuchtest also für die Anzeige des Bildschirms 15 Streifen, dann aber nochmal für jeden Layer einen, also insgesamt 45 Sprites. Das ist noch vertretbar. Neue Blocktransfers müssen nur ausgeführt werden, wenn ein neuer Streifen in den Bildschirm rückt (und dann muss auch nur ein Streifen neu gezeichnet werden, die anderen rutschen einfach nach unten).
Dennoch wird die Performance dabei nicht berauschend sein.
Ich benutze allerdings keine Bewegung die auf 32x32 Pixel Tiles aufbaut sondern pixelgenau ist. Sprich würde ich zumindest 16 Reihen (bei einem 640*480 standard) brauchen oder mehr je nachdem wie groß ich das Window erstellen lasse.
Würde es vielleicht besser gehen die gesamte Tilemap als einzelnen großen Sprite dar zu stellen und jeweils per Blocktransfer an diesem einen Bitmap zu arbeiten?
Wenn ein Tile dann gegen ein anderes ausgetauscht werden würde müsste ich lediglich für 9 Tiles, das heist eine 64*64 Pixelfläche einen Blocktransfer durchführen.
Wenn die ganze Map ein großes Bitmap ist, bekommst du Probleme mit der Höhe/Tiefe der Events auf der Map. Ein Baum beispielsweise sollte für Events, die davor stehen, einen geringeren Z-Wert haben als für Events die dahinter stehen. Du kannst aber nicht einem Map-Layer mehrere Z-Werte zuordnen. Dafür müsstest du ihn schon in einzelne Streifen zerlegen.
ja das stimmt, dabei hast du natürlich recht, ich vergas zu erwähnen, dass mich der Z-Wert der Tiles in meinem Project nicht interessiert, beziehungsweise sie gar keinen besitzen.
Nun, da ich diese neue Information nachgereicht habe, denkst du (oder auch andere Mitglieder welche unserer Unterhaltung folgen) dass die von mir beschriebene Methode die Performance verbessern würde?
Ich denke wenn die Map ein riesiges Bitmap ist, müsste es recht effizient sein. Das kommt aber auf die Implementierung der RGSS an. Ich könnte mir z.B. vorstellen, dass die RGSS versucht ihre Bitmaps in der Grafikkarte zwischenzuspeichern. Und die hat nur begrenzt viel Arbeitsspeicher. Wenn das der Fall ist, könnte es bei Grafikkarten mit weniger Arbeitsspeicher effizienter sein, die Map als Mosaik einzelner großer Bitmaps (die durchaus auch größer als der Bildschirm sein können) darzustellen. Denn dann müssen im Ernstfall maximal 4 kleinere Bitmaps gleichzeitig angezeigt werden, was evtl. weniger Speicher kostet als ein großes. Aber ob dem wirklich so ist, musst du ausprobieren.
Vielen Dank, völlig befriedigende Antwort darauf.
Nun noch einmal zu meiner ersten Frage, stimmts du zu, dass es die beste Methode sei ein einziges Array zu verwenden in welchem alle Tiles gespeichert sind? (Tile speichern in dieser Hinsicht nicht die Bitmaps oder stellen Sprites dar, sondern beinhalten weitere Spieltechnisch wichtige Informationen)
Eine Art, Zweidimensionales Array Marke Eigenbau?
Ich persönlich finde ein eindimensionales Array eleganter. In einem Array aus Arrays ist der Zugriff vielleicht etwas einfacher, aber es lässt sich nicht so schön iterieren.
Die Frage ist eher, ob du wirklich ein Array aus Tile-Objekten verwenden solltest. Vor allem in Ruby 1.8 werden Objekte sehr ineffizient im Speicher abgelegt. Effizienter wären vermutlich einfach mehrere Arrays die jeweils ein Tile-Attribut enthalten. Am effizientesten ist es natürlich, wenn du die Klasse Table der RGSS nutzt. Mit der kannst du auch zweidimensionale Arrays hocheffizient abspeichern. Das Problem: Die Klasse darf nur Fixnum-Werte abspeichern. Du kannst also keine Strings oder andere Objekte darin hinterlegen.
Berechtigungen
Zitieren