spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Moin.

Ich will meine aktuelle Sprite-Verarbeitung umstellen auf einen Textur-Atlas und VBOs, sodass alle Sprites in "einem einzigen Call" gerendert werden können statt der im Moment noch alten Verwendung von glVertexArray & Co.
Das Problem stellen dabei die typischen Kandidaten dar, die aus dem Hintergrund-Puffer lesen müssen (z.B. Sprites mit Distortion-Effekten etc). Bisher war das so gelöst, dass ohnehin alle Sprites nach Ebenen sortiert einzeln gerendert wurden und solche Sprites mit speziellen Shader-Ansprüchen, welche auf dem Hintergrund basieren, ihren Bildinhalt nach dem Rendern in einen zweiten separaten Buffer kopiert haben, aus dem dann für die Effekte der nachfolgenden Sprites gelesen werden konnte. Sprich:
1) Alle normalen Sprites rendern
2) Hintergrund separat buffern
3) spezielles Sprite rendern - lesen aus Buffer+Textur -> schreiben in Backbuffer
4) Affected Region aus 3) vom Backbuffer in Buffer kopieren
5) Falls noch spezielle Sprites da, gehe zu 3)

Wenn ich jetzt alles in einem einzigen Pass/Call rendern will, dann sieht es mit dem Schritt (4) schlecht aus. Ich habe überlegt, ob man dafür zwei FBOs binden kann und gleichzeitig in beide schreibt. Allerdings weiß ich nun nicht, wie und ob es auch geht, dass ich in einem Shader auch entscheiden kann, dass ich nur aus dem einen lesen und in den anderen schreiben will. Sprich dass ich zwei Sprites rendere: Das erste liest aus Buffer1 und schreibt in Buffer2, das zweite liest aus Buffer2 und kopiert nach Buffer1. Ist das möglich und sinnvoll? Welche Alternativen seht ihr dabei? Eine weitere Unschönheit bei "alles in einem Call" wäre, dass ein einziger Shader alle Effekte bereitstellen müsste, man nicht einfach mal so neue Shader einhängen könnte oder ich die Render-Calls nach verschiedenen Shadern aufspalten müsste.
Meh, irgendwie komme ich da nicht so richtig auf eine Idee oder Lösung, mit der ich sowohl flexibel, als auch performant wäre.

Ja, das ginge und ist am Ende vermutlich auch die einzig variable Lösung. Solche Probleme zeigen mir aber immer wieder, wie sehr Rendering-APIs und -Hardware eigentlich noch in den Kinderschuhen stecken, weil sie bei Shadern mit Zugriff auf bisherige Render-Ergebnisse oder multiple Shader doch sehr unflexibel sind.

Ach nein? Wenn ich Shader-Programme anhand von Attributen wählen könnte, dann wäre das überhaupt kein Problem. Klar, das wäre nicht trivial in Hardware zu bauen, aber das habe ich auch nie behauptet. Die Parallelität würde dabei aber kein Stück tangiert.

Nein. Ich hätte gern SIMD, aber eben die Möglichkeit zwischen verschiedenen Shadern in einem einzigen Pass/Call wechseln zu können, wie man eben auch auf verschiedene Texturen oder Buffer zugreifen kann. Als Trigger über ein Attribut oder so, das wäre sehr nice. Momentan muss man ja leider entweder einen sehr großen Shader schreiben, der alles kann oder verschiedene Passes für jeden Shader einzeln machen. Aber gut, die Debatte sollten wir lieber lassen, ich weiß ja, dass Du gern die aktuellen Architekturen verteidigst und nur sehr schwer Kritik oder Änderungswünsche/Erweiterungen an ihnen zulässt, auch wenn mir nicht so ganz klar ist warum.

Ja, erstaunt mich gerade selbst etwas. Genau soetwas stelle ich mir irgendwie vor, ja. Wie genau, weiß ich nicht, aber diese Beschränkung ist schon eher hinderlich.