Beiträge von Füchti

Hallo liebe Heliflieger,

heute habe ich mal einen kleinen Erfolg zu vermelden, in der Hoffnung, dass das nicht eh'schon bekannt ist ...

Das Rätsel um die nicht oder nur sporadisch funktionierende "Ready to Fly"-Option für die 407 im MV Manager ist gelöst .

Die Funktion oder Nichtfunktion dieser Option ist abhängig von der Einstellung des Mixture-Levers ....
Warum auch immer...
Wenn der Mixture Lever auf Full-Rich steht oder während des Ladens/ Hochfahrens auf Full-Rich gesetzt wird (entweder über eine Achse oder über die Tastenkombi CTRL-SHFT-F4 ), dann fährt die Turbine hoch ... gesetzt den Fall, man hat den Wind abgestellt...

Ich kann das hier zu 100% reproduzieren:
Mixture full off = Mühle fährt nicht hoch/ Mixture full rich= Turbine fährt hoch, auch wenn der Gashebel noch auf unterer Drehzahl, aber oberhalb der Cuttoff-Position sitzt, wie es sich gehört, dann geht die Turbine brav in den Leerlauf (etwa 60%) und wartet darauf, dass man sie hochfährt.

Dass bei mir die "Ready to Fly"-Option gar nicht, bzw, nur ganz am Anfang einmal, funktioniert hat, erklärte sich dadurch, dass ich den Mixture keiner Achse zugeordnet habe, warum auch, ich fliege ja ausschließlich Turbinenheli's und wenn nicht, dann die King Air und für die gelegentlichen Flüge mit der C172 nehme ich die Tasten für's leanen.

Die Mixtureeinstellungen werden, wie die anderen Enginesettings ebenfalls, in Flugdateien mit abgespeichert, und dementsprechend stehen sie bei mir bei allen Flügen auf Null, mit einer Ausnahme, nämlich des Default-Flights und genau deshalb hat es anfangs funktioniert, weil ich den zum testen von neuen Luftfahrzeugen lade, um eventuelle Probleme im Zusammenhang mit Szenerien zu vermeiden...

Also:
Wer Probleme mit der "Ready-to-Fly"-Option der MV 407 hat, der stellt entweder über CTRL-SHFT-F4 das Gemisch auf voll reich oder setzt eine Controllerachse und stellt diese auf voll reich oder ändert in der Flugdatei die entsprechende Einstellung in der Sektion
"<Section Name="Engine Parameters.1.0">" (Achtung! bei mehreren Triebwerken gibt es so viele Engine-Parameter-Sektionen, wie es Triebwerke gibt!) von
<Property Name="MixtureLeverPct" Value="0" />
auf
<Property Name="MixtureLeverPct" Value="1" />

Wobei "1" der maximale Wert ist und üblicherweise nicht von Controllern erreicht wird, abgespeicherte Daten von Controllern sehen dann etwa so aus:
<Property Name="MixtureLeverPct" Value="0.999755859375" />

Sollte man eine Controllerachse auf die Mixture programmiert haben, bitte beachten, dass wenn diese auf Minimum steht, möglicherweise die aus dem Flug übernommenen Daten überschrieben werden und es dann wieder sein kann, dass die Mühle nicht startet.

Nachdem die Turbine erstmal hochgelaufen ist, hat die Mixtureeinstellung keine Funktion/ Bedeutung mehr (welche auch? .....)

Das Ganze ist schon ein bisschen merkwürdig und nicht oder nur wenig zu verstehen ... denn Turbinenhelis haben gar keinen Gemischhebel ... warum auch immer das also so ist ... keine Ahnung.
Die MV 407 ist nicht der einizge Flieger mit einer solchen Eigenart, auch die Aerosoft Huey hat eine solche ... bei der muss ich, wenn auf "Ready to Go" klicke, einmal kurz den Collective anlupfen, nur ein kleines Stückchen, dann läuft auch da die Turbine los, ansonsten ebenfalls nicht.
Mystische Welten ... mystische Welten.

Alles in Allem ok und gut zu wissen.
Am liebsten klickt man sich ja eh' durch die Anlassprozedur, aber gerade für Testflüge ist so eine Option ideal.

Liebe Grüße & happy landings
Marcus

Hi again.

Kurz gefragt:
Was soll eigentlich die "Free Radio" Option im MV ACM-Manager bewirken?

Wenn ich das anklicke, dann habe ich nur Abdeckbleche im Radio Stack ....
Die Dokumentation schweigt sich darüber aus (oder ich übersehe das immer wieder...), genauso wie das Forum.
Dort gibt es einen Thread, indem jemand anmerkt, dass in der "Free Radio" Option das ADF im Radiostack unten abgeschnitten ist, auch mit Screenshot .... Rätsel über Rätsel, denn wie gesagt, bei der angewählten Option, ist da bei mir gar nichts eingebaut ...

Ich hatte die stille Hoffnung, dass man damit seine Avionik konfigirieren kann und ich damit einen ADF zufügen kann.
Für einen VFR- Flieger sind die Dinger immer noch Gold wert, besonders für Helikopter, insofern verstehe ich ohnehin nicht, dass es nicht ein Modell gibt, welches einen beinhaltet.

Ich kann übrigens dann die "Ready to Fly"-Option nutzen, wenn ich aktuell einen Flieger mit laufenden Motoren in Betrieb habe ....
Rufe ich dann eine MV 407 auf, welche "Ready to fly" konfiguriert ist, dann läuft die Mühle.
Rufe ich eine "Cold and Dark" auf, dann ist die auch cold and Dark.
Witzig ist aber folgendes:
Wenn ich den Flieger "Ready to Fly lade und er dann ja nicht anläuft, obwohl die Instrumente aktiv sind, brauche ich nur einmal "CTRL-E" drücken und die Kiste ist an .... .
das geht auch, wenn die Mühle Cold and dark geladen wurde, nur muss man CTRL-E dann zweimal drücken .... (Dann stimmt allerdings keine einstellung an den Schaltern mehr, die muss man alle nachsetzen und die Kiste geht dann auch schnell wieder aus ...)

Irgendwie bin ich versucht, den nochmal runterzuladen, nicht dass am ende einfach nur der Download 'ne macke hat.
Aber dann hätte ich eher erwartet, dass ich das Zip nicht auspacken kann oder anderes ...

Wenn ich nicht ganz daneben liege, handelt es sich dabei um den Fix, welcher durch den Umstand entstanden ist, dass der FSX nun mal kein Win7-GUI besitzt (=Graphical User Interface -> grafische Benutzeroberfläche).
Wie bei vielen anderen XP-basierten Programmen, bedingt das ein Abschalten der Aero-Funktionalität von Windows 7 und höher.
Vielleicht hast Du das schon selbst mal gehabt, dass bei alter SW der Desktop umschaltet und Du eine Meldung bekommst, dass nun das Standard Schema verwendet wird.
Ab dem Moment wird aber auch das Windows7-eigene vsync deaktiviert, was zu Tearings und eben den üblichen vsync-Problemen führt.
Abhilfe schafft dabei ein Neustart des DWM, des "Desktop Wondows Manager", nachdem der FSX gestartet wurde.
dadurch wird die vsync Funktion wieder aktiviert.
Dann gibt es zusätzlich einen Eintrag in der FSX.cfg.
In der Sektion [GRAPHICS]
wird diese Zeile eingetragen:
ForceWindowedVsync=1
Das ist jetzt aus nur aus dem Gedächtnis wiedergegeben, also bitte noch mal prüfen oder bestätigen oder korrigieren.

Wenn ich mich recht erinnere, dann gibt es dazu auch einige Scripte ider Batch-Dateien, um das zu automatisieren, aber da müsste ich selber erstmal nach suchen, sorry.
Ich bin mir aber sicher, dass es da einen Thread von Kosta im AVSIM-Forum gibt.
Wenn Du also den rot markierten Begriff googlest und da ein Treffer aus dem AVSIM-Forum dabei ist, dürfte das wohl schon der richtige Thread sein .

Viele Grüße
Marcus

Erstmal lieben und vielen Dank für Deine Mühe.

Ich werd mal sehen, dass ich das mache.
Im Großen und Ganzen hätte ich das wohl recht ähnlich übersetzt, muss nur gestehen, dass mir das einfach im Moment zu viel geworden wäre.
Mit der Vorlage überlege ich jetzt schon, ob ich das mit einigen Ergänzungen (und wenn ich darf, Änderungen) mal dort poste und hinterfrage.

Auch möchte ich gern wissen, ob noch andere das Problem haben, dass die 407 sich nicht Ready to Fly laden lässt.

Aber die Abstürze sind mit Abstand am nervigsten.

Ich werd mir damit aber noch ein wenig Zeit lassen, denn meine Frau hat derzeit Urlaub und da stehen Flusi und Rechner ganz weit hinten an .

Liebe Grüße & Danke
Marcus

Zitat von overflow

"C:\Users\Dein Username\AppData\Local\Lockheed Martin\Prepar3D v2\Shaders"

Für Schreibfaule lässt sich die Zeile verkürzen, indem man den ganzen vorderen Teil bis "Lockheed..." durch %LOCALAPPDATA%\ ersetzt.
Sieht dann so aus:
%LOCALAPPDATA%\Lockheed Martin\Prepar3D v2\Shaders

Funktioniert auch auf Commandointerpreter-Ebene

Wobei ich, was die Sahder angeht, noch nie so ganz verstanden habe, was genau der Eintrag "SHADER_CACHE_VERSION=1" in der CFG bewirkt.
Warum auch immer, aber ich bekomme die Übersetzung der Beschreibung aus dem LM-P3D-Learning Center nicht korrekt zusammen:

Zitat von Learning_Center

Using this rebuilds your shader cache by incrementing the number each time you make
a change to the Prepar3D.cfg.

Eigentlich würde ich das so übersetzen, dass nach jeder Änderung (bzw. nach der Anzahl der gesetzten Ziffer) eingetragenen in den Settings, der Cache neu aufgebaut wird.
Eine "1" bedeutet also, nach jeder Änderung, eine 2 nach jeder 2. Änderung usw.
Nur ergibt das nicht so recht Sinn und deckt sich auch nicht mit den Daten im Shaderverzeichnis.

Das Löschen der Shader ist gewiss die sicherere Lösung, aber mich würde wirklich interessieren, was dieser eitnrag tatsächlich bedeutet/ bewirkt.

Berichtest Du, ob und wenn, was sich daraus ergeben/ geändert hat?
Wär prima.

Na hömma ...
Du hast doch Windows, und Windows hat einen Taschenrechner, den stellst Du mit "Ansicht" auf "Programmierer" und wenn der auf "Dez" steht, gibst Du "33" ein und stellst dann von "Dez" auf "Hex", dann ändert sich der Wert im Display von "33" auf "21" und schon hast Du den Hex-Wert .

Die Blöcke in der Datei für die jeweilige Einstellung sind leicht erkennbar, denn sie beginnen mit <Custom ... und enden mit </Custom....

Also fügst Du in der Datei die Zeilen:
<CustomSettingValue>
<UserfriendlyName>33 fps</UserfriendlyName>
<HexValue>0xF0000021</HexValue>
</CustomSettingValue>

in die Datei ein, an welcher Stelle bleibt Dir überlassen, aber der Logik folgend (jaja, Logik hin oder her, aber ich bin ein Freund der Logik) würde ich es zwischen die Einträge 30 und 35 setzen, das ist übersichtlicher

Das Ganze sieht dann so aus:

<UserfriendlyName>30 fps</UserfriendlyName>
<HexValue>0xF000001E</HexValue>
</CustomSettingValue>
<CustomSettingValue>
<UserfriendlyName>33 fps</UserfriendlyName>
<HexValue>0xF0000021</HexValue>
</CustomSettingValue>
<CustomSettingValue>
<UserfriendlyName>35 fps</UserfriendlyName>
<HexValue>0xF0000023</HexValue>
</CustomSettingValue>

Den blauen Teil fügst du so in die Datei ein, wie Du es hier siehst und der Fisch ist geputzt .

Ok, ... Rainer war schneller, aber sorry, das konnte ich mir jetzt nicht verkneifen

Ein Batch zum Shaderlöschen ist in der Tat eine gute Idee.

Wobei mir zum Thema ausmachen des 407 noch ein paar Unrichtigkeiten aufgefallen sind.
Die Mühle schaltet das Triebwerk auch ab, wenn auch nur eine der Treibstoffpumpen abgeschaltet wird.
Das dürfte aber nicht passieren.
Und auch wenn ich das Original Handbuch noch nicht gelesen habe, sondern nur von der 206 ausgehe, dann dürfte das Triebwerk zumindest unterhalb von 6000ft auch dann nicht abschalten, wenn auch beide Pumpen aus sind, da bereits der Jet Ranger eine dreifache Reundanz auf den Pumpen hat und die dritte Pumpe mechanisch an der Welle hängt.

Das sind zwar nur Kleinigkeiten, aber ich war etwas perplex, als ich gewohnheitsgemäß eine der Pumpen abschaltete und dann völlige Stille herrschte

Zitat von overflow

Du brauchst auch beim NI nichts in der XML machen, einfach 33 eintragen von Hand im Profil und dann übernimmt er die rechts auch als Hexwert.

Das habe ich vor längerer Zeit mal versucht, hat aber nicht funktioniert.
Der Wert wurde nicht übernommen.
Kann aber gut sein, dass das noch mit einer früheren Version des NI war.

Zitat von overflow

Der RAM Takt wird immer durch die Übertaktung (Bus und CPU) bestimmt und kann auch mal krumme Werte wie zum Beispiel 1536 haben.

Das kann ich soweit nchvollziehen und bestätigen.

Aber dennoch denke ich schon, dass es einen Unterschied zwischen 1333er und 1600er machen wird, denn letztlich ist das fast ein Viertel mehr an Takt und das dürfte sich schon bemerkbar machen.

Natürlich muss man auch die Latenzen beachten!
Es dürfte wohl witzlos sein, einen 1333er mit CL8 oder CL9 zu haben und den gegen einen CL10 1600er auszutauchen.
Das die Werte immer auch eine große Rolle spielen, sollte natürlich nicht unerwähnt bleiben.

Auch ein interessanter Tipp, Danke.
Allerdings bedeutet das dann ja auch, dass jedesmal die Shader neu aufgebaut werden müssen.
Obwohl ich zugeben, davon in meiner aktuellen Konfiaguration nichts zu merken, das führt bei mir nicht zu spürbaren Rucklern, wäre also eine Option.

Nach wie vor kann ich die Kiste übrigens nicht Ready to Fly bekommen ... Rotor steht...
Macht aber nix, denn ganz ehrlich: Der Anlass-Sound ist so genial, dass man den einfach genießen muss

Zitat von Ruhrfrequenz

Ganz klar Fenstermodus. Im Vergleich zum Vollbildmodus stelle ich keine spürbaren Verbesserungen fest.

Das bestätige ich

Dazu die Empfehlung, falls einen die Dateizeile oben einfach nervt, schließlich ist der Monitor ganz bezahlt, da darf er auch ganz benutzt werden , das kleine Pseudofullscreen-Script von AVSIM einzusetzen, welches unter dem kleinen Freeware Tool "Autohotkey" läuft (auch bei Chip.de zu bekommen).
So hat man ein Vollbild, ist aber im Fenstermodus.
War für mich damals die beste Lösung .
Edit:
Um das Script zu finden, suchst man am Besten in der AVSIM-Library nach dem Suchwort "autohotkey" oder nach "pseudo_full_screen.zip"

Was die Frameratelimitierung betrifft:
Das sind nicht wirklich "Lager".
Da muss man einfach testen und das Setting nehmen, welches auf dem eigenen System am besten funktioniert.
Da ist einfach von System zu System verschieden und muss ausprobiert werden.

Nach wie vor:
Rätsel über Rätsel mit dieser MilViz 407 Kiste ....

Nachdem ich den komplett deinstalliert und anschließend neu installiert habe, gleich am Anfang vor dem ersten Start auch im Manager alle Settings durchgeklickt und gespeichert habe, bleibt das gleiche Problem:
Sobald ich einen gespeicherten Flug mit dem MV407 aufrufe, stürzt mir P3D ab.

Aber ich habe einiges dazu rausgefunden:
Zum Einen scheint es AUCH mit dem Ai-Traffic zusammenzuhängen.
Aber nicht nur.
Weiterhin muss ich mich vorher in einer Situation befinden, in der bereits ein MV407 das aktuelle LFZ ist ...

Ich hab das getestet:
Stand mit meinem Standardflug, dem Dodosim Jet Ranger vor der Flugleitung in EDXF, Flug noch frisch geladen, Cockpit Cold & Dark.
Wollte den MV-Flug laden, im Grunde die selbe Situation, selber Ort, selbe Zeit, selbe Position, nur ohne Wetter/ Wind und mit der MV407 -> Absturz beim Laden.

Habe dann einfach mal einen anderen Flieger geladen und den Dodosim gegen die Default-King Air ersetzt, hätt ja sein können, dass es Probleme mit komplexen Aircrafts mit externen Modulen gibt -> Absturz beim Laden des MV407-Fluges.

Dann das gleiche Spiel nochmal, Flug geladen, MV407 geladen UND den AI-Traffic (nur Flieger, sowohl GA als auch Airline) auf 0 gesetzt -> Flug wurde geladen. ...

Ich hab das noch ein bisschen weiter durchprobiert und es scheint reproduzierbar zu sein.
Nur wenn ich vorm Laden eines gespeicherten MV407-Fluges sowohl zunächst den MV 407 lade UND den AI-Traffic auf 0 setze, kann der Flug ohne Absturz geladen werden.

Anschließend kann ich den AI-Traffic wieder hochsetzen (in meinem Fall steht der auf 75%)

Sorry, aber das ist doch so schräg, dass es schräger schon nicht mehr sein kann oder?

Wie auch immer, dieser Flieger ist nicht meiner, größter Fehlkauf, zumindest auf meinem System, mag ja vielleicht ein Einzelfall sein.

Aber immerhin kann ich ihn so laden und damit fliegen und das ist auch soweit ok.
Für Flüge, die mal ein bisschen zügiger sein sollen, ist der ja ganz prima und hübsch ist er auch .

Ich weiß nur nicht, ob meine Englischkenntnisse auseichen um das für das MV-Forum auszuformulieren und ich weiß auch nicht, ob dazu jetzt auch noch die Lust habe.
Die Zeit, die mich dieses Teil schon am Boden und zum Testen gekostet hat, überschreitet den Wert und die Qualität des Fliegers ungefähr um das Tausendfache ...

Zitat von Zonk0815

im Arbeitsverzeichniss des NVIDIA Inspector gibt es die Datei CustomSetingNames_en-EN.xml. Dort könnt Ihr jeden gewünschten Wert einfügen ! Einfach dann auch den entprechenden HEX Wert weiterzählen!

Das funktioniert übrigens pirma, Danke für den Tipp.

Ich habe mir Setting für 33 FPS eingerichtet und das wird auch sauber übernommen.
Vielleicht werde ich noch mal schauen, ob ich Unterschiede in der Ausführung erkenne, wenn einmal die Bildrate mit dem Riva-Tuner und einmal mit dem NI gesetzt wird, da beide ja anscheinend nicht die gleichen Verfahren verwenden, denn der Riva Tuner greift in die laufende Applikation ein, und stellt den geünschten Wert ein, ungeachtet dessen was im Treiber steht.

Was ich auf jeden Fall inzwischen für mich gemerkt habe ist, dass es für mich keinen Sinn macht, die Frames auf unbegrenzt zu lassen und nur vsync zu setzen, egal auf welche Weise.
Das gibt zwar eine flüssige Simulation und mit gesetztem vsync fährt meine GPU auch nicht in Volllast, aber es zeigt sich deutlich, dass man einen Preis zahlt, wenn man die Priorität auf die Framerate setzt und krebst dann ja durchaus in Bereichen um die 60 herum.
Die Folge davon sind deutlich langsamer nachladende Bodentexturen, was sehr sehr deutlich bemerkbar ist, weil man über unscharfes Bodengelände fliegt.
Genauso werden Objekttexturen, besonders Texturen von AI-Flugzeugen nur sehr langsam nachgeladen und die Flieger bleiben eine lange Zeit schwarz.
Sobald ich die Framerate wieder begrenze, ist das erledigt und ich habe schnell ladende Flieger- und Bodentexturen .

Das mag natürlich von System zu System unterschiedlich sein, aber auf meiner Mühle ist eine Frameratebegrenzung Pflicht und sie muss für beste Ergebnisse auch extern erfolgen.

Die über den NI eingestellten 33FPS fand ich gerade bei einem Testflug aber sehr sauber und optimal .

Zitat von overflow

auch 1333 ist immer noch schnell genug zum Rest und es macht sich echt NULL bemerkbar im Verhältnis zu 1600.

Das entspricht aber eben genau nicht meiner Erfahrung, als mein Sim stottrig und rucklig war, nachdem der RAM auf 1333 runtergesetzt war ....
Welche Erklärung sollte es dafür dann geben?

Naja, ... eigentlich sollte es ja logisch sein ... wir suchen nach den besten Multiprozessoren, die Highest-End-GPU's werden im SLI betrieben und dann hängt da 1333er RAM in der Kiste ....
Die Unmengen an Daten müssen ja nun mal alle auch durch den Speicher gejagt werden können....

Klar, der Takt ist nicht alles, die einzelnen Cyclen müssen auch sauber eingestellt sein, aber dafür gibt es ja die XMP-Profile.

Ich hab die Frage nach der Rolle des RAM auch spaßeshalber mal im LM-Forum gestellt.
Bis jetzt ist dort nur ein Antwortender aktiv, aber auch er schreibt klar, dass wir doch ohnehin alle auf der Jagd nach der besten Hardware sind und sich die Frage nach den RAM eigentlich bei den aktuellen RAM-Preisen gar nicht stellen sollte.

Er schreibt aber auch, dass er der Meinung ist, dass ab 2000er RAM kein Unterschied mehr vorhanden wäre.
Aber 1333er sind nun mal wirklich unterstes Ende.

Ich denke auch drüber nach, meine RAM zu tauschen, noch bevor ich die GPU angehe, einfach weil der RAM auch die geringere Investition sein dürfte (hab noch nicht nach Preisen geschaut).
Und ich bin wirklich zufrieden mit meinem System, wäre aber sehr daran interessiert, wie sich das verhält und ändert.

Zitat von Artur

Faktisch ist doch beides ein und das selbe Bild. Wie kann da das eine schärfer sein als das andere?

Kommt drauf an ....

Zunächst mal wie gesagt macht es bei NVIDIA-PU's einen Unterschied, ob ein Datensichtgerät als PC-Monitor oder als Fernseher erkannt wird, weil das unterschiedliche Farbräume bedeutet.
Der Farbraum für Fernseher ist eingeschränkt auf 16 - 235 pro Farbkanal.
Datensichtgeräte, also PC-Monitore können aber den kompletten Farbbereich von 0 - 255 pro Farbkanal.
Das bedeutet, das Schwarz, welches 0,0,0 bedeutet, also Null für Rot, Grün und Blau, bei einem Fernseher jedoch 16,16,16 ist.
Auf einem Fernseher wird das auch als Schwarz wiedergebeben, ein PC-Monitor dagegen kann noch weiter runter und stellt denselben Wert also als dunkes Grau dar.
Gleiches gilt für Weiß.
Da Schärfe auch gleich Kontrast bedeutet, wirken die Bilder dann aber unscharf und flau.

Dass ein Screenshot wiederum anders wirkt, als das laufenede Bild des Sim auf dem Monitor, liegt daran, dass es Unterschiede, wie ein BNild erstellt und "weitergereicht" wird.
Das genau zu erklären würde mich im Moment etwas überfordern, dazu müsste ich erst wieder in meinen Büchern verschwinden.
Das ist schon zu lange her, dass ich mit damit beschäftigt habe/ beschäftigen musste ;).

Nur kurz soviel:
Das Bild, welches der Sim produziert, hat auf jeden Fall immer die gleichen Farbwerte.
Den Rest macht der Treiber.
Wenn der nun auf ein Unterhaltungsgerät eingerichtet ist, dann wird aus 0,0,0 eben 16,16,16 konvertiert und je nachdem, an welcher Stelle man das Bild "abfängt" hat man es entweder in seinem Ursprung oder berits für das Datensichtgerät aufbereitet.

(das ist jetzt sehr grob aus dem Gedächtnis gesaugt, und dürfte wohl extrem verbesserugnswürdig sein, aber hilft vielleicht zumindest für ein etwas grundsätzliches Verständnis)

Was jetzt?

Das klare Bild im FSX ist weg und Deine Screenshots sehen kacke aus?

Irgendwie bin ich mir nicht sicher, ob Du uns verarschen willst oder da wirklich ernst meinst.

Welches Problem ist denn nun behoben?

Du hast doch geschrieben, dass dein Sim auf dem Monitor super aussah ...

Wat stimmt den nun?

Zitat von Duesseldorf25

Fakt ist das, dass Bild im fsx scharf ist und der Screenshot sehr schwammig.

So etwas wäre schon mal eine mehr als hilfreiche Information im Zuge der Frage selber, denn dort hast du nur gefragt, wie man mehr Schärfe bekommt.

Zitat von Duesseldorf25

Nach langer Suche habe ich den Schuldigen gefunden und das war das Programm welches die Screenshots verkleinert hat.

Deshalb wurdest Du ja auch gebeten, den Screenshot in Originalauflösung zu posten.

Ganz ehrlich:
Hier hilft gewiss jeder helfen, aber dazu brauchts auch eine entsprechende Unterstützung des Fragestellers.
Wir haben ja keine Kristallkugeln und sitzen nicht vor Deinem Rechner .

Zitat von Duesseldorf25

Aber du würdest mir aufjedenfall empfehlen die DVI Anschlüsse zu nutzen? Dann würde ich das morgen mal direkt umstöpseln.

Wenn Deine Einstellungen ok, sind und Du ansonsten zufrieden bist, dann spricht nichts dagegen, es zu lassen.
Never change a running System.
Mach vorher ein Image und teste es einfach.
Aber vorher ein Image ziehen, sicher ist sicher.

Angesichts des Threads, den Du für die Frage gewählt hast und angesichts der Frage selber, wäre hier wohk kaum überhaupt jemand darauf gekommen, dass Dein Problem nur mit dem Screenshot selber zusammenhängt.

Also ehrlich und gut gemeint:
Kommunikation ist alles, wenn Du Hilfe erfragst, müssen jene, die Dir helfen sollen, auch über das Problem becheid wissen, denn hier kann Dir keiner in den Kopf schauen.

Welches Programm verwendest Du zum reduzieren der Auflösung?

zunächst mal, wenn GPu und Monitor einen DVI-Anschluss haben, sollte man auch den nutzen, zumindest bei NVIDIA-GPU's, eben aus dem genannten Grund.
Man kann dden Farbraum etc. allerdings von Hand einstellen, das geht also auch, irgendwo habe ich das auch schon mal beschrieben.

Aber was Du bechreibst ist unlogisch, denn dann müsste der Screenshot scharf und das Monitorbild schwammig sein.

Aber noch imemr hast Du uns nicht erklärt, um was genau es Dir geht?
Was ist Dein problem?

Hilfe bei Problemen kann nur bekommen, wer sein Problem beschreibt und das fehlt bei Dir völlig.
Wir stochern hier und dort im Dunkeln rum und hoffen, mit etwas Glück das Richtige zu treffen.
Aber sorry ... ich fürchte dass mir dafür sowohl die Lust, Geduld und auch die Zeit fehlt.

Solange Du nicht klar formulierst, worum es Dir geht, kann Dir keiner helfen und ich schätze mal dass ich nicht der einizige sein werde, dem seine Zeit zu schade für wilde Vermutungen ist.

Zumal dieser Thread hier das Thema NVIDIA-Inspector hat und ein Tutorial ist, insofern wäre es ohnehin besser, einen eigenen Thread für Dein Problem aufzumachen, denn ich sehe nicht, inwiefern sich hier eine Frage speziell zu dem Tutorial oder dem NI ergibt .... irgendwie sehe ich gar keine Frage ...

Zitat von Duesseldorf25

Das Bild ist bei mir im FSX VIEL klarer, hier auf dem Screenshot sieht das so aus als wenn ich durch eine dreckige Brille schaue.. Leider weiß ich nicht wie ich dir den unterschied zeigen soll

Ich verstehe offengestanden nicht, worauf Du hinaus willst und um was es Dir geht

Wenn das Bild im FSX viel klarer ist, dann ist es doch gut oder?
Wenn Screenshots nicht das gleiche Aussehen haben, dann liegt das mitunter daran, wie sie gemacht wurden.
Screenshots über die "V"-Taste des Sim seheu.U. anders aus, als jene, die über die PRTSC-Taste gemacht werden, was daran liegt, dass einige Einstellungen intern, also InGame, andere extern gemacht werden.
Wie genau das zusammenhängt kann ich hier nicht erklären, bin aber selber auch schon darauf reingefallen.
Vereinfacht ausgedrückt würde ich es so bechreiben, dass die Abarbeitung der Bildeinstellungen gewissermaßen sequentiell erolgt und die Unterschiede zwischen der InGame-Darstellung und Screenshots dadurch entstehen, wann das Bild "abgefangen" und in einer Datei gespeichert wird.
Das ist aber seeeeeeehr vereinfacht und muss auch nicht stimmen.

Aber anyway ... Du fragtest nach mehr Schärfe, jetzt schreibst Du, dass das Bild im FSX viel klarer sei ... ich weiß nicht, worauf du hinauswillst.

Dann bliebe noch die Frage nach Deiner Monitoreinstellung und wie der Monitor angeschlossen ist.
Nur nebenbei:
Wenn Monitor über HDMI betrieben wird, dann erkennt eine NVIDIA-karte diesen üblicherweise als fernseher und stellt, warum auch immer, das versteht bis heute keiner, das Gerät als Fernseher.
Man möchte meinen, dass das egal sei, aber das ist es nicht, denn die Farbräume wren zu Röhrenzeiten andere und genau das stellt der Treiber um und damit hat man einen eingeschränkten Farbraum, was sich z.B. dadurch bemerkbar macht, dass die Farben flau und flach und das Bild kontrastarm wirkt und Schwarzflächen allenfalls als dunkelgrau bezeichnet werden können.
Aber wenn Du schreibst, dass das Bild im Sim besser und klarer aussieht, kann es das ja irgendwie auch nicht sein.

Der langen Rede kurzer Sinn:
ich verstehe derzeit nicht, wo Dein Problem ist

Und ansonsten würd ich mir auch ein Bild in Originalauflösung wünschen.