spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mach's mit einzelnen Sprites, bis es sich definitiv als zu langsam erweist und refactore dann. In Rickety Racquet machen wir aktuell alles per Sprites und das ist kein Problem. Zumindest nicht im Release-Modus. Im Debug hängt die Performance da aber auch an anderen Stellen

Wenn es bei dir so langsam war, dann hast du definitiv etwas falsch gemacht.
Für animierte Tiles kannst du einfach regelmäßig den Buffer updaten(Das was du auch mit einzellnen Sprites im Prinzip machen kannst, bloß viel uneffizenter) oder eine erweiterte Möglichkeit wäre auch ein Shader.

Ob einzellne Sprites schnell genug sind, ist eine Frage der Anzahl. Ein paar hundert gleichzeitig Sichtbare wären kein Problem. Ein einige Tausend sollten möglich sein, ist aber uneffizienter und leistungsraubender als es sein müsste und über diese Zahlen hinaus, kann es dann auch schon zu den ersten direkten Problemen kommen. Wenn man zb. weiter heraus zoomen können soll, wodurch sehr viele Tiles sichtbar würden, wird kaum ein Weg um eine anständige Lösung über "VertexArrays", wie das scheinbar in SFML heißt, führen.

Wenn du auch OpenGL nativ nutzt, wären Texture Arrays eine einfacher Alternative zu den Atlanten.
Direkt in SFML wird dir das vermutlich aber nicht zur Verfügung stehen.

Wenn ich schon "füllen leeren wieder befüllen..." höre zieht sich bei mir eine Augenbraue hoch.

Du kannst die Tilemap sicherlich per VA darstellen, ist aus Performancegründen auch sinnvoll (allerdings nicht relevant), aber warum sollte man die Daten wären des Spiel ändern?
Ich würde pro Tile einfach 4 Vertices in den Buffer schreiben und dabei "ganze" floats nehmen. Also die obere rechte Ecke von Tile 1 hätte die Koordinaten (1.0f|1.0f), die von dem weiter rechts (2.0f|1.0f) usw.
Dadurch skalierst du die Tilemap nachher einfach mit einem Faktor der der größe eines Tiles entspricht (z.B. 32, 64, ...) und tada! Du hast deine Tilemap.

Uniform Variablen?
Mehrere Buffer?
Indiziert updaten?

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

BlueCobolds Vorschlag ist da schon sehr sinnvoll wie ich finde. Du ersparst dir eine Menge Arbeit und bis es wirklich anfängt zu ruckeln musst du schon einiges an Content haben. Bei Sprites kannst du die Texturen ganz einfach austauschen. Wichtig ist aber auch der Hinweis den er dir gegeben hat. Wenn es langsam wird, teste im Release Modus. SFML ist im Debug Modus wirklich viel viel langsamer als im Release Modus. Nicht nur deine IDE umstellen, sondern vor allem die Release DLLs verwenden. Damit wirst du vermutlich gut fahren und kannst dir die Vertex Arrays sparen.

Man kann theoretisch ja auch die Release-DLLs für den Debug-Build mit VisualStudio verwenden. Ich wüsste zumindest persönlich nicht, wann mir die Debug-Version der SFML mehr Nutzen als schlechte Performance geliefert hat.

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.