Tutorial: Optimierung einer großen FM
zwecks besserer Performance
Immer wieder sind (vor allem) unter NewDark erhebliche Probleme mit der Performance zu verzeichnen. Das liegt im wesentlichen daran, dass unter NewDark vieles möglich ist, das ziemlich viele Ressourcen verbraucht.
Nun ein kleiner Führer, wie man seine FM von Anfang an optimieren kann. Und auch eine kleine Anleitung für Spieler, wie sie möglichst viel herausholen können.
Für Spieler und Dromeder.
Bearbeite die cam_ext.cfg mit einem Editor. Folgende Einträge bearbeiten
-Deaktiviere multisampling "multisampletype 8".
-Deaktiviere "d3d_disp_enable_hdr"
-Deaktiviere Bloom "postprocessing"
-Deaktiviere "d3d_disp_sw_cc"
-Deaktiviere "d3d_disp_enable_distortionfx"
-Aktiviere "d3d_disp_no_rgb10_buf"
-Aktiviere set "use_d3d_display".
Deaktivieren heißt: setze ein „;“ vor die jeweilige Zeile, aktivieren meint: lösche „;“. Speichern nicht vergessen.
FM Bau von Anfang an optimiert
Wenn man an einer großen Map arbeitet, wird man irgendwann zu dem Punkt kommen, an dem man sich Gedanken machen muß, wie wohl die Spieler damit zurechtkommen. FM-Bauer bekommen manchmal nicht mehr so richtig mit, dass die Performance nach und nach nachlässt, weil sie sich daran gewöhnen. Ab und zu muß man das überprüfen. In DromEd gibt es ein Tool (show_stats), das übrigens auch in der Konsole so funktionert. „show_stats“ zeigt unter anderem die Frames per Second (FPS) an. Faustregel: Wenn die FPS jemals an einer Stelle unter 25 fällt, haben die Spieler Grund zum Meckern, weil das Spiel nicht mehr flüssig genug läuft.
Einige Punkte, die man gleich am Anfang der FM-Bauerei beachten sollte
-Die Airbrushes sollten nicht zu groß sein 100x100, maximal 200x200 sein. Besser mehrere kleine nebeneinander.Ich komme später darauf zurück.
-Von Anfang an Texturen im dds-Format mit Mipmaps verwenden. Sowohl für Terrain-Brushes, als auch für Objekttexturen. Die Texturen nicht zu groß wählen. Mehr als 512 ist nicht nötig, es sei denn es sind Terrain-Texturen für große Flächen. Mipmaps werden den Speicherverbrauch minimieren und für bessere Performance sorgen.
-Von Anfang an überlegen, ob man nicht LODs (Level of Detail) auf Objekten verwenden kann.
Das wird die Performance extrem verbessern. Man kann LODs in der Objekt-Hierarchie schreiben. Sie bleiben auch auf Objekten, wenn man sie kopiert.
-Durch einen Zufall bin ich auf einen weiteren Trick gestossen, der mit den Eigenschaften von Blockable Brushes zusammenhängt. Türen haben diese Blockable-Eigenschaft, man sieht es an den schwarzen Flächen, die dafür sorgen sollen, dass AIs im Spiel nicht durch Türen sehen können. Der Spieler kann es auch nicht. Denn das führt dazu, dass die Objekt-Polys dahinter nicht mehr sichbar sind. Natürlich kann man nicht überall Türen machen, wo man sie nicht haben will.
Aber man kann da tricksen. Und zwar mit Hilfe des tnhscripts „TrigProximity“. Es geht so: erst tnhscripts laden. Man erstellt an einer Stelle in der Map, die man nicht einsehen kann, aber deren Hintergrund man blocken will, eine riesige Tür, z. B. 300x2x60, je nachdem, wie es passtl. Dimensions anpassen. Die Tür wird auf „Translating“ gestellt, Speed etwa 100, so dass sie sofort etwa 200 DU im Boden versinkt und wird mindestens 1-2 DU über dem Terrain platziert (sonst gibt’s unschöne Effekte). Die Tür wird von einem Up/down Switch per ControlDevice angefunkt, den man direkt davor platziert. Script auf dem Schalter: TrigProximity. Design Note: proximity =300. Der Radius kann angepasst werden. Nun Optimize. Diese Maßnahme wird locker mehrere hunderte WR-Cells verbraten, aber es wird sich lohnen.
Geht man nun weit entfernt in den Game-Mode, wird der Blockable-Brush dieser „Tür“ dafür sorgen, dass die Anzahl der Backface-Checks (sichtbare Objekt-Polys) ganz erheblich sinkt. Die FPS wird dafür umso mehr verbessert werden, bis zu 20 in manchen Maps, was eine halbe Welt bedeutet. Kommt man der Stelle mit der Tür/dem Schalter näher, geht die Tür nach unten. Geht man wieder weg, geht die Tür automatisch nach oben. Nur sollte der Spieler von all dem nichts mitbekommen. Dafür muß man sorgen, indem man Größe, Ort und Radius richtig wählt.
-Ein weiterer Punkt: Spare an WR Cells. Jede WR-Cell braucht Ressourcen. Man kann das wunderbar, indem man mit den Time-Werten spielt. Deshalb sind kleinere Airbrushes auch viel besser, weil sie sich zum „sparen“ eignen.
Nehmen wir an, eine Map hat 25000 WR-Cells. Nur mit den Time-Werten kann sicherlich 2000-3000 einsparen.
Was man auf keinen Fall tun sollte
-Ganz verboten sind (große) Texturen des Formats png und tga. Insbesondere auf SFX-Effekten und Coronas. Das sind wahre Performance-Killer. Auch schlecht sind Objekte mit eingeschaltetem Tweq-Models. Zum einen kann man keine LODs auf solche Objekte legen, zum anderen brauchen sie von Haus aus viele Ressourcen. Z. B. Fackeln haben sowas. Fackeln kann man auch mit nur einem Objekt machen oder zumindest so verstecken, dass sie nicht weithin sichtbar sind.
-Viele sichtbare Dodecahedrons auf einem Haufen sollte man vermeiden. Die haben zuweilen den kuriosen Effekt, dass die FPS hoch bleibt, das Spiel dennoch ruckelt.
Wenn das Kind schon in den Brunnen gefallen ist, kann man immer noch etwas verbessern
-LODs verwenden (meist viel Arbeit)
-dds/Mipmaps, möglichst klein (eher wenig Arbeit, wenn man einen Batch-Konverter verwendet)
-Türen/TrigProximity-Tricks wie oben beschrieben (ganz wenig Arbeit). Nachteil: verbraucht hunderte WR-Cells und verhunzt womöglich das Licht an der Stelle.
-WR-Cells und Objekt-Polys sparen (viel Arbeit)
-Optimieren mit der Schattenqualität, die man will. Wichtig: Mit Objektschatten optimieren
-Am Ende die Pathfinding berechnen (run pathfind.cmd).
Addendum
-dds mit mipmaps kann man mit einer Vielzahl von Programmen erzeugen, z. B. Paint.net, Photoshop oderGimp mit dds-Plugin, usw. Es gibt sogar Batch-Konverter von Nvidia und AMD und einige andere. Damit geht’s sehr schnell.
-LODs in DromEd: Add—Shape--Model LOD