spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Fass einfach mehrere Tiles zu einem Block zusammen. Z.B. ein Viertel der Screengröße. Diese kannst Du separat auf Sichtbarkeit testen. Jedes Tile einzeln zu zeichnen und auch jedes Tile einzeln auf Sichtbarkeit zu testen, ist jedenfalls nicht optimal. Eventuell reicht es auch alles in einen einzigen VertexBuffer zu schmeißen und diesen komplett ohne Sichtbarkeits-Prüfung vollständig zu rendern und den Rest der Grafikkarte zu überlassen.
Ich würde nicht unbedingt dazu raten die Dinger in einer Textur vorzurendern. Das gibt meist Probleme mit diversen z-Überlappungen von dynamischen Objekten.
Allerdings muss ich auch erwähnen, dass solche Optimierungen heutzutage selbst auf Smartphones eventuell komplett überflüssig sind. Man verbrät Leistung, klar. Aber man spart an Entwicklungsaufwand

Eine ganze Gruppe von Tiles pro Draw Call zu rendern ist wohl der beste Ansatz. Einfach alles zu rendern wird, abhängig von der Größe der Map, doch recht schnell recht verschwenderisch. Wenn es sich speichermäßig ausgeht, könntest du die ganze Map z.B. einfach zeilenweise in einen Vertex und Index Buffer zu packen. Dann brauchst du in jedem Frame nur ausrechnen, welche Abschnitte welcher Zeilen sichtbar sind und dann machst du einen Draw Call pro Zeile...

Tiles sind regelmäßig geordnet. Du kannst also jederzeit exakt bestimmen, welche Tiles sichtbar sind, *ohne* die einzelnen Tiles abzuklappern. Von da an ist es kein Problem mehr, einfach alle sichtbaren Tiles auf einen Rutsch rauszuhauen. Das ist der komplett dynamische Ansatz, den ich üblicherweise fahre, und quasi jedes Framework bringt irgendne Art Sprite Batcher mit, um mit dieser Arbeitsmethode schnell ans Ziel zu kommen. Noch schneller wird's, wenn die Tiles dann auf einem Texturatlas zusammengefasst werden.

dot's Idee der VertexBuffer-Ausschnitte geht aber auch prima, weil die Tiles ja linear darin liegen und Du nur einen linearen Ausschnitt daraus brauchst. Dann kannst Du schlicht über die DrawCall-Parameter bestimmen, welchen Zeilenabschnitt Du brauchst. Dafür musst Du minecraft-style alle Buffer, die von einer Änderung betroffen sind, neu erstellen. "So effizient" wie möglich wär das nicht, weil Du bei kleinsten Änderungen jeweils ganze Zeilen neu erstellen musst, was bei großen Maps ein enormes Missverhältnis zwischen Änderungen und statischen Daten wäre. Die offensichtliche Verbesserung wäre das Organisieren in Quadraten anstatt in Zeilen, weil in nem Quadrat räumlich alles näher beieinander liegt und demzufolge wahrscheinlicher ebenso von einer Änderung betroffen wäre. Und das trotzdem noch mit dot's Idee der DrawCall-Parameter zu rendern wär ne richtig geile Spielerei. Du kannst ja in nem 2D-Gebilde jeweils eine Zeile rendern und dann per Instancing und mit Offset pro Instanz den Differenz zur nächsten Zeile umsetzen. Hey, das wär cool.

Leider ist das, wie BlueCobold schon schrieb, völlige Verschwendung von Lebenszeit, weil selbst Handys stressfrei jede Zelda-Map in einem DrawCall raushauen und dabei noch nichtmal aus der Puste geraten. Aber wenn Du das als Hobby betreibst, warum nicht... es gibt da doch Ansätze, die ich zu Lebzeiten noch nicht gesehen habe :-)

Letztlich hängt es auch stark vom Ziel ab. Also über was reden wir hier? Reden wir von 1000x1000 Tiles, von denen immer nur 20x15 auf den Bildschirm passen? Oder von 1000x1000, wovon immer 800x600 zu sehen sind (in Zeiten von 4k-Monitoren muss man selbst mit sowas ja eventuell rechnen)? Oder reden wir von 100x80, von denen 80x60 auf den Bildschirm passen? Oder von 12x8 Tiles, von denen 10x6 auf den Screen passen? Das macht plötzlich riesige Unterschiede. daher bezog ich mich bei meiner Gruppierung auf eine Menge an Tiles, abhängig von der Darstellungsmenge.

Für unendlich große Tilemaps nehme ich immer Chunks, ähnlich wie in Minecraft, werden dabei z.B. 10x10 Tiles zu einem Buffer zusammengefasst und dieser wird auf Sichtbarkeit geprüft. Wenn sich der Spieler bewegt können (wenn wirklich so riesig ist) dann dynamisch neue Buffer erzeugt werden und am "anderen Ende" wieder freigegeben werden.
Man kann aber auch sehr sehr große Karten einfach in einem Buffer rendern. So wirklich spüren wird man das zumindest auf einem PC wahrscheinlich nicht.

Wichtiger als die Anzahl der dargestellten Tiles ist die Anzahl der nicht sichtbaren Tiles Sind nämlich nur 20% nicht sichtbar, ist das was ganz anderes als wenn 95% nicht sichtbar sind. Bei ersterem lohnt sich View-Culling überhaupt nicht.

Lies meinen Beitrag nochmal.