spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Spiele Programmierer«

Zitat

Komplett neu befüllen (so hab ichs verstanden) wäre wahrscheinlich schlimmer als 10k Sprites zu rendern...

Ich, bei meinen persönlichen Experimenten in letzter Zeit, hatte zu meiner eigenen Überraschung in OpenGL(GTX760) keine Probleme mit dem Upload von über 1 000 000 Vertices pro Frame bei 60 FPS in ein VBO.

Man könnte natürlich die Tiles auch nach Updaterate sortiert in Buffer halten oder wie ich vorgeschlagen hatte, spezielle Shader verwenden.
Aber im Gegensatz der Verwendung eines einfachen VBOs (bzw SFML "VertexArray") ein deutlicher Mehraufwand in der Verwaltung und die gewonnene Effektivität auch nicht ganz so gewiss.

Das ist auch meine Erfahrung. Ich rendere alle Arten von 2D-Grafiken seit Jahren mit Vertex Buffer Objects. Und wenn man die passend erzeugt, so dass der GPU-Treiber einen Hinweis hat, dass man die oft neu befüllt, sind auch hunderttausend Sprites bei 60fps kein Problem mehr.

Den unveränderlichen Teil der TileMap in statische Vertex Arrays rauszuziehen ist dann natürlich noch etwas effizienter. Allerdings hat ja auch BlueCobold schon geschrieben, dass auf aktuellen Rechnern die Rechenzeit kein großes Problem mehr ist. Du solltest am Ende schon genau überlegen, ob Du hier wirklich die best-optimierte Lösung brauchst oder ob es nicht auch eine Lösung reicht, die alle Anforderungen erfüllt und "schnell genug" ist. Wenn SFML-Tiles das Problem lösen, dann nimm das und fertig. Wenn die SFML jedes Sprite in einem separaten DrawCall abhandelt, wirst ab ein paar tausend Sprites pro Frame in Probleme rennen. Dann würde ich zur nächstbesseren Lösung raten: dynamisch befüllte VertexBuffer (oder VertexArrays, da fehlt mir das API-Wissen). Und wenn Du dann noch mehr Performance brauchst und Du nach umfangreichen Profilen wirklich sicher weißt, dass es am Rendern der TileMap liegt, dann lohnt sich das Rausziehen der statischen Tile in feste VertexBuffer.

Kurzversion: einfachste Lösung programmieren, Ergebnis profilen. Ohne Profiling wird nicht optimiert!

Zitat von »Schrompf«

Kurzversion: einfachste Lösung programmieren, Ergebnis profilen. Ohne Profiling wird nicht optimiert!

Genau das ist auch das, worauf ich hinaus wollte.

Ich benutze ein Vertexarray für die eigentliche Map und verwende für animierte Tiles einzelne Sprites, die ich einfach darüberlege. Auf einem relativen alten Dual-Core Rechner mit einer 8800GT bin ich damit noch nicht an Performancegrenzen gestoßen und es ist einfach umzusetzen .

Wo wir gerade beim Thema sind...
Bin auch gerade dabei eine Tile map zu rendern.
Wie geht ihr mit den Texturkoordinaten um?

Bitte Bild im Anhang anschauen.

Jeder rote Punkt soll eine Vertex-Position darstellen. Nun zum Problem:
Um das gelbe Tile zu rendern hat der Vertex 3 die Texturkoordinaten (0,1).
Für das grüe hat er die Texturkoordinaten (0,0).

Ist es somit nötig für den Punkt 3 zwei Vertices zu benutzen?

Zitat

Ist es somit nötig für den Punkt 3 zwei Vertices zu benutzen?

Du kannst möglicherweise etwas optimieren, indem du:

• Für 2x2 Tiles jeweils die Quadranten spiegelst und somit den (0|0) in der Mitte ansetzt (spart dir dann die Bi-Redundanz für jeweils den 2ten Vertex in x- und y-koordinate), oder
  
• du nutzt die kachelung einer texture aus, oder
  
• du nutzt einen geclippeten texture-atlas prepass, und renderst, sich geupdatete Tiles in einen temporären RT
  

Es gibt sicher noch mehr Möglichkeiten, aber diese fallen mir grad mal spontan ein... die kachelung dürfte die effizienteste und am leichtesten zu implementierende methode sein.

Hey danke für die info.
Habe eigentlich vor eine Textur map in den Buffer zu speichern (Eine Art sprite sheet).
Also ich speichere mehrere Tile Texturen in einer "großen" Textur und hol mir dann entsprechend die Textur, die ich will, per Koordinaten raus.
Dort wird es dann schwierig ...

Du meinst Einen prebaked texture Atlas. Wenn du den so wie er ist zur runtime verwendest, bist du natürlich auf doppelte vertices angewiesen.

Wenn du wirklich einen texatlas nutzen möchtest, fiel mir jetzt noch eben ein, dass man auch im VS mithilfe einer übergebenen texture id und einem Constant buffer die texture coordinates selektiv bestimmen könntest. Ich kann mir aber sehr gut vorstellen, dass das auf die Performance geht, sollten es viele Daten werden.

Ansonsten empfehle ich dir, wenn du schon einen prebaked texture Atlas hast, diesen bei der Initialisierung auseinanderzuschneiden und zur runtime dann die kachelung auszunutzen

Über wie viele tausend mal tausend gleichzeitig sichtbare Sprites reden wir denn hier, dass solch merkwürdige Ansätze nötig oder sinnvoll wären statt einfach normale sf::Sprites zu nehmen und die im schlimmsten Fall in Chunks zu cullen?

Nun ja, Texture-Atlanten sind generell wie ich finde bei weitem kein "merkwürdiger Ansatz". Allerdings wüsste auch ich nicht, warum man ihn denn zur Laufzeit erstellen wollte? Wenn schon, dann nimmt man einfach ein Textur mit den verschiedenen Tiles und lässt evtl. noch einen Pixel zwischen den Tiles frei, um Filtering-Fehler zu umgehen.

@DerUltraLord: Ich würde dir ernsthaft empfehlen, dass du dir nicht den Umstand machst, einen Texture-Atlas zur Laufzeit zu erzeugen. Speichere ihn doch lieber statisch in einer Datei ab. Das ist zum einen einfacher und spart dir Zeit (ich nehme an du nimmst an der LetsGameDev Challenge teil, und dann benötigst du diese Zeit auch ). Und wenn es jetzt nicht gerade X-Tausend Sprites sind die du zeichnen möchtest, so muss ich Blue Recht geben: Da benötigst du keinen dynamischen Texture-Atlas. Ein statischer kann ganz schön sein, und hat - wie ich finde - auch seine Vorteile, aber in einem dynamischen sehe ich eine potentiell große Fehlerquelle.

Liebe Grüße,
~ EuadeLuxe ~