Wie gesagt das wachsen eines Speicherlecks hängt damit zusammen welcher Bereich eines Landclassfiles gerade aktiv ist.

Weiterhin wieviele fehlende Texturen in diesem aktiven Bereich geladen werden müssen. Hätte man ein 300km x 300km großen Bereich in dem nur eine LC Nummer aktiv ist dann werden nur maximal 7 Texturen benötigt. Das bedeutet im günstigsten Fall (ganz vereinfachtes Beispiel ich will es nicht kompliziert machen) nur eine Speicherlast durch 7 Texturen. Da läuft der Speicher extrem langsam voll. Man wird es nicht bemerken.

Weiterhin hängt es mit den erreichten Frames zusammen. Sind die Frames hoch werden auch die Texturen häufiger neu aufgefrischt (siehe Thematik unscharfe Bodentexturen und schärfere Texturen bei Framevorgabe unendlich)

Werden die 7 Texturen in unserem Beispiel öfter aufgefrischt dann wird bei jedem Auffrischungsvorgang eine neue Speicherlast erzeugt.


Hat ein LC File extrem hohe Landclass und damit auch Texturvielfalt dann erzeugt jede der vielen Texturen eine Speicherlast.


Da die AROE nur wenig LC Informationen innerhalb der Landmasse liefert, tritt bei Inlandsflügen das Speicherleck kaum in Erscheinung.

Fliegt man aber im Küstenbereich zum Beispiel nach Mallorca oder ähnliches dann tritt es schon stärker auf.

Wer dann noch hohe Frameraten hat bei dem verstärkt sich das ganze noch mal.

Auch hängt es davon ab in welchem Bereich die AROE wieviel Landmasse nachliefern musste um Gewässerprobleme zu beseitigen.

Es gibt also regional unterschiedlich stark anwachsende Speicherprobleme.


Wie man sieht ist im FS alles nicht so einfach.

Ohne Lutz hätte ich der AROE auch kein Speicherleck zugeschrieben.

Hallo Zusammen
Auch ich möchte mich auf diesem Wege nochmals öffentlich bei Joachim bedanken,denn es ist nicht selbstverständlich, soviel Zeit in ein Problem des Anderen zu investieren (ich weiß wovon ich spreche).Also nochmals herzlichen Dank Joachim und hoffentlich macht unser Beispiel Schule.

Servus Hubert

Zeitlich war das nicht so schlimm. Klar es gab einiges an Techniken zu erklären um zu Ergebnissen zu kommen. Aber im Großen und ganzen war es nicht so schlimm, da ich vieles aus der Dok entnehmen konnte. Leider habe ich dort wegen anderer Gründe schon seit Wochen nicht mehr dran gearbeitet.

Schlimmer war die Zeitverschwendung die wir aus den anderen Dir bekannten Gründen hatten.

Ohne dieses ich nenne es nicht beim Namen (ist nicht böse gemeint) wären wir sehr viel früher zu einem Ergebnis gekommen.

Da hast Du Recht

Hallo Joachim,

tolle Dokumentation und Recherche von Dir (wie immer :)).

Auch wenn ich die ARoE selber nicht habe (ich warte lieber auf Ultimate Terrain Europe) so wird das sicher vielen hier weiterhelfen.


Viele Grüße,
Michael Grüterich


http://www.grueterich-software.de/avatar.jpg

Mus ich noch mal kurz aufgreifen. Warum es schwankt hatte ich ja schon geschrieben. Ich denke Lutz hat nichts dagegen wenn ich zwei Bilder aus unserem Mail Verkehr verwende.

Das erste Bild zeigt die Speicherlast des Fluges in GByte per handschriftlicher Zahlen eingetragen.

Lutz sein Flug ging von München nach Mallorca wie man sehen kann. Fängt bei 960MB an und endet bei über 1,6GB.

Mallorca ist aber kein extrem langer Flug. Man kann sich ausmalen wo das endet wenn man zurück fliegt. Oder einen PC hat der sehr hohe Frames liefert.

Der Zustand der Default AROE als Screenshot

Hier wie es aussieht wenn man den Fehler der AROE beseitigt. Wir befinden uns beim gezeigten Bild bereits kurz vor der Landebahn auf Mallorca. (Lutz seine Bilder enthielten zusätzlich noch die Screenshots aus dem FS wo er sich gerade befand, dass kann man sich hier schenken)

Wir sehen wir liegen bei knapp 1GB. Wenn man bedenkt das der Flug bei 960MB begonnen wurde dann ist das nicht viel zusätzliche Speicherlast. Diese Speicherlast ist normal, da ja während des Fluges ständig neue Scenerydaten von z.B Addons dazukommen. Nicht alles fliegt aus dem Speicher wieder raus.

Wir müssen uns daran erinnern, dass mit dem AROE Fehler die Speicherlast bei exakt dem selben Flug um ca. 600MB höher lag.

Nicht unerheblich wie ich finde.


Lutz verbraucht mit korrigierten Fehler über ein Drittel weniger Speicher.

Wie gesagt umso höhere Frames ein PC erreicht, umso schneller kann das Speicherleck wachsen. Bei einem anderen wäre es ev. schon auf 2GB oder mehr angestiegen. Bei einem lahmen PC ev. nur auf 1,3GB.

Der Screenshot nach Bereinigung

@JOBIA: Eigentlich fehlt unter Deinen Artikeln nur noch ein

Q. E. D.

:D

Gratulation und vielen Dank!

Eine super Leistung sich so hinter eine Sache zu klemmen um das Problem zu lösen.
Aber, sollte man dass normalerweise nicht vom Hersteller erwarten??



Gruß


Olli

Tja, so sollte es eigentlich sein. Ich weiß das aus eigener Erfahrung am besten, da ich von Beruf Softwareentwickler bin und solche Sachen (Fehlersuche) zu meiner täglichen Alltagsarbeit gehören. Keine Software ist fehlerfrei (wer das behauptet, lügt), auch nicht die, die ich entwickele. Aber ich erwarte auch nicht von den Anwendern meiner Software, dass sie die Fehler suchen und Lösungen anbieten. Das ist mein Job, dafür werde ich bezahlt.