davon ausgehend dass das additive Zeichnen schuld ist… ist es dann normal, dass eine Farbzuweisung von RGBa(255,255,255,255); trotzdem noch zu Lag führt? Das Licht ist nicht mehr sichtbar, aber trotzdem Lag das Spiel noch. Erst wenn ich SetVisibility verändere, hört das laggen auf. Wundert mit nur etwas, dass die Durchsichtigkeit von 255 nichts bewirkt und gibt mir gerade die Hoffnung, dass es vllt doch eine andere Ursache haben könnte? 
Ja, weil es darauf ankommt, ob gerechnet wird, nicht mit welchen Werten gerechnet wird.
Einfaches Beispiel: Du hast eine Addition in deinem Programmcode (additives Zeichnen ist ja auch genau das): result += x;
Für die CPU ist es völlig egal, ob x null ist oder nicht - sie führt immer eine Addition aus.
Der Code könnte aber die Addition vielleicht nur ausführen, wenn eine weitere Variable gesetzt ist (d.h. das Objekt sichtbar ist):<br/>if (doAddition) {<br/>   result += x;<br/>}<br/>
Jetzt wird die Addition nur dann ausgeführt, wenn doAddition gesetzt ist, wir sparen also manchmal eine Instruktion ein! (davon abgesehen, dass dieser einfache Fall wegen der CPU-Pipeline nicht wirklich effizienter wäre)
Genauso funktioniert auch das additive Zeichnen. Das eigentliche Zeichnen ist eine Schleife über alle Pixel der Grafik, wobei die Farbwerte addiert werden (unter Berücksichtigung des Alpha-Wertes). Wenn das Alpha dafür sorgt, dass man nichts davon sieht, dann hat das trotzdem keinen Effekt auf die Addition - es wird eben 0 addiert und trotzdem Zeit dafür verbraucht. Der Visibility-Wert ist die Zusatzbedingung, die dafür sorgt, dass diese ganze Zeichenschleife mit ihren vielen Additionen gar nicht erst ausgeführt wird.
Theoretisch könnte natürlich eine zusätzliche Bedingung dabei sein, die auf Alpha-Wert 255 überprüft. Das würde dein Problem aber auch nicht lösen.
1 „Gefällt mir“
alles klar, danke dir für die ausführliche Erklärung 
Habe jetzt eine Regel eingebaut, die man jederzeit aktivieren kann, und die die normale Helligkeit der Landschaft herstellt, dafür sorgt, dass diese nicht mehr in der Nacht runtergesetzt wird und Lichter durch SetVis nicht sichtbar sind Wenns dann iwann bei zuvielen Lichtern laggt, stellt man das halt ein… Die Lichter haben glücklicherweise noch den 2ten Effekt, dass sie SetPlrViewRange verteilen, sodass es trzd. sinnvoll ist Fackeln und Lcihtobjekte zu bauen
Danke für diesen Beitrag, interessante Feststellung - kein Wunder das viele hazard-basierende Szenarien und Pakete unter schlechter Performance leiden, die Engine läuft sich an ineffizienten Rechenaufgaben kapputt nur um simple Lichtkreise und -kegel darzustellen =|
Ich hatte da ja immer die Dunkelheit an sich unter Verdacht^^'
Tritt das Problem mit LC noch auf? Das Einzige, was bei additivem Rendering geändert wird, ist die blend function.
Ich mache leider noch immer eine Auszeit von Clonk (weil ich mich sonst wieder total in meine Pack-Sammlung reinstürze und da weiter modde und total meine Arbeit vernachlässige). Daher habe ich auch kein Clonk installiert.
Ich glaube aber man kann es leicht mit Hazardlichtern testen, also einfach 20-40 mittelgroße hazardlichter in den bildausschnitt packen und gucken was passiert. (in meinem Pack hat später jedes Gebäude sein eigenes Licht, welche sich evlt auch überlagern)
(mein Pack ist auf ccan und heißt Serpens66Pack GameplayPack http://ccfmirror.striver.net/ccf.striver.net/prae2e.html?pr=1549 )