Hm, das wage ich gerade mit der heutigen Hardware stark zu bezweifeln. Außerdem müsstest du da allein bei deiner Spritegröße ~72.000 Sprites füllen, damit der Buffer auf eine annähernde Größe kommt. Die Devise hat ja gelautet, und lautet auch bis heute noch "Batchen, batchen, batchen". Deshalb, ohne dass ich es noch gebenchmarkt habe, wiegen die gewonnen Kosten durch die Verwendung eines einzelnen Buffers für so gut wie das ganze Programm (d.h. kein Bufferwechsel) garantiert jeden etwaigen Verlust durch die Größe aus.
Das kann man schwer nachprüfen. Ich habe nicht sehr viele verschiedene Rechner auf denen ich Benchmarks ausführen kann, ich könnte mir aber sehr wohl vorstellen, dass gewisse Hardware Probleme mit zu großen Buffern haben kann. Je nachdem wie die Daten auf der Karte abgelegt werden könnte es dort zu ziemlichem aufwand führen bei gewissen Größen.
Falls zum Beispiel alle Daten des Buffers in aufeinanderfolgenden Speicherblöcken platziert werden (um Performance zu gewinnen) so können zu große Buffer definitiv zu erhöhtem Aufwand führen.
Nein, das muss man so nicht machen, wäre in jedem Fall definitiv viel zu viel Aufwand, da geb ich dir Recht. Ich habe das so gelöst, dass ich die Sprite-Zeichen-Befehle nicht direkt auf den Buffer übertrage, sondern in einer Kommando-Queue zwischenspeichere. Diese sortiere ich dann nach Z und Textur (später noch shader), dauert wie ich bereits geschrieben habe nur wenige Millisekunden bei einer plausiblen Anzahl an Sprites. Damit kann ich dann einen Buffer verwenden, und den auch in einem Rutsch befüllen.
Das ist schon eine beträchtliche Menge an overhead. Sortieren nach 3 Kriterien kann im Worst-Case ziemlich schlechte Ergebnisse liefern. Vor allem wenn du pro Frame sortieren musst (wenn wir davon ausgehen, dass sich die Objekte in jedem Frame bewegen ==> Worst-Case)
Ein interessanter Unterschied der scheinbar zwischen OpenGL und DirectX existiert, in letzterem ist bis 9 die Performance enorm gesteigert wenn man jedes Frame den ganzen Buffer neu befüllt (da ansonsten die Grafikkarte hängt während man den Buffer sperrt). Dazu sperre ich am Ende des Frames den gesammten Buffer mit dem "DISCARD"-flag, damit er gelöscht wird, und danach bei jedem Sprite mit "NO-OVERWRITE", das garantiert der Grafikkarte dass sie den Buffer auch verwenden kann während die CPU arbeitet. Ab DirectX11 ist es sogar ohne diese Flags nicht mehr möglich, einen Buffer von CPU-Seite aus zu befüllen, d.h. es entsteht keinerleich Nachteil durch statische oder dynamische Sprites...
Das scheint tatsächlich ein Unterschied zu sein. In OpenGL sperrt man keine Buffer. Wie sich die Performance im Vergleich verhält zu komplettem Neu-befüllen oder teilweise Füllen dazu habe ich keine Daten, das könnte man aber sicher ausprobieren.
Das würd ich so nicht unbedingt sagen. Zumindestens die Sache multiple Bufferschreibvorgänge und mehrere Buffer erzeugt auch einen gewissen Overhead auf CPU-Seite, allein wegen der API-Aufrufe und des Speichertransfers... das wären in dem Fall 19k weniger Aufrufe zum Sperren des Buffers, das hat bei mir noch ne Menge Performance für die (noch) unoptimierte N^2 Kollisionabfrage rausgeholt...
Wenn du die Textur wechselst und den selben Buffer erneut zeichnest sind das ebenfalls Aufrufe an die Hardware. Ich würde lediglich einen zusätzlichen Aufruf zum binden des neuen Buffers hinzufügen. Das ist eine relativ schnelle Operation und bei kleinen Zahlen wie 5 oder 6 Buffern keinerlei Problem.