Okay, ich bräuchte ein paar Überblicksinfos über die Zusammenhänge zwischen Nexusgröße (wo befindet sich der Nexus: Grafikspeicher, Ram oder in der Auslagerungsdatei), was speichert die Engine im RAM und was in der Auslagerungsdatei?

Wie kann man allzugroße Auslagerungsdateien vermeiden?
Wie kann man die Speichernutzung dahingehend optimieren, dass sich nur immer die Dateien des aktuellen Levels im Speicher (egal ob Nexus, Ram oder Auslagerungsdatei) befinden und wie kann man Daten aus vorherigen Leveln entfernen? (vor allem Terraindaten)

Würde mich über ausführliche, schnelle Antworten freuen. Danke.

Texturen im Grafikspeicher
Nexus im RAM(Auslagerung)

Es befinden sich nur Dateien im RAM/Grafik des aktuell geladenen Levels. Terraindaten bzw. restliche Files werden autom. gelöscht. Große Auslagerungen kann man durch kleinere Levels bzw. schlechtere Qualität vermeiden.

Leider habe ich keine allzu große Ahnung, kann gut möglich sein dass das nicht 100% stimmt.

Herzlichen Dank!

Nun mein Problem ist, dass die Performance im ersten LEvel, das nach Enginestart geladen wird, am besten ist und dann stetig von Level zu level abnimmt, obwohl ich zwischen jeden Levelwechsel extra eine leer WMB datei als LEvel lade um auch wirklich alle bisherigen Daten zu entfernen.

Kann sich das jemand aufgrund von Speicherverwaltungsproblemen erklären?

Also beim Levelwechsel wird grudsätzlich mal alles vom Level ausm Speicher geschmissen... also Terrain, Entites und so Zeug....

Bei Bitmaps/Panels muß man das mit bmap_purge() selber machen, sie können ja über einen Levelwechsel hinweg gültig sein.

Um während einem Level den Speicherverbruach konstant zu halten, sollte man selten benutzte erzeugete Entities mit ent_purge() vor dem entfernen wieder aus dem Videospeicher hauen. Ansonsten gibts noch die Möglichkeit, ein Model mit mehreren Skins in mehrere Models mit je einer Skin zu trennen, falls nicht alle Skins benötigt werden. Bei alten A6 Versionen haut natürlich das ganze Lod Zeug ordentlich auf den Videospeicherverbrauch, da man noch keine Modelskinns sharen kann.

Mit dem Cache geht das leider alles nicht so einfach, da man reservierten Cache nicht so ohne weiteres wieder freigeben kann (weswegen auch "Endlos"welten derzeit nur bedingt mit A6 möglich sind - gibts irgendwo nen Thread wo die genauen Gründe erklärt werden)... da kamen ja zuletzt neue Funktionen dazu, aber ich weiß nicht ob die noch in Beta sind oder nicht. Ganz trivial und völlig frei einsetzbar sind sie zudem auch nicht.

Hier die alten Threads:

http://www.coniserver.net/ubbthreads/sho...true#Post610687
http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/556507/page/3/fpart/1/vc/1

sind beide lesenswert

vielen dank, bringen einiges an licht ins dunkel, aber bieten nicht wirklich eine lösung...

ent_purge() oder das Laden eines leeren Levels vor dem Levelwechsel bringt nichts.

Wenn höhere Levels langsamer sind als niedrige, kann das an der Groesse der Levels selbst liegen. Sie sehen die ursache im F11-Panel.

Danke für die Auskunft.
Jedoch kann die Ursache des Performanceverlustes nicht in den Leveln liegen.
Die Level an sich sind gestestet und optimiert und bringen einzeln eine stabile Leistung.
Lädt man jedoch fünf Level hintereinander, ist die Performance im 5ten Level deutlich schlechter, als wenn dieses Level zuerst geladen werden würde.

Zwischen dem Levelwechsel wird sichergestellt, dass alle nicht benötigten Funktionen beendet sind und auch alles mögliche überflüssige aus dem Speicher entfernt.
Ich kann mir den Performanceverlust einfach nicht erklären.

Sie sollen ihn ja auch nicht erklaeren, sondern erstmal im F11-Panel nachsehen, woran er liegt.

Die Entity-Rendering-Zeit steigt von Level zu Level um 0.5-1.5 Ms an, unabhängig davon ob mehr oder weniger Entities dargestellt werden.

So sieht es bisher auf alle Beta-Rechnern aus. Einer der Tester hat zusätzlich von einer extrem großen Windows-Auslagerungdatei berichtet.