Nun, um einige replies gleich zu verhindern: Natürlich habe ich den r_speeds Artikel studiert. =)

Als ich neulich gustavo22_bh (Burning Hate) gespielt habe ist mir aufgefallen das die Map an vielen Stellen ruckelt. Als Mapper habe ich gleich mal ein Blick auf die r_speeds geworfen. Als ich dann gesehen habe

400 wpolys 1600 epolys bei 25 Frames

bin ich fast vom Stuhl gefallen. Auf meinem PC (PIII-500,128MB,V3-3000) gibt's bei solchen Werten normalerweise die vollen 72 Frames. Naja ich habe mir halt gedacht 'Da haste was falsch in Erinnerung, das war schon immer so'. Von wegen! Dannach habe ich gleich mal Havoc gespielt und mir eine ähnliche Stelle gesucht. Und siehe da

380 wpolys 1700 epolys bei 68 Frames

An den 100 Entz mehr dürfte das ja wohl nicht liegen oder? Sind da noch mehr Faktoren im Spiel? Wie z. B. Texturgröße, Anzahl der Lichter (viele Bunte), Sichtweite usw.? Es kann sein das dies generell zu langsam ist (Ich habe auch nicht die aktuellen Treiber), aber mir geht es jetzt nur mal um diesen riesen Unterschied...

...es spielen sowohl dynamische Lichter (alle Lichter, die zumindest einen Namen haben, egal ob sie dann auch ein- und ausgeschaltet werden/flackern etc. oder nicht), als auch Transparenzeffekte eine große Rolle. Wenn man z.B. in HL durch ein Glasfenster schaut, muß die Engine sämtliche Polygone, die sie in diesem Moment darstellen muß doppelt berechnen. Beim ersten Mal werden die Texturflächen so berechnet, als ob das transparente Element gar nicht da wäre, im zweiten Durchgang wird dann die transparente Textur des Fensters in die zuvor berechneten Texturen "reingerendert". Bei dynamischen Lichtern funktioniert die ganze Sache prinzipiell genauso. Ich hoffe, das erklärt den Effekt...

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

*g* genau das was du eben erklärt hast habe ich schon mal einem im alten MR-forum erklärt. Daran habe ich jetzt aber nicht gedacht, ich werde beide Stellen nochmal genau untersuchen...