Wie am besten text rendern?

[Schrompf]

Ich wäre auch vorsichtig mit solchen Basteleien. Ich habe nämlich festgestellt, dass für viele Zwecke die Reihenfolge der Zeichenaktionen wichtig ist. Und sobald man anfängt, Zeichenaktionen verschiedener Texturen zu gruppieren, um Performance rauszuholen, versaut man praktisch zwangsweise die Reihenfolge.

[snoob741]

So habe mal mit der Basisimplementation des SpriteRenderers begonnen. Klappt soweit auch ganz gut. Nur habe ich nach wie vor grad nen logischen Hänger mit der Abarbeitung. Im Prizip arbeitet der Renderer wie ein Stack, d.h. ich pusche munter meine Sprites die gerendert werden sollen per draw clall, lege die Geometriedaten für das Rendern in einer Liste ab und wenn ich Render wird die Liste auf den Buffer übertragen. Überschreitet die Liste die allokierten Buffergröße wird dieser vorher neu initialisiert ...

Dies impliziert aber das ich permanent die Drawcalls aufrufe und den Stack pro frame lösche... Somit muss die Geometrie für jedes Sprite pro Frame neu berechnet werden.

Oder arbeitet Ihr eher wie ein Cache, d.h. einmalig draw aufrufen und dann nur auf die GPU flushen wenn sich was an der Liste geändert hat? Dann müsste ich aber etwas einbauen, was dynamische Daten von statischen unterscheidet, z.B. zwei separate Listen und ein draw call mit Zuordnungsflag. Nur die dynamische Liste würde dann gelöscht werden, die statische nie.

Denke der erste Ansatz ist wahrscheinlich eher state of the art, doch spart man nicht ne Menge durch das Caching? Da z.b. ganze Schriffzüge nicht ständig neu berechnet werden? Oder trennt Ihr sogar einen "normalen" SpriteRenderer und FontRenderer? Wahrscheinlich denke ich schon wieder zu komplizert ...

[Schrompf]

Das "Neuberechnen" der Sprites/Quads/Glyphen/Zeichen/WasAuchImmer kann ein bisschen Rechenzeit kosten, aber jetzt nicht exorbitant viel. Besonders seit ich die ganze Quad-Erstellung/Rotation/Skalierung/Texturkantenkorrektur per Instancing in den VertexShader geschoben habe, ist das so billig, dass es nicht mehr von Belang ist.

Du könntest natürlich einen "Cache" implementieren, so im Sinne von "vergleiche die reinkommenden Rendercalls mit dem bestehenden Satz Sprites vom letzten Mal, und setze erst dann ein Neu-Hochladen-Flag, wenn sich der erste Rendercall unterscheidet". Geht. Ob's was bringt, weiß ich aber nicht.

Abgesehen davon gibt da ja noch das Layout der Texte. Also so Sachen wie Zeilenumbruch, Zentrierung, Auspunkten bei Überlänge und sowas. Das mache ich aktuell jedes Frame live bei der Textausgabe, aber ich kann mir vorstellen, dass man ein paar Mikrosekunden sparen kann, wenn man es nur bei Änderungen einmalig tut. Das würde ich dann aber wieder in ne eigene Klasse auslagern. Vielleicht so:

Code: Ansicht erweitern :: Alles auswählen


class TextLayout {
void SetText( const std::string& text);
void SetParams( Font& font, Vector2f screensize, Alignment horizontal, Alignment vertical, and so on);
void Render( Vector2f topleft, AlphaColor color) const;
};


Dann hast Du eine Klasse, deren Job es ist, einen Text nach gegebenen Parametern anzuordnen und sich das zu merken. Diese Klasse kann dann auf Zuruf den vorformatierten Text irgendwo hin rendern, solange alle Parameter konstant sind. Ich würde aber ernsthaft erstmal messen, ob das überhaupt die Arbeit wert ist.

[snoob741]

Klingt logisch, ich denke ich sollte zuerst einmal alles ausimplementieren. Dann testen und dann kann ich ja immer noch optimieren und evtl. auch ein Chaching einbauen. So viel Text sollte man ja wirklich i.d.R. kaum auf einen Schlag anzeigen... Danke für die Anregungen.