Warnung: Use of undefined constant MYSQL_NUM - assumed 'MYSQL_NUM' (this will throw an Error in a future version of PHP) in ..../includes/init.php (Zeile 156)

Warnung: Use of undefined constant MYSQL_ASSOC - assumed 'MYSQL_ASSOC' (this will throw an Error in a future version of PHP) in ..../includes/init.php (Zeile 156)

Warnung: Use of undefined constant MYSQL_BOTH - assumed 'MYSQL_BOTH' (this will throw an Error in a future version of PHP) in ..../includes/init.php (Zeile 156)

Warnung: Use of undefined constant VB_FRAMEWORK - assumed 'VB_FRAMEWORK' (this will throw an Error in a future version of PHP) in ..../includes/functions.php (Zeile 8101)

Warnung: Use of undefined constant archive_postsperpage - assumed 'archive_postsperpage' (this will throw an Error in a future version of PHP) in ..../archive/index.php (Zeile 456)
X-Plane10 vs X-Plane9 [Archiv] - X-Plane Schweiz

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : X-Plane10 vs X-Plane9



Dietmar
15.12.2011, 10:53
Mit X-Plane10 habe ich in meiner Region, Deutschland West, Airport Düsseldorf ein Problem.
X-Plane 10 verabschiedet sich!
Warum?

Ich versuche das heraus zu bekommen und glaube folgendes festgestellt zu haben:
Ich habe sehr, sehr viele konvertierte Szenerien - und das ist sicherlich ein Grund, denn
---> XP10 schaufelt 9 Kacheln 1°x1° in den Speicher, beim XP9 waren es 6 Kacheln.
Stelle ich mich auf EDDL, dann ist der südöstlichste Bereich bei Rüdesheim 49°N 7°E, der nordwestlichste Bereich liegt bei Ijsselstein (NL) 51°N 5°E. Male ich mir das auf, sind das 9 Kacheln.
XP10 schaufelt also schon mal 33% mehr Szenerien in den Speicher!
Hinzu kommt, dass die Landscapetexturen von XP10 nun vielfach auf 2048x2048 Pixel gebracht wurden. Man will ja auch eine bessere Grounddarstellung sehen. Auch das verschlingt Speicherplatz.
Soweit, so gut - oder nicht so gut!

In meinem RAM befinden sich nun 5,23 GB an Daten. Ein 32 bit Programm kann aber nur 3,2 GB verararbeiten.
Das führt dann zu einem Überlaufkonflikt.
Wenn Laminar ihren X-Plane10 auch als 64 bit Programm anbieten würde, dann hätten wir dieses Problem nicht.

Das ich mit meiner Untersuchung irgendwie auf dem richtigen Weg bin, zeigt die Tatsache, dass bei Herausnahme von sehr großen konvertierten Szenerien, die selber wieder Texturen im Format 2048x2048 aufweisen, wie z.Bsp. Weeze, Brüggen oder Köln der X-Plane10 sich anständig verhält und nicht abschmiert.

WoDi
15.12.2011, 13:59
Hast Du die Beta 4 schon geladen? Hier sollen einige Dinge für ältere Szenerien gefixt worden sein. Ob allerdings Deine Erkenntnisse damit auch gemeint sind weiß ich nicht.
Bezüglich des Speichers kann ich Dir sagen, dass der XP10 durchaus mit größeren Speichermengen über 5 GB zurecht kommt. Ich habe das schon selbst erlebt und reime mir das so zusammen, dass zwar der RAM belegt aber nicht adressenmäßig angesprochen wird. Lt. Ben Supnik sollen wohl nur 2,8 GB maximal vom XP10 belegt werden. Hier handelt es sich wohl um vorauseilende Platzreservierung.
Allerdings wird das geschilderte Verhalten nicht mit den großen Landscapetexturen zusammen hängen können, denn die werden ja gleichzeitig mit den Scenerien benötigt.
Eine 64-bit Version wird es vorerst nicht geben, so Ben Supnik.

Gruß
Dieter

Dietmar
15.12.2011, 15:42
Hm,
diese 5,23 GB RAM-Belegung ergeben sich mit der Einstellung "extreme res!" bei "texture resulution" in den "Renderings Options".

Gehe ich da auf die Einstellung ""very high" zurück, dann werden 3,46 GB belegt. Dann klappt das auch mit allen meinen konvertierten Szenerien. Das zeigt mir eigentlich, dass die Größenauflösung schon was mit dem XP10-Verhalten, wie von mir beschrieben, zu tun haben könnte.

Bei der "extremen Texturauflösung" kommt eine Meldung "X-Plane has hit an internal error: bad_alloc (Sim_Main.CCP:683)", was wohl soviel wie "bad allocation" bedeuten kann. CPP steht für C++.

"bad alloc" bedeutet demnach "schlechte (falsche) Zuteilung. Das bezieht sich wohl auf den Speicher.

In der "crash.log" steht: Unhandeled exeption: EXEPTION_ACCESS_VIOLATION (C0000005)
Also eine nichtbehandelbare Ausnahme " Ausnahme_Zugangs_Verletzung bei Adresse C0000005 hex"

Also rechnen wir mal. Adressierbar sind bei einem 32 bit Programm:
(2^31 = 2 147 483 648) + (2^30 = 1 073 741 824) = 3 221 225 472 Das ist der höchste adressierbare Wert.
C0000005 hex = 3 221 225 477 dez Dieser Wer ist um 5 zu hoch, damit crasht XP10 als 32 bit Programm.

Dieser Wert 2,8 GB, von dem Ben Supnik spricht, beziehen sich wohl auf XP10 ohne zusätzliche Szenerien.

Allerdings sieht XP10, mit einer um eine Stufe niedriger eingestellten Texturauflösung auch noch sehr gut aus.


PS:
Da fällt mir noch ein, dass XP10, die Demo Beta3 mit den Global Scenery - DSF's der Version 9 einwandfrei lief. Diese Texturen sind wesentlich kleiner, ein weiterer Hinweis, dass eine Aufblähung der Texturgrösse doch etwas mit einem Speicherüberlauf (32 bit-Programm) zu tun haben kann.

WoDi
15.12.2011, 18:34
Ben Supnik meinte die maximal von der EXE belegte Größe. Tatsächlich lag die Demo-EXE immer unter 1 GB. Also auch weniger als die XP9-EXE.

Gruß
Dieter

WoDi
16.12.2011, 13:37
Dies hier http://www.x-plane.com/blog/2011/12/bad-alex-bad-the-road-map-for-memory/ ist in den Zusammenhang sicher von Interesse.

Gruß
Dieter

Dietmar
16.12.2011, 19:20
Das ist ja auch mein Gerede, die ganze Zeit. Es gibt einen Adressenüberlauf!
Habe ich in Post #3 berechnet.
Dabei spielt es keine Rolle, wo dieser overflow auftritt, ob im virtual address space oder im physikalischem RAM.

Ben schreibt, dass auf längere Sicht nur folgende Abhilfe das Problem wohl richtig lösen wird:

"The long term solution is clear – we need to migrate X-Plane to 64 bits. This is not going to be particularly easy or fun."

Weiterhin schreibt er:

"Turn down rendering settings. The major ones are: airport detail (set to default), forests (set to something moderate if you are using autogen too), and texture res (first run with compressed textures). Don’t use 4x SSAA when in HDR mode – use FXAA instead."

Also hat die Größe der Texturen in ihrer Gesamtheit doch einen Einfluß.

Sag ich doch!