spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »CBenni::O«

Wieso erstellst du ein Makro? Sollte eine inline-Funktion nicht das selbe Ergebnis erzielen?

mfg CBenni::O

Nein, erzielt nicht das selbe Ergebnis. Funktion, die Inline Funktion aufruft, die Inline Funktion aufruft, die Inline Funktion aufruft -> 3 Calls insgesamt. Funktion, die Makro aufruft, das Makro aufruft, das Makro aufruft -> 1 Call. Hinzu kommt, dass der Compiler das spätere Ergebnis deutlich besser optimieren kann. Ist ein Schnipsel aus unserem Software-Renderer und was der auf einem handelsüblichen Quadcore-Xeon pro Sekunde im 2D-Bereich an dynamischen Linien und Flächen durch die Schaltkreise prügelt, lässt jede Grafikkarte erblassen. Die Wartbarkeit hält sich so natürlich arg in Grenzen, aber seit Jahren in unseren Navigationssystemen und Servern im Einsatz und auch wenn Makros generell ja "Pfui" sind, heiligt Erfolg in Fällen wie diesen halt die Mittel. Und glaub mir, den gesamten Quelltext willst du nicht sehen, dass mit dem Makro -> Makro -> Makro war noch sehr stark untertrieben, von den rekursiven Includes ganz zu schweigen. :-)

LG
Alyx

Okay, hatte mich nur gewundert

mfg CBenni::O

Wie gesagt, ich denke nicht, dass es teuer ist die Transparenzfarbe durch einen sinnvollen Alpha-Wert zu tauschen, das ist eine lächerliche Vorschleife von 1024x1024 oder welche Auflösung deine Zeichnung auch immer hat, ich sehe da derzeit nicht das Problem :-). Ansonsten kannst du es machen wie David bereits vorgeschlagen hat, Framebuffer mit RGBA initialisieren, bei glClearColor mit Alpha 0 füllen und dann ganz normal zeichnen, dann sollte der A-Wert richtig gefüllt sein, wenn du nur untransparente Dreiecke bzw. welche mit Alpha-Testing darstellst.

LG
Alyx

Zitat von »Alyx«

Also mein letzter Stand der Dinge war hier, dass du zwar sehr wohl RGBA-Framebuffer erstellen kannst, diese aber nur gezielt durch tricksten überhaupt sinnvoll gefüllt werden können und weder die gerenderten Fragmente mit dem bereits enthaltenen Inhalt noch die Alpha-Werte sinnvoll miteinander kombiniert werden. Sprich wenn man zwei mal mit A 0.5 über die selbe Stelle zeichnet enthält der FB anschließend 0.5 und nicht 0.75 wie es sein müsste. Sie machen also nur Sinn, um rein gealphatesteten Objekten einen Alphakanal sinnvoll füllen zu lassen, nämlich mit 0.0 oder 1.0, ihen eigentlich darüber hinaus erwünschten Sinn z. Bsp. zur Erzeugung von Impostern mit alphatransparenten Texturen oder generell halbtransparenten Flächen jedoch leider nicht.
Korrigier mich bitte, wenn du da einen sinnvollen Weg kennst, würde mich auch sehr interessieren, wenn so etwas irgendwie ginge... mir fehlte da bisher immer der Framebuffer-Shader

Das füllen des Framebuffers mit Alphawerten läuft normalerweise über die Vertexfarben/Texelfarben. Damit kann der Framebuffer selbstverständlich mit allen möglichen Alphawerte gefüllt werden.
Was du mit "sinnvoll miteinander kombinieren" meinst ist mir etwas schleierhaft. Es gibt zig. Blendfunktionen/Combiners die allerhand Kombinationen erlauben. Oder man macht das selbst im Shader (das wär ohnehin der konforme Weg).

Übrigens, eine Frage zu deinem Code: Wenn du so viel Wert auf Geschwindigkeit legst. Wieso dann die vielen Divisionen (ich meine nicht die die sowieso optimiert werden)?

Bzgl. der Divisionen: Ich weiß nicht genau, worauf du dich da beziehst. Wenn du meinst, wieso wir anstatt dessen nicht geshifted haben: Weil es auf ARM-Prozessoren langsamer war und dafür war das Ganze ursprünglich konzipiert.
Generell mussten wir wegen dem Windows CE-Compiler diverse Konstrukte bauen, wo auf den ersten Blick jeder sagen würde: Wie kann das schneller sein? Ein ganz gutes Beispiel dafür ist das

Zitat

__BA = __OA; \
__BA = (__BA*__AntiAlpha)/255 + __Alpha;

Sollte man meinen, dass __BA = (__OA*__AntiAlpha)/255 + __Alpha; hier ja definitiv schneller sein müsste als es erst der Variable zuzuweisen, um sie dann direkt danach mit einem neuen Wert wieder zu überschreiben. Ist es in dem Fall aber nicht, da er das andere Konstrukt besser optimieren kann. Sprich wir haben tagelang an einzelnen Formen wie diesen solange hin und hergestellt und am Ende die genommen, die die beste Leistung lieferte (auf dem ARM). Auf dem x86 könnte man bestimmt noch ein gutes Stück mehr rauskitzeln, wenn man es drauf anlegen würde, aber da die Leistung mehr als nur zufriedenstellend war, haben wir uns die Mühe nicht mehr gemacht. Das RGBA8-Beispiel ist in der Praxis aber generell auch eher ein Exot, hatte es nur der Formel halber mal rausgesucht :-).

Aber mal zurück zum eigentlichen Thema:
Folgendes Szenario: Du zeichnest auf die selbe Stelle 10x ein Rechteck mit einem Alpha-Wert von 0.1 und möchtest am Ende eine Textur haben, die sich, wenn man sie anschließend in einen anderen FB ausgibt, so verhält, dass der andere FB am Ende genau so aussieht, als hätte man diese 10 Rechtecke direkt in diesen gezeichnet. Ohne Shader ist das soweit ich weiß nicht möglich, zumindest fiele mir auf anhieb keine sinnvolle Konfiguration für BlendFunc und Equation ein, mit der man diesen Effekt erzielen könnte. Via Shader könnte man das ganze eventuell realisieren, wenn man nicht in den Haupt-FB zeichnet, sondern via RenderToTexture und dann dem FS gleichzeitig den Ziel-FB, also der der Textur in diesem Fall, als Textur zur Verfügung stellt, so dass ihm dann alle Werte zur Verfügung ständen, die er für die Berechnung benötigt.

LG
Alyx

Zitat

Ich weiß nicht genau, worauf du dich da beziehst. Wenn du meinst, wieso wir anstatt dessen nicht geshifted haben: Weil es auf ARM-Prozessoren langsamer war und dafür war das Ganze ursprünglich konzipiert.

Nein, ich bezog mich hauptsächlich auf folgende Stelle



Selbst auf dem ARM sollten Multiplikationen schneller sein als Divisionen. Bei der von dir angesprochenen Stelle sollte der Compiler ohnehin optimieren.

Zitat

Folgendes Szenario: Du zeichnest auf die selbe Stelle 10x ein Rechteck mit einem Alpha-Wert von 0.1 und möchtest am Ende eine Textur haben, die sich, wenn man sie anschließend in einen anderen FB ausgibt, so verhält, dass der andere FB am Ende genau so aussieht, als hätte man diese 10 Rechtecke direkt in diesen gezeichnet. Ohne Shader ist das soweit ich weiß nicht möglich, zumindest fiele mir auf anhieb keine sinnvolle Konfiguration für BlendFunc und Equation ein, mit der man diesen Effekt erzielen könnte. Via Shader könnte man das ganze eventuell realisieren, wenn man nicht in den Haupt-FB zeichnet, sondern via RenderToTexture und dann dem FS gleichzeitig den Ziel-FB, also der der Textur in diesem Fall, als Textur zur Verfügung stellt, so dass ihm dann alle Werte zur Verfügung ständen, die er für die Berechnung benötigt.

Wieso sollte man so etwas tun wollen? War das die Anforderung des Threaderstellers?

Bäume mit alpha-transparenten Texturen in Imposter umwandeln ist hier denke ich ein gutes Beispiel, für das man so etwas bräuchte.
Und ja, für mich klang die Frage des Threaderstellers so, als wollte er am Ende die Szene Mit-Ohne-Hintergrund :-).

LG
Alyx