"Highmemfix=1" - Tweak (Grafikfehler beseitigen)

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Nico081 schrieb:

      Hi Hans,

      Falsch, ich hab dann keine vielseitigeren Wolkentexturen. Die von REX sind einfach besser als der Standart- Mist. Mein persöhnliches Empfinden und der Vergleich mit der Realität beim fliegen, lässt mich durchaus die 512er nehmen. Für mich passender als 1024er.

      Gruss Nico



      Aber es gibt doch auch noch 2048er und 4096er... letztere sehen einfach nur lecker aus und kosten bei mir nicht merkbar Frames.

      Bezüglich Ati Tray Tools hast dann wohl was falsches gelesen, das funktioniert problemlos unter W7 / x64. nhancer ist gegen Tray Tools kompliziert, wirklich.

      @ Pegasus: 2x AA, das reicht mir völlig aus, kaum noch Aliasing zu sehen. Wem das nicht reicht der sollte sich mal Downsampling anschauen.

      Wenn man DX10 verwendet sollte man sich halt nicht so Krämpfe wie Woai oder Aerosoft Airports draufmachen, sondern bessere Addons die davon profitieren.
      Dafür hab ich dann auch das doppelt bis dreifache an Frames und kann deshalb die Settings bis zum maximum anheben.


      Ich finds halt bisschen unfair wenn ein mit nhancer gemoddeter nvidia FSX mit Standard ATi FSX vergleichen wird, weil wenn die Texturen bei dir bei der ATi nicht so scharf waren ist das definitiv Einstellungssache.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Hans300 ()

    • Hello again Hans,

      Hans300 schrieb:

      Aber es gibt doch auch noch 2048er und 4096er... letztere sehen einfach nur lecker aus und kosten bei mir nicht merkbar Frames.


      hm, wäre mal ne Möglichkeit das auszuprobieren, hatte bisher nur 1024 gegen 512 verglichen. Höher aufgelöst hatte ich noch garnicht eingestellt weil ich vermutet hatte anhand unterschiedlicher screenshots, dass höhere Auflösungen zu "gemalt" und harte Konturübergänge haben. Ich probiers mal aus.

      Hans300 schrieb:

      Bezüglich Ati Tray Tools hast dann wohl was falsches gelesen, das funktioniert problemlos unter W7 / x64. nhancer ist gegen Tray Tools kompliziert, wirklich.


      Klingt gut, bist du online- flieger auf IVAO? Dann lass uns mal in TS bequatschen wie das tool zu handlen ist wenn du mich da unterstützen würdest, nur mal grob natürlich.

      Hans300 schrieb:

      Ich finds halt bisschen unfair wenn ein mit nhancer gemoddeter nvidia FSX mit Standard ATi FSX vergleichen wird, weil wenn die Texturen bei dir bei der ATi nicht so scharf waren ist das definitiv Einstellungssache.


      Du es sind einfach tatsachen, die ich mit nHancer und dem ATI Catalyst Center gemacht habe. Alles mal ausprobiert und alle möglichen Settings getestet. Und es ist nicht nur bei 275GTX vs. HD5850, sondern auch 285GTX vs. HD5870 fakt das die Bodentexturen viel grober aufgelöst werden. Ich konnte beim reinzoomen sogar die Grösse einzelner Texturmuster am Bildschirm ausmessen. Interessant wäre wenn du im direkten Vergleich zwischen NVIDIA und ATI andere Ergebnisse erzielt hast, würde mich sogar freuen wenns so wäre ;)
      Ok wir müssen unbedingt mal quatschen wenn du unter Verwendung von Tray tools deine ATI so fein und scharf hast wie ne NVIDIA, diese Settings muss ich unter DX9 unbedingt mal testen :thumbsup:
    • B777-200 schrieb:

      Da bis DirectX 9 einschließlich dem virtuellen Arbeitsspeicher eine Kopie der Videospeicherressourcen zugeordnet wird und eine Anwendung jetzt versucht eine so grosse Menge an Videospeicher ( z.B. 1GB Grafikkarte) zu nutzen, wird dementsprechend ein sehr grosser Teil des virtuellen Adressraumes für genannte Kopie benötigt, ist dann irgendwann der Punkt erreicht, wo die 4 GB an adressierbarem Speicher nicht mehr ausreichen.
      Diese Kopie des VRAMS wird genutzt, damit beim Umschalten von ALT+TAB, bzw. ALT+ENTER in diesem Moment geht ja der Inhalt des VRAMS verloren[ die Anzeige schnell wieder hergestellt wird (was auch das Auftreten des Fehlers beim switchen zwischen Fenster-u. Vollbildmodus erklärt, da sieht man das der FSX eben diese Kopie des VRAMS in den virtuellen Adressraum verlagert).

      Bei DX10 ist das von MS geändert worden, was auch erklärt warum dieses Phänomen in der DX10 Vorschau des FSX nicht passiert.



      servus,

      hast du für die fett gedruckten Sätze vielleicht eine anschauliche Quelle? Hier geht es mir eigentlich nur um den Bezug auf DX10.

      Übrigens bin ich der Ansicht, dass der Inhalt des VRAMs nicht verloren geht (Speichernutzung bleibt ident, nicht nur wenn du auf den Desktop gehst sondern auch beim switch zwischen Voll und Fenstermodus) , das bild muss nur neu gerendert werden!? (Möge mich ein 3D Guru eines besseren belehren, messen lässt sich der drop des framepuffers jedenfalls mit mir zur Verfügung stehenden Mitteln nicht)

      Btw. nach dem Neuaufsetzen habe ich alle meine FSDT Airports bei Tag und bei Nacht wieder und was das Größte ist,

      ich kann jetzt mit Alt-Enter, Alt+tab [!!!!] und zwischen Vollbild und Fenstermodus switchen wie ich es mir beliebt, nach 10 Stunden Flug nach Landung genauso wie, auf der Kurzstrecke, was mir bisher mit PMDG verwehrt blieb und stets mit black screen quittiert wurde. Somit kann ich direkt auftanken und weiterfliegen ohne den FS zu quittieren.

      Unter DX9 und feinen 4096er REX Wolkentexturen, versteht sich.

      kein Austausch irgendeiner dll, keine Reduzierung der Audioqualität, diesmal habe ich ein paar Dinge anders gemacht, mehr dazu nach ein paar weiteren Testflights

      Es gilt zuerst noch zu eruieren, ob dieses Maßnahmenpaket alleine dafür verantwortlich ist oder ob ich das "Bildwechsel" Phänomen unter weiterer Last erneut auslösen kann.

      Dass das switchen bei DX9 bisher solche Probleme gemacht hat, halte ich nach bisherigen Erkenntnissen für einen DX9 Kompatibilitäts bug und nicht für ein "feature" von DX10

      NickN schwört ja dass das blackscreenphänomen unter XP64@Sp2c nicht auftritt, das war Ausgangspunkt dafür mich bisher nicht zufrieden zugeben. (und nein ich hab die Plattform nicht gewechselt, ist weiterhin w7 64bit :D )
    • hallo alle die sich hier mit nützlichem input einbringen - da ich mein system hardwareseitig nochmal etwas aufgewertet habe (raid0 mit controller und 2 wd velis) und den fsx nun komplett neu installieren werden würden mich die zb. von hans300 angesprochenen settings des ati tray tools (habe ne 5850) oder neuen einstellungen nah neuinstallation von commander-aut sehr interessieren ..........

      bitte dated mich mal ab ....

      danke und gruss rick
    • Commander-AUT schrieb:

      servus,

      hast du für die fett gedruckten Sätze vielleicht eine anschauliche Quelle? Hier geht es mir eigentlich nur um den Bezug auf DX10.

      Übrigens bin ich der Ansicht, dass der Inhalt des VRAMs nicht verloren geht (Speichernutzung bleibt ident, nicht nur wenn du auf den Desktop gehst sondern auch beim switch zwischen Voll und Fenstermodus) , das bild muss nur neu gerendert werden!? (Möge mich ein 3D Guru eines besseren belehren, messen lässt sich der drop des framepuffers jedenfalls mit mir zur Verfügung stehenden Mitteln nichtD )


      Hallo Commander,

      die Quelle war Microsoft, da habe ich lesen können, daß es seit DX10 (WDDM1.1) geändert wurde.
      Dank der Einführung von DirectX 10 und des Windows-Anzeigetreibermodells (WDDM – Windows Display Driver Model) in Windows Vista müssen Anwendungen keine Kopien ihrer Ressourcen im Systemspeicher beibehalten. Stattdessen wird durch den Videospeichermanager sichergestellt, dass die Inhalte aller Videospeicherzuordnungen über Anzeigeübergänge hinweg beibehalten werden. Aus Kompatibilitätsgründen emuliert Windows Vista "Gerät verloren" (device lost) für DirectX-Versionen vor DirectX 10, um sicherzustellen, dass es keine für die Anwendung sichtbaren Änderungen des API-Verhaltens gibt.


      und weiters:

      Um Videospeicher zu virtualisieren, weist der Videospeichermanager in Windows Vista jeder Videospeicherressource einen virtuellen Adressbereich zu. Dieser Bereich entspricht vom Konzept her der Kopie, die von einer Anwendung erstellt werden könnte. Der Videospeichermanager verwaltet den Prozess jedoch effizienter als dies durch die Anwendung erfolgen würde. Der Videospeichermanager verwendet den virtuellen Adressbereich, um Übergänge oder Overcommitment (Vergabe von mehr Speicher als vorhanden) von Videospeicher zu behandeln. Der virtuelle Adressbereich wird jedoch in Systemen mit ausreichendem Videospeicher in der Regel nicht verwendet. Wenn dieser virtuelle Adressbereich nicht verwendet wird, erfolgt auch keine Zuordnung von physischem Speicher. Dagegen ist für die Kopie, die bei dem älteren Treibermodell im Systemspeicher verwaltet wird, garantiert in vollem Umfang Arbeitsspeicher reserviert.

      Wenn von einer Anwendung im Arbeitsspeicher die Kopie ihrer Videoressourcen erstellt wird, oder wenn DirectX 9 oder eine frühere Version verwendet wird, enthält der virtuelle Adressraum den virtualisierten Bereich des WDDM-Videospeichermanagers und die von der Anwendung erstellte Kopie. Anwendungen, die Grafik-APIs vor DirectX 10 verwenden und auf GPUs zugreifen, die einen großen Videospeicher haben, können ihren virtuellen Adressraum leicht erschöpfen.


      Jetzt bin ich natürlich gespannt, wie deine weiteren Tests verlaufen sind.
      Was kann man bei der Installation denn "anders" machen?
      Ich hatte die Benutzerkontensteuerung und Aero ausgeschaltet, sämtliche Programme als Admin installiert, ausserdem liegt der FSX auf einer anderen Partition, also nicht auf dem Standardpfad C:\programme (x86), daran kann es ja nicht liegen.
      Viele Grüsse Hannes

      Ivy i7-3770k @ 5,2 GHz, 24/7, Asus Maximus V Gene, 8 GB GSkill Trident X 2666 MHz, 2 x EVGA Titan X, OCZ IBIS 240 GB/OCZ IBIS 360 GB,Corsair H100, Corsair HX 1000, Cooler Master HAF-X, Dell Ultra Sharp 3008WFP 2560x1600 @ 8x SGSSAA
      Fliegst du schon P3D oder ruckeltst du etwa immer noch??
    • B777-200 schrieb:

      Commander-AUT schrieb:

      servus,

      hast du für die fett gedruckten Sätze vielleicht eine anschauliche Quelle? Hier geht es mir eigentlich nur um den Bezug auf DX10.

      Übrigens bin ich der Ansicht, dass der Inhalt des VRAMs nicht verloren geht (Speichernutzung bleibt ident, nicht nur wenn du auf den Desktop gehst sondern auch beim switch zwischen Voll und Fenstermodus) , das bild muss nur neu gerendert werden!? (Möge mich ein 3D Guru eines besseren belehren, messen lässt sich der drop des framepuffers jedenfalls mit mir zur Verfügung stehenden Mitteln nichtD )


      Hallo Commander,

      die Quelle war Microsoft, da habe ich lesen können, daß es seit DX10 (WDDM1.1) geändert wurde.
      Dank der Einführung von DirectX 10 und des Windows-Anzeigetreibermodells (WDDM – Windows Display Driver Model) in Windows Vista müssen Anwendungen keine Kopien ihrer Ressourcen im Systemspeicher beibehalten. Stattdessen wird durch den Videospeichermanager sichergestellt, dass die Inhalte aller Videospeicherzuordnungen über Anzeigeübergänge hinweg beibehalten werden. Aus Kompatibilitätsgründen emuliert Windows Vista "Gerät verloren" (device lost) für DirectX-Versionen vor DirectX 10, um sicherzustellen, dass es keine für die Anwendung sichtbaren Änderungen des API-Verhaltens gibt.


      und weiters:

      Um Videospeicher zu virtualisieren, weist der Videospeichermanager in Windows Vista jeder Videospeicherressource einen virtuellen Adressbereich zu. Dieser Bereich entspricht vom Konzept her der Kopie, die von einer Anwendung erstellt werden könnte. Der Videospeichermanager verwaltet den Prozess jedoch effizienter als dies durch die Anwendung erfolgen würde. Der Videospeichermanager verwendet den virtuellen Adressbereich, um Übergänge oder Overcommitment (Vergabe von mehr Speicher als vorhanden) von Videospeicher zu behandeln. Der virtuelle Adressbereich wird jedoch in Systemen mit ausreichendem Videospeicher in der Regel nicht verwendet. Wenn dieser virtuelle Adressbereich nicht verwendet wird, erfolgt auch keine Zuordnung von physischem Speicher. Dagegen ist für die Kopie, die bei dem älteren Treibermodell im Systemspeicher verwaltet wird, garantiert in vollem Umfang Arbeitsspeicher reserviert.

      Wenn von einer Anwendung im Arbeitsspeicher die Kopie ihrer Videoressourcen erstellt wird, oder wenn DirectX 9 oder eine frühere Version verwendet wird, enthält der virtuelle Adressraum den virtualisierten Bereich des WDDM-Videospeichermanagers und die von der Anwendung erstellte Kopie. Anwendungen, die Grafik-APIs vor DirectX 10 verwenden und auf GPUs zugreifen, die einen großen Videospeicher haben, können ihren virtuellen Adressraum leicht erschöpfen.


      Jetzt bin ich natürlich gespannt, wie deine weiteren Tests verlaufen sind.
      Was kann man bei der Installation denn "anders" machen?
      Ich hatte die Benutzerkontensteuerung und Aero ausgeschaltet, sämtliche Programme als Admin installiert, ausserdem liegt der FSX auf einer anderen Partition, also nicht auf dem Standardpfad C:\programme (x86), daran kann es ja nicht liegen.


      servus,

      danke dir für die Zitate. Dank dieser, hab ich die Originalartikel inzwischen auch. (werde ich umgehend verinnerlichen)

      Absatz 1 bestätigt aber meinen Einwand betreffend VRAM Persistenz unter DX9.

      Jetzt bin ich natürlich gespannt, wie deine weiteren Tests verlaufen sind.


      Ich darf dich noch bis spätestens Morgen Abend um Geduld ersuchen. Ich muss noch 2 weitere Flüge machen. (Vielleicht geht es sich heute Nacht noch aus, mal sehen)

      Ziel meiner Testreihe ist nachzuvollziehen warum die Probleme für Entwickler nicht nachvollziehbar sind und dahingehend sind die bisherigen Tests absolut positiv verlaufen. Wenn die letzten 2 Flüge wie geplant schiefgehen, dann kann ich die Erkenntnisse veröffentlichen.
      stay tuned :D
    • Also bei mir läuft es jetzt besser.

      Ich weiß auch nicht warum aber ich habe keine Bildausfälle mehr und sogar bei Sichtwechseln wird die Grafik noch korrekt dargestellt. Bin allerdings auch noch nicht beim Sonnenauf- oder Untergang angeflogen. Evt. liegt es daran das ich LOD 4.0000000 die Auflösung am Boden ist zwar nicht perfekt aber ich fliege ja auch große Maschinen da hat das keine großen Auswirkungen.

      Mir ist allerdings jetzt was aufgefallen und ich weiß nicht wie ich das deuten soll bzw. ob das mit diesem Thema was zu tun hat. Gary hatte in der Richtung ja auch schon mal was erwähnt gehabt. Worauf ich hinaus möchte... , bei langen Flügen, ich hatte jetzt einen nach Sao Paulo, Accra, Punta Cana und New York, ist mir der Flusi einfach nach ein paar Stunden stehen geblieben. Es gibt keine Fehlermeldung wie z.B. schwerwiegender Fehler o.ä. . Der FSX reagiert ganz einfach nicht mehr und ich muss ihn über die Taskleiste beenden:(.

      Kann das mit einen der Einstellungen hier zu tun haben, bzw. Gary wie hast du das in den Griff bekommen? Kurz fliegen, sprich 2std. geht aber danach wird das kribbelig.
      Stingrey, Mitglied im FlightXPress Forum seit Sep 2007.
    • Hallo Steven

      Du hast also die Grafikprobleme in den Griff bekommen, indem Du den Lod kräftig reduziert hast... Damit kann (und will) ich mich einfach nicht anfreunden. Allerdings, ich flieg mit meinen Propellern tiefer als Du... :D
      Ööhm, zu Deinem neuen Problem mit dem nicht mehr reagieren: Dazu soll ich mal was erwähnt haben?! Du meinst einen Beitrag im ersten Thread? Was ich damals hatte, war ein defekter RAM-Riegel. Dies hat dazu geführt, dass der Flusi einfach hängen geblieben ist... Ich hab den PC zum Händler gebracht (war erst 2Monate alt), der hat das Untersucht. Wie er darauf gekommen ist, weiss ich leider auch nicht. Eigentlich habe ich ihn dorthin gebracht, weil ich den RAM nicht bis zu seiner 1600er Frequenz schrauben konnte. Er hat die Riegel getauscht, kann trotzdem nur bis 1200MHz takten aber das Hängenbleiben ist verschwunden. Ziemlich undurchsichtig das Ganze. Naja, war jetzt wohl nicht sehr hilfreich für Dich... Aber kontrollier mal die RAMs (oder lass kontrollieren, Deiner ist ja scheinbar auch noch nicht alt), vielleicht ist ja auch dort Dein Fehler dass Du nicht über Lod 4.0 rauskommst.

      Update von mir:
      Ich hab das komplette System neu installiert. FSDT hab ich vorerst weggelassen, ist mir zu nervenaufreibend...
      Flughafenverkehr hab ich ausgesschaltet!
      Meine Testflüge sind dafür aber noch belastender geworden:
      Im Morgengrauen bei Regen (!) ein kurzer Flug mit der Cheyenne von CH Kleinflugpl. Samedan über CHPro nach Free-Z Zürich. Hat dank weglassen des Verkehrs funktioniert! Keine bescheuerten fehlerhaften AI-Flieger! Hat vorher nicht funktioniert...
      Ebenfalls bei Sonnenaufgang bei Regen ein Cheyenne-Flug von G Airfields Bremerhaven über VFR-G nach GA Hamburg. Leider hat es da nicht mehr gereicht. Wieder unvollständige AI-Flieger ;(

      Momentane Einstellungen:
      Lod_Radius=7.5, (mit den schönen Szenerien will ich einfach nicht reduzieren...)
      TEXTURE_BANDWIDTH_MULT=2000, (1Mio hat übrigens doch keine verbesserte Wirkung! = Placebo...)
      SmallPartRejectRadius=1 (ist jetzt wieder Standard, da bei "4" Flugzeuge, die meinen Weg in der Luft kreuzen nicht angezeigt werden) (Allerdings ist das jetzt natürlich wieder ein höherer Wert, der gegenüber vorher wieder mehr Ressourcen frisst...)
      Also, so überraschend ist das wohl nicht, dass die Fehler noch da sind, denn ich hab zwar den Flughafenverkehr weggelassen, dafür den SmallPartDingsbums wieder auf 1, und die Flüge sind dank Dämmerung (Lichter) und Regen noch anspruchsvoller geworden...
      Da ich früher schonmal festgestellt habe, dass mit einem Traffic-Add-On die AI-Flieger "bleiben", werde ich mir nochmal MyTraffic2010 besorgen und nochmal testen. Mal sehen, welche neuen Probleme das wieder bringt... :D

      Aber zuerst bin ich schon sehr gespannt, was "Commander-AUT" da zu Tage führt...!!! :thumbsup:

      Alles Gute!
      Gerald
      Intel i7 3930K@4.5GHz; Asus Rampage IV Extreme; 16GB; GTX980UC NVSurround 3xFullHD 40`LED 5760x1080; SSD 240GB Windows; OCZ RevoDrive3 PCI-SSD 240GB FSX; Brunner FFYoke + FFPedals; 3x Saitek Panels;
      Windows10 Pro 64bit FSX mit allen Add-Ons für CH+DE
    • Captain Gary schrieb:

      Damit kann (und will) ich mich einfach nicht anfreunden.


      Hallo Gary,

      ich verfolg deinen Thread schon 'ne ganze Weile mit und wollte eigentlich noch folgendes loswerden, auch wenn es für dich wohl eher ernüchternd klingen mag :) Der von dir genannte Satz ist eigentlich das ursprüngliche Problem ;) Du musst den Tatsachen ins Auge sehen. Die eierlegende Wollmilchsau gibt's nicht. Man muss Kompromisse eingehen. Ich würde auch am Liebsten mit LOD 9.5 fliegen wollen, Bloom eingeschaltet, Wasser auf Max 2.x und alle Regler ziemlich weit oben. Es wird nicht funktionieren. Das liegt einfach in der Engine des FSX. Das einzigste was du versuchen kannst --> im DX10-Modus zu fliegen. Dann wirst du keine Grafikprobleme in dieser Art mehr finden, und auch nicht mehr mit Bufferpools rumspielen und der ganze Kram. Da wird alles "flüssiger" laufen, allerdings musst du auch dort wieder Abstriche ziehen. Die Performance bei DX10 passt, da hab ich absolut null Grafikprobleme und die FPS sind auch super. Allerdings kann ich mich mit dem schlechten Anti-Aliasing und dem Flimmern nicht abgeben, denn das AA was meine GraKa (derzeit nVidia GTX-295) zaubert, ist unter aller Sau. Ich schätze das ist 2x Multisampling, das billigste vom Billigsten quasi :S

      Ihr solltet euch eben im Klaren sein, dass sobald die Bufferpools modifiziert auf kleine Werte modifiziert werden, Grafikprobleme regelrecht herausgefordert werden (früher oder später). Wenn ihr schon mit Bufferpools = 0 oder 4000 fliegt, dann solltet ihr "meiner Meinung" nach unbedingt den FSX-internen Framelimiter einschalten. Damit fahre ich am besten und die Frames sind akzeptabel. Allerdings muss man trotzdem irgendwo Grafikbelastende Sachen runterschrauben, wenn noch Abstürze vorhanden sind. Es ist ein unendliches Dilemma, ich geb's zu :)

      Teu-Teu-Teu,
      Pegasus.
      Intel i7-920 @4 GHz, 12GB RAM OCZ Platinum @1.646MHz,Sapphire HD-5870 Vapor-X, 30" Dell @2560x1600, TrackIR 5, Win7 64bit
      PEGASUS' Bilder-Thread
    • Pegasus, könntest du vielleicht mal DX10 und AA einschalten, ein Flugzeug nehmen, dich nach Princess Juliana stellen und ein Screenshot machen?
      Dann könnte ich mal vergleichen wie dein AA in Vergleich zu meinem aussieht, vielleicht gibts ja einen Unterschied. Hatte ja in diesem Thread bereits einige Bilder gepostet.

      Klar, 4x AA sieht schöner aus, aber ich finde es völlig ok. Und ich bin eigl. sehr AA verwöhnt, spiele viele Spiele nur mit 8x AA.

      Ich denke halt auch am besten ist es das etwas schlechtere AA in kauf zu nehmen aber dafür flüssig, mit Bufferpoolsize 0 und hohem LOD_Radius grafikfehlerfrei fliegen zu können.
    • Ich hab grad einige Screenies geschossen. Dabei habe ich DX10 aktiviert, und im FSX AA und AF aktiviert (da im DX10-Modus der nHancer ja nicht greift). Die restlichen Einstellungen sind eigentlich ziemlich fast alle auf Endanschlag. Klar, auf den Screenshots sieht's gar nicht so schlecht aus, da fällt einem das schwache AA gar nicht grossartig auf. Lediglich im Vorschaufenster sieht man es ganz gut. Aber das Blöde ist, dass einige Sachen (Wasser, entfernte Schiffe, dünne Linien, etc...) stark flimmern, weil eben schlechtes AA verwendet wird. Das nervt mich doch schon ein wenig, weil's nicht so gut aussieht. Leider kommt das auf den Screenshots nicht rüber. Wie auch immer, hier ein paar Screenies...

      PS: Mit meinem St.Maarten stimmt irgendwas nicht. Keine Ahnung warum, ich hab da normalerweise im DX9-Modus schwarze Vierecke. Im DX10-Modus sind diese nicht schwarz, sondern mit dem Microsoft-Logo versehen (?). Ist nur bei TNCM so, keine Ahnung warum. Wenn jemand die Lösung kennt, bitte verraten :)

      Und hier die Pics ...

      Intel i7-920 @4 GHz, 12GB RAM OCZ Platinum @1.646MHz,Sapphire HD-5870 Vapor-X, 30" Dell @2560x1600, TrackIR 5, Win7 64bit
      PEGASUS' Bilder-Thread
    • here we go:

      euer thread kam mir aufgrund meiner Neuinstallation des FSX sehr gelegen. Normalerweise würde ich zuerst den FS aufsetzen, dann alle Szenerien einspielen und zu guter Letzt, den Hangar mit allerlei Schmuckstücken auffüllen. Ich habe hier aber die Gelegenheit beim Schopf gepackt, auf diese Tradition zu verzichten und das Pferd rückwärts zu zäumen, sprich auszuloten, wieviele Addons der FSX mit blütenweißer Weste (ohne fsx.cfg tuning) verträgt , bis dieses Übel, welches Gegenstand dieses Threads ist, wieder aufkommt. Was PMDG auf AVSIM behauptet hat ist kein "Hardwareproblem welches nur auf wenigen Rechnern vorkommt". Das kann jede(r) bekommen, der /die überhaupt addons verwendet.


      Meine Testumgebung: "Setup1"

      FS spezifisch:
      WIN7 Ultimate 64bit (RTM)
      FSX@SP2 (kein Accelerationpack!) Auflösung 1920x1080
      FSX SDK1a (wegen Simconnect)
      REXv2 (aktuell gepatched)
      nhancer 2.5.7
      Nvidia WHQL 186.18 (der 196.21 WHQL, machte keinen Unterschied hinsichtlich meiner Testreihe, auch getestet)
      Ivap 1.98
      FSBUILD
      NAVIGRAPH AIRAC 1002
      PMDG 747X/8i (jeweils auf den Letztstand gepatched)
      PMDG MD11 (auch)
      FSDT: LSGG, LSZH, KJFK, KFLL, KORD, KLAS (jeweils die aktuellste Version)
      FS Global 2008
      MS Visual C++ 2005 x86 Version 8.056336
      MS Visual C++ 2008 x86 Version 9.021022
      MS Visual C++ 2008 x64 Version 9.021022

      sonstiges:
      Norton Ghost 15
      O&O defrag 12 64bit

      Wie man sieht sind gerade mal 1 Addon Mesh, nur FSDT Airports und 2 Aircraft installiert. Anmerkung Echtzeitwetter lieferte bei jedem Flug welches auf einem Client-PC installiert und via "Simconnect" eingespielt wurde. Zwischen allen Flügen wurde der Rechner immer rebootet.

      hardware:

      ASUS P5Q Deluxe (Bios 2301)
      Intel E8600@4Ghz
      WD Velociraptor 300Gb
      4Gb Corsair (2x CM2X2048-8500C5D)
      ASUS ENGT285
      Creative X-FI Elite Pro (am sound wurde nicht geschraubt!)

      FSX Setup: (sorry für Vollbild, dafür keine Werbung;-))











      Unglücklich wäre es gewesen, wenn in dieser 1. Versuchsreihe bereits Texturen verloren gegangen wären, sich Airports nicht aufgebaut oder Blackscreens die Freude getrübt hätten und ich darf vorweg nehmen, dieser Fall ist zum Glück nicht eingetroffen.

      1. Versuchreihe:

      LOWW-LSZH (also ein Standardairport, ein addonairport, jeweils 2 Flüge mit PMDG 747-8i und mit der MD11, alle nachts) 2 Flüge deshalb, weil ich übermütig wurde und neben:
      TEXTURE_MAX_LOAD=1024 (ich sagte ja blütenweiße FSX.cfg) auch
      TEXTURE_MAX_LOAD=4096 testen wollte. Für die Wetterfetischisten nicht unerheblich.

      Ich konnte mit ALT-TAB und ALT-ENTER switchen soviel ich wollte, die FS "Menüzeile" aufrufen, ohne dass die Schrift unsichtbar war.*Herrlich* :P

      2. Versuchsreihe: "long haul"
      LOWW-KFLL (2 Addons Airports, dazwischen Standard Szenerie, nur FSG Mesh und Echtzeitwetter) je ein Flug mit der 747-8i und der MD-11 bei TEXTURE_MAX_LOAD=4096 je ein Flug mit der 747-8i und der MD-11 bei TEXTURE_MAX_LOAD=4096 (no risk ,no fun!)
      KFLL-KLAS (Bedingungen wie oben)

      wieder ohne Befund, alles war möglich, die Airports blieben im Nachtanflug immer ganz, trotz der Abweichung der TEXTURE_MAX_LOAD=4096

      Grundsätzlich würde ich jedem "switcher", der zb mit PMDG unter Vista bzw. WIn7 blackscreens hat empfehlen, folgende Settings auf der FSX.exe durchzuführen:



      Was machen die Einstellungen? [Quelle MS]:

      Visuelle Designs deaktivieren

      "Deaktiviert Designs im Programm. Versuchen Sie es mit dieser Einstellung, wenn Sie Probleme mit den Menüs oder Schaltflächen in der Titelleiste des Programms beobachten."

      Desktopgestaltung

      "Deaktiviert die Transparenz und andere erweiterte Anzeigefunktionen. Wählen Sie diese Einstellung aus, wenn die Fensterbewegung nicht einwandfrei funktioniert oder wenn Sie andere Anzeigeprobleme beobachten."

      Berechtigungsebene

      "Führt das Programm mit Administratorrechten aus. Für einige Programme sind Administratorrechte erforderlich, damit sie ordnungsgemäß ausgeführt werden können. Wenn Sie nicht als Administrator angemeldet sind, steht diese Option nicht zur Verfügung."

      Diesen Vorgang habe ich für jede FS spezifische Anwendung wiederholt, das schließt den PMDG Config- und Loadmanager mit ein.

      Was hab ich bei Windows selbst alles gekillt?:

      Die UAC (kann auf mich selbst aufpassen :rolleyes: )
      Indexservice
      Windows Defender
      Systemwiederherstellung

      quasi das "Standardprogramm" für einen optimierten Rechner, sollte nicht weiter überraschen.


      Meine Testumgebung: "Setup2"

      Nachdem ich meine Serie von Flügen auf relativ nacktem FSX erfolgreich absolviert habe, musste jetzt Switzerland pro X drann glauben.
      Die neue Testreihe ist demnach gleich dem software setup von oben nur um die Switzerland Pro X erweitert.

      perfektes Szenario:
      LOWW (basic) - LSZH (FSDT addon) eingebettet in einer Sichtflugszenerie unter Echtzeitwetter mit der MD11 bei Nacht (braucht, wie man mir gesagt hat die meisten Ressourcen, ausgezeichnet zum Testen)

      zwischen SITNI und MATIK bin ich bei jedem Flug mehrmals auf den Desktop gewechselt um die Sache etwas reizvoller zu gestalten.

      Flug 1) TEXTURE_MAX_LOAD=1024 funktioniert problemlos (airport baut sich wie er soll auf, MD11 lässt sich selbst nach approach switchen, wiederbefüllen weiterfliegen.

      Flug 2) TEXTURE_MAX_LOAD=4096 FSDT Airport baut sich nicht auf (es fehlen also keine Texturenteile sondern FSDT Zürich sieht aus wie im Demo Modus, wie niedergebrannt). Wechsel am "imaginären" Gate aus der MD11 zum Desktop wird mit Blackscreen quittiert:

      Damit wäre bereits plausibel, dass es sich hier um kein seltenes Hardwareproblem handelt, eine einzige VFR Szenerie und eine Abweichung in der FSX.cfg nämlich "texture max load 4096" (für REXv2 in "schön" :) ) hat gereicht um das Mysterium zu reproduzieren. Ist also nichtmal AI Traffic zusätzlich notwendig.

      Hätte genauso gut ein Anflug auf Aerosoft EDDH eingebettet in VFR Germany Nord sein können, habe ich hier ausgelassen, weil ich mich an die Symptome noch gut erinnern kann, vor meiner aktuellen FSX installation. => halb aufgebaute Gebäudestrukturen und blackscreen am Gate mit PMDG.

      Im Zuge dieser Austausch.dll tweaks, gemeint ist "uiautomation.dll", die derzeit gerne auch im Zusammenhang mit der Fensterwechselproblematik inzwischen auch schon mal der Tipp gegeben, sich vom "Sitzungsmanager für Desktopfenstermanager" (kreativ sind sie in Redmond!) gänzlich zu verabschieden, ergo den Dienst zu killen.

      Das halte ich für keine gute Idee, weil

      Flug 3) selber Flug erneut bei TEXTURE_MAX_LOAD=1024

      FSDT Airport vorhanden
      PMDG verliert Texturen:



      dann folgt das hier, beim Beenden des FS:



      So jetzt konnte ich das Texturen "Gerippe" auch endlich wieder nachvollziehen, dass hatte ich zuletzt unter Windows Vista. Dienst wieder angestellt, Problem behoben.

      Ich darf kurz zusammenfassen:

      1.) TEXTURE_MAX_LOAD=4096 ist Gift für PMDG, wenn VFR Szenerie den Anflug tangiert (blackscreen spätestens beim Fensterwechsel am Gate nach approach)
      2.) TEXTURE_MAX_LOAD=4096 killt FSDT bei Nacht im Anflug mit PMDG wenn VFR Szenerie im Anflug mit von der Partie ist.

      Es gibt sicher jede Menge anderer Settings die ähnliches bewirken. Für mich war ausschlaggebend, die Fehler zu reproduzieren und das gelingt mir bei jedem weiteren Flug, wenn ich Wert darauf lege. In meiner letzten Testreihe hatte ich noch die ASA Wetter Engine selbst in Verdacht, weil wenn ich ohne Wetter geflogen bin, blieb auch FSDT erhalten. Jetzt weiß ich, es sind die REX HD Texturen die offensichtlich einen Knoten in den FSX machen, dass mehrere addons wie aircraft, airports und AI traffic tools überfordert sind und ich kann nicht ausschließen, dass andere womöglich bereits bei einem value von 1024 diese Symptome haben, in Abhängigkeit ihrer FSX Ausbaustufe.

      Ich hoffe das hilft dem einen oder anderen bei seiner Fehlersuche.
    • ATI Tray Tools

      @ Hans300

      Hi, ich hab jetzt trotz eines stabilen, guten, fehlerfreien und schnellen FSX bei sehr hohen Einstellungen das ATI Tray tools installiert und auch zum laufen gebracht. Millionen von Einstellungsmöglichkeiten und Häckchen zum setzen. Wenn du so nett wärst und mir mal deine Einstellungen (die wichtigsten) reinschreiben oder screens reinstellen würdest, mit der du die ATI scharf wie ne Nvidia bekommen hast?

      Wäre genial :beer:

      Gruss
    • Commander-AUT schrieb:

      Im Zuge dieser Austausch.dll tweaks, gemeint ist "uiautomation.dll", die derzeit gerne auch im Zusammenhang mit der Fensterwechselproblematik inzwischen auch schon mal der Tipp gegeben, sich vom "Sitzungsmanager für Desktopfenstermanager" (kreativ sind sie in Redmond!) gänzlich zu verabschieden, ergo den Dienst zu killen.


      Toller Bericht. Vielen Dank dafür. Jetzt ist man wieder ein wenig schlauer:).

      Kannst du bitte nochmal erzählen was du in dem oben aufgewiesenen Zitat genau meinst? Habe das nicht ganz verstanden?

      Dank Dir
      Stingrey, Mitglied im FlightXPress Forum seit Sep 2007.
    • Stingrey schrieb:

      Toller Bericht. Vielen Dank dafür. Jetzt ist man wieder ein wenig schlauer.

      Kannst du bitte nochmal erzählen was du in dem oben aufgewiesenen Zitat genau meinst? Habe das nicht ganz verstanden?


      servus,

      gern geschehen! :)

      Zu deiner Frage:

      Die "Switch-Probleme" die viele haben, äußern sich auf imo 2 unterschiedliche Arten:

      1.) nach zu oftmaligem Wechsel auf den Desktop bleibt der Bildschirm schwarz und lässt sich sich nicht mehr aufbauen Der Sound bleibt aktiv, es erfolgt auch kein Absturz des FSX mit "schwerwiegendem Fehler" (so hatte ich es)

      und kann diese Probleme mit den zuvor geposteten Kompatibilitätssettings + Verzicht auf FSX.cfg tweaks zuverlässig umgehen. Ich hatte unter W7 64bit, egal ob RC oder RTM) noch keinen CTD!


      2.) hier crasht der FSX "mit schwerwiegendem Fehler" sehr oft in Bezug auf die "uiautomation.dll"

      imo ein eigenständiges Problem welches auf den selben trigger (viele switches zum Desktop) zurückzuführen ist.

      Das was du zitiert hast, ist eine präventive Warnung vor einem Tipp der mutmaßlich helfen sollte. (weil ich ihn im Zuge meiner testreihe miteinbezogen habe)
      und jeder der die erwähnten Probleme mit CTD des FSX hat, soll in der Systemsteuerung => Verwaltung => Dienste, nachsehen ob dieser Dienst läuft oder nicht. Falls nicht, dann besser wieder aktivieren, um das als etwaigen Auslöser zu eliminieren.

      Zu dem "uiautomation.dll" Problem gibt es in diversen FS spezifischen Foren, diverse workarounds, die viel eher am Problemkern vorbeiführen, man betreibt Symptombekämpfung anstatt Ursachenforschung.

      Wenn ca. 10 "Problemkinder" koordiniert zusammenarbeiten würden, wäre das Geheimnis wahrscheinlich binnen einer Woche gelüftet.

      Irgendetwas machen die Herrschaften "anders" um nicht falsch zu sagen ;)

      Sei es bei der Installation, bei der Rechtverwaltung, haben eine Anwendung am Laufen die am FSX nichts verloren hat, whatever.

      Das Problem liegt sicher nicht an WIN7 und nicht am FSX. Meine letzte FS Install war kurz bevor ich ihn platt gemacht habe 300gb groß und selbst dort hatte ich keinen CTD wegen dieser dll.

      Jetzt unabhängig, von oft fehlendem SP2 für den FSX, Adressraumpatches die weder sinnvoll noch notwendig sind. Wenn ich hier blind einen Tipp betreffen Fehlerquelle abgeben müsste, würde ich die Ursache im Bereich NET-Framework und den Visual C++ Umgebung vermuten. (diese Informationen inklusive Versionsnummer sind wesentlich wertvoller als eine Signatur mit den Hardwareckdaten, wenn man hier an einer Lösung interessiert ist.)

      Entweder ist das passiert durch selbst zugeführte updates via Windows updates, durch ein addon oder es legt sich der Speicherschutz von Securitytools quer (Antivirenprogramme, Personal Firewalls, usw natürlich auch die MS spezifischen, diesb. Boardwerkzeuge)

      Wenn diese Informationen konzentriert gesammelt würden, wäre das Problem recht flott aus der Welt. Ich kann es nur leider nicht reproduzieren, da mir die Vergleichsdaten fehlen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Commander-AUT ()

    • Guten Morgen,

      ne kurze Zwischenfrage:

      Ist der Parameter bekannt, welcher für die "Artefarkte" verantwortlich ist?
      Habe den Thread überflogen, aber keine Antwort gefunden....oder gibts noch keine?!?

      Schönen Sonntag noch
      Joachim
      Prisco, Mitglied im FlightXPress Forum seit Sep 2007.