Nexus, Auslagerungsdatei, Grafikspeicher

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.

Ok, dann checken Sie zuallererst die Anzahl der laufenden Funktionen und die der sichtbaren Entities. Erhoeht sich eine davon von Level zu Level, oder bleiben sie gleich? Im ersten Fall steckt ein Bug in Ihrem Levelwechselcode.

Die Zahlen variieren stark, abhängig vom Level, aber ein grundsätzliches Ansteigen ist nicht zu beobachten.
Welche Fehler wäre im Level-Wechsel-Vorgang denkbar?
Level_Load entfernt alle Level-Entities und beendet dadurch alle verknüpfte Funktionen, wenn ich nicht irre, d.h. nach dem aufrufen von Level_Load darf danach kein Objekt mehr aktiv sein?

Denkbar waeren z.B. View oder Sky entities, die mehrfach gerendert werden.

Ich verwende Ent_Morph auf das Sky-Entity-Set um den Himmel an jedes Level anzupassen, kann das etwas ausmachen?

Inwiefern mehrfach gerendert? Wenn eine View-Entity sichtbar ist, wird sie einmal gerendert?
Ich verwende kein dynamisches Erstellen von View/Sky-Entities...

Views die nicht sichtbar sind (visible == off) können die performance auch nicht beeinträchtigen?

EDIT: Allgemein nutze ich ent_morph sehr häufig... wie steht es damit, kann das dazu führen, dass ungenutzte daten im speicher verbleiben?

View Entities werden beim Levelwechsel nicht entfernt.
Wenn du also beim Levelstart View Entities per ent_createlayer() erzeugen würdest, dann könnte dies eine Ursache sein.

ja, leider fehlanzeige!

View Entities werden beim Levelwechsel nicht entfernt.

Frage: ich habe zum Teil statische view entities, die allerdings nur in einem Level zu sehen sind. Ich möchte sie nicht dynamisch erzeugen, allerdings soll das benutzte Model nicht immer im Speicher sein. Dann wäre es doch quasi optimal wenn ich sie mit Dummydaten initialisiere (2x2 Sprite oder so) und im entsprechenden Level mit ent_morph in das entsprechende Model umforme. Dann müsste ich doch quasi um Speicher zu sparen nach dem Level auf invisible setzen, mit ent_purge (entity); aus dem Speicher entfernen und dann wieder mit Dummydaten füttern. Oder?

Das Problem ist dass die view entity ein Avatar eines Models im 3D Space ist. Das eigtl Model wird durch die Definition in der WMB geladen. Da aber der Avatar dasselbe Model ist, würde ich nach dem Levelwechsel die Modeldaten immer noch im Speicher haben und das wären ca. 10 MB im worstcase.

Für den Videospeicher funktioniert das auf jedenfall - ich arbeite auch mit einem "Panel-Pool".
Ich weiß jetzt nur nich genau, wie sich das mit dem Nexus verhält.
Das aktuelle View Entity bleibt natürlich drin (zumindest wenn sie visible ist), aber was mit den zuvor gemorphten Model/Spritedaten im Nexus passiert, kann ich dir jetzt nicht 100%ig sagen... ich meine aber sie werden mit dem Levelwechsel entfernt. Müßte mal wieder einen Blick auf mein Debug Panel werfen, dann kann ichs dir sicher sagen. Hab zuletzt an anderen Problemen rumgedoktort.

Ja, die Morph-Loesung wuerde funktionieren.

Um View Entites aus dem Speicher zu schmeissen gehe ich eigentlich immer wie folgt vor:
* Entity unsichtbar machen
* ent_purge auf dies Entity anwenden

So hab nochmal nachgeschaut. Der Nexus wird natürlich wie erwartet auch bei View Entities beim Levelwechsel geleert. Also visible auf off und dann purgen sollte tun.

"sehr gut, so lob ich mir das"

Danke, kann ich dann gleich mal auf meine Liste schreiben

uff, fehler gefunden!

das problem lag tatsächlich bei den view-entities, aber anders als man meinen könnte.
Vor einiger Zeit hab ich festgestellt, dass man das Laden eines Levels (und das cachen aller nötigen daten) beschleunigen kann, wenn man die daten vorher schon irgendwie in den speicher bringt...
ich hab mir also ein script gebaut, dass vor dem eigentlichen level_load auf basis einer dateiliste alle benötigten dateien lädt... aber wie.. hier ist der haken... ich nehme eine view entity, ent_morph-e die auf die gewünschte datei und führe ein ent_preload aus...
nun, das für jede datei... sprich: alle entitydaten gehen ins view-entity-speicher-nirvana aus denen sie von der engine selbst nie wieder geholt werden...
so würden effektiv sämtliche daten des spiels in den speicher kopiert werden, so lange bis nichts mehr geht und das ganze system crasht.

problem gelöst: dateiliste wird gespeichert und beim laden der nächsten liste zuerst die vorige liste wieder aus dem speicher entfernt..

das problem wurde also aufgrund eines logik-fehlers in meinem script verursacht..