spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Grundsätzlich sollte man sowas weitestgehend vermeiden.
Mach es ruhig erstmal für jedes Quad (oder auch 3D Geometrie), das wird erstmal nicht stören.

Später kann man Instanzen gleicher Objekte sowieso besser instanziert rendern, dann hast du keine Bufferwechsel und auch keine Texturwechsel. Je weniger desto schneller.
Für unsere Zwecke (gerade 2D) ist das aber alles eigentlich auch irrelevant. Wann hat man schon > 1000 Sprites im Bild?
Wenn es um Grafikperformance geht ist die Devise eigentlich immer: möglichst wenig Kommunikation mit der Grafikkarte.

Wenn du weißt das deine 1000 Quads die gleiche Textur haben kannst du diese natürlich besser außerhalb binden, also dort wo ich auch meine Buffer binde. Nach der for Schleife dann das unbind().
Den Shader solltest du nur einmal binden, der macht ja für alle das gleiche (sollte er zumindest).

Falls dich das übrigens verwirrt kannst du immer in die Klasse gucken, dort siehst du dann in den Methoden welche GL Funktionen ich aufrufe. Ich habs teilweise selbst schon wieder verlernt weil ichs abstrahiert habe
Aktueller branch ist "light", ich änder häufiger Kleinkram in den Klassen... also evt. immer beim aktuellen gucken.

Ja, ein Grid in den Buffer packen und rendern
Sprite heißt für mich abgetrenntes Quad, bei einem Grid hält man alle Tiles in einem Buffer (bzw. mehrere jeweils für Vertices, Texturkoords, ...).

Geht es hier darum?

Zitat von »Schwarzefee«

	C-/C++-Quelltext
1 2 3 4 5	shader->bind(); [...] texture->bind(); [...] texture->unbind();

Wie schauts denn da mit der Performance aus?
Ist es OK wenn man das bei jedem Quad aufruft? D.H. man hat keinen Geschwindigkeitsverlust wenn man ein ShaderProgram, Texture, etc. bindet, obwohl es ja eigentlich schon gebunden ist?


Gruß

Also den Shader öfter als nötig zu binden muss man unbedingt vermeiden. Jedenfalls als ich das vor ca. 2 Jahren mal geprüft hatte, hatte es zu sehr starken Performance-Einbrüchen geführt, als ich den Shader jedes Mal neu aktiviert habe. Anscheinend wird das durch die Grafikkarte/Treiber nicht geprüft (was an sich sinnvoll ist, reicht wenn die Anwendung das richtig organisiert). Aber vielleicht ist das heute auch schon anders...

Du wirst doch sicherlich wissen wie groß deine Tilemap ist, dann reicht es natürlich wieder diese einmal in den Buffer zu schreiben.

Vorgehen könntest du dann so dass jedes Tile aus 4 Vertices, 4 Texturkoordinaten und 6 Indices besteht. Diese erstellst du dann grundsätzlich genau wie meine Sprites, nur dass du sie um die x bzw. y Koordinaten verschiebst.
Also für eine 10x10 Tilemap 3 Buffer anlegen, Tile 0|0 hat dann die Vertices 0|0, 1|0, 1|1 und 0|1. Das nächste (sagen wir mal x+1) hätte dann die Vertices 0|0+1|0, 1|0+1|0, 1|1+1|0 und 0|1+1|0. Das schreibst du alles erstmal in ein array und lädst es dann als großen Datenhaufen in den Buffer.
Vorteil ist dass du die gesamte Tilemap dann wieder über eine Matrix skalieren kannst, also z.B. x32 dann wäre jedes Tile (bei orthogonaler Projektion) 32px breit.

Nochmal: das ständige neu Erstellen ist langsam und überflüssig. Nur wenn sich die Daten tatsächlich ändern (und sich dies nicht im Shader dynamisch erledigen lässt), dann solltest du den Buffer updaten. Eine Tilemap ist ein statisches Objekt. Trenne einfach zwischen Initialisierung und dem render Durchlauf selbst.