Aus meiner Erfahrung heraus gibt es nur einen Grund die FPS zu begrenzen, und das ist das Online-fliegen. Der Grund scheint das Senden (Empfangen?) von Datenpacketen zu sein, die dann die empfangenden PCs nicht mehr verarbeiten können und so die Mitflieger springen lassen. Es reicht dabei aus, wenn ein Mitflieger die FPS nicht begrenzt hat. Scheinbar ist das Versenden der Datenpackete mit den FPS verknüpft.

Einen anderen Grund für eine Begrenzung kann ich - wie Jobia auch - nicht erkennen.

Ja PAL war bisher die im europäischen Raum am meisten verbreitete Norm der TV / Videosignalübertragung.

NTSC kommt aus dem amerikanischen Raum.

wesentliche Unterschiede sind z.B die Bildwechselfrequenzen bei PAL 50 HZ, bei NTSC 60 HZ.

Weiterhin wie die Chroma / Farbinformation im Signal abgelegt und dessen Stabilität gesichert ist.

Wie gesagt mittlerweile dürfte bundesweit nur noch auf DVB-T terristrisch Fernsehen empfangbar sein, über normalen Tuner seit letzte Woche nicht mehr.

Da spielt PAL nun keine Rolle mehr.

Wohl aber bei den meisten die noch die üblichen Röhren Fernseher besitzen, die keine RGB oder andere aktuellen Signalformen verarbeiten.

Denn der nun nötige DVB-T Receiver muss diesen ein Video Signal über die Video Cinch Buchse bzw. die beiden Scart Videopins liefern. Dieses hat Signal noch PAL Norm.



Ansonsten

Ja ein Röhrenmonitor arbeitet aus Sicht der Röhre selbst exakt wie eine TV Röhre, auch die Strahlablenkung. Nur das wir halt nicht an feste Ablenkfrequenzen beim PC Monitor gebunden sind, weiterhin wir hier eine höhere Auflösung darstellen können, was beim PAL TV keinen Sinn ergeben hätte, da die Übertragungsbandbreite begrenzt ist.

Siehe
http://steve-lacey.com/blogarchives/...blurries.shtml
und
http://www.steve-lacey.com/blogarchi...stutters.shtml
(auch die Kommentare!)

Die Begrenzung (target frame rate) ist "locked" in "Fullscreen" (Monitor) und im "Windows Modus" nicht.

Es hat schon einen Sinn es zu begrenzen. (Fibers)!

Aber im Prinzip auch abhängig von der Hardware und Treiber, also dem System des Anwenders.
Und vor allem auch der Verwendung von diversen "Addons", die mit ihren "Tricks" auch einiges wieder "aushebeln"

Siehe auch:
http://forums.avsim.net/dcboard.php?...id=3398&page=2
oder für multi core:
http://blogs.msdn.com/sebby1234/arch...06/567438.aspx

Das in der Hilfe steht, man soll auf seinem eigenen Geräte sein Limit finden, ist IMO korrekt, da es ja von sehr vielen Faktoren abhängt.

Horst

nicht ganz richtig Deine Aussage. Es geht hier wie gesagt nicht um das Thema Flimmern,

Du sagts ja selbst:

die Hz (Bildwiederholfrequenz) des Monitor haben ja nichts mit den fps des FlightSim zu tun!



Es geht um die erreichte FPS Rate, also die Rate der von der Graka berechneten Einzelbilder.


Gerade bei Bodentexturen verwendet die FS Grafik- und Terrainengine ein spezielles Verfahren um die MIP Level also die verschiedenen Qualitätsstufen der Bodentexturen zu laden.

Für dieses Verfahren gibt es einen ganz speziellen Grund.

Der Grund waren Custom Fotoscenerien, dessen Speicherbedarf während des Fluges. Da Custom Fotoscenery und normale Landclasscenery nach identischen Verfahren arbeiten, ist dieses das generelle Verfahren
was der FS bei der meshkompatiblen Bodentexturierung anwendet.

Ich möchte die genauen Gründen hier nicht erläutern.


Dieses Verfahren erfordert ein ständiges nachladen von Bodentexturen während der Bewegung. (auch von Texturinformationen die zuvor schon mal aktiv waren)

Genau dieses Verfahren hat eine Kopplung zu den erreichten Frameraten.

Habe ich sehr wenig Frames und viele nachzuladenden Informationen weil ich schnell fliege, kommt der FS nicht mehr nach. Wir alle kennen das die Bodenscenery wird mit der Zeit immer unschärfer.

Haben wir aber hohe Frames können mehr Informationen nachgeladen werden. Es wird ev. nur langsam unscharf.


Wenn jetzt jemand seine Frames begrenzt dann ist das in der regel nicht immer schlimm. Wehe aber er hat eine abwechslungsreiche Landclasscenery oder Fotoscenery, dann hat er mit begrenzten Frames sehr häufig unscharfe Texturen trotz eines guten PCs.

Man sollte also nicht unbedingt auf niedrige 20 Frames begrenzen.

Ich hatte mal eine Messkurve dieses verhalten im Forum gezeigt ist schon länger her. Dort kann man die Frameabhängigkeit sehen.

wohl gemerkt diese ist bei ein und dem selben System unabhängig ob es sich um reale Last oder Framebegrenzung handelt.

Werde sie nachher mal suchen.

In meiner DOK werden die Vorgänge genauert erklärt.


Achtung ich gebe zu das wenn man hohe Frames zulässt oder gar auf unendlich stellt Frameschwankungen stärker auffallen sogar in Form von Ruckeln.

Aber Achtung das wird oft durch störende Prozesse verursacht wie z.B Virenscanner siehe auch anderen Thread.

Ihr müsst diese störenden Prozesse nur ermitteln und beenden.

Werden störende Prozesse beendet dann läuft der Fs trotz wilder Frameschwankung ganz smooth.

Probiert es aus.

Zu der Target Frame Rate und LOD Target siehe diesen Link der übrigens vor den Microsoft Blocks entstanden ist.

http://www.wcm.at/forum/showthread.php?threadid=159653


Auch das einem Zeitmultiplex Verfahren ähnliche verhalten also die Stutters hatte ich früher vor den Blogs schon mal erläutert.

Hat mich dann selbst verblüfft, dass sich meine Ergebnisse die ich durch Versuche usw. ermittelt habe exakt mit denen der späteren Blogs decken.

Allerdings kann ich das mit LOD Target trotz offizieller MS Aussagen egal ob Vollbild oder Fenstermodus nicht bestätigen.

Wer weis, ev. ist hier im FS2004 etwas faul. Ev. war es so im FS2002 und im FS2004 arbeitet es nicht so wie von den Entwicklern vorgesehen.

Ich denke da z.b auch an LOD11 Mesh im FS2004 (FS9.0) was ja auch nicht ging, bestimmt aber so nicht gedacht war.


Das mit der Messkurve und den Frames findet sich in diesem Thread.



http://www.wcm.at/forum/showthread.php?threadid=168928

Zu dieser Messkurve müsste ich noch etwas erläutern, muss jetzt aber weg. Ev. später mehr.

hat mit dem Frames im Computer nix zu tun, aber das ist falsch ;)

Das PAL-System ist für die Farbwiedergabe zuständig, genau wie NTSC oder SECAM (sonst hätte man im Osten früher kein Westfernsehen gehabt). DVB-T ist nur eine neue Übertragungstechnik (eben digital).
Aber es wurde ja schon genügend durcheinandergebracht mit den ganzen Begriffen...so richtig läßt sich das wohl nie "ausmerzen" (genau wie die immer "empfohlenen Werte in der FS9.cfg
:-) ).

Ich hatte oben aber geschrieben, dass PAL auf dem Wege der Übertragungstechnik in der HF Ebene keine Rolle mehr spielt.


Auf Video Ebene hinterher schon noch.

Ich habe nicht geschrieben, dass PAl bei unseren bisherigen Fernsehern keine Rolle mehr spielt.

Wenn ich bei meinem System die Frames-Begrenzung von 20 auf 30 hochsetze, bekomme ich an den vielen Stellen, an denen die 20 eh nur knapp erreicht werden verwaschene Texturen.

Da ich hauptsächlich im Flusi "Linie" fliege konnte ich das immer schön nachvollziehen.

Also stimmt das schon, was Microsoft sagt, und funktioniert, und der Unterschied ist sichtbar. Wenn er bei euch nicht sichtbar ist, dann sind vielleicht eure Rechner zu schnell ;-)

Was das PAL Verfahren betrifft. Zu dieser analogen Technik der Farbsignal Unterbringung im ursprünglichen schwarz / weiss Videosignal könnte man natürlich noch sehr viel mehr sagen.

Nur ich denke nicht, dass hier jemand Interesse an solchen Geschichten wie Farbträgerburst, Farbkreis, R-Y, B-Y Signal, Phasenumtastung usw. hat.

Eine etwas kuriose Aussage.

Denn, die Framebegrenzung ist ja nur eine künstliche Begrenzung nach oben die dann in keinem Fall überschritten wird.


Beispiel:

Setze ich die Framebegrenzung auf 30 Frames, dann wird selbst der stärkste PC der hier sonst ev. 100 Frames erreicht dort nur mit 30 Frames arbeiten. Er wird dann bei störenden anderen Prozessen übrigens unempfindlicher hinsichtlich ruckeln.

Habe ich aber ein PC der aufgrund von Performanceproblemen eh nur 20 Frames erreicht, dann wird hier die Framebegrenzung auf 30 keine Frameveränderung auslösen. Der PC bleibt bei seinen durch Performance bedingten niedrigen 20 Frames hängen.

Den jetzt gesetzten oberen Anschlag von 30 Frames erreicht er nicht.



Deshalb funktioniert es ja auch nicht, wenn jemand bei einem eh schon schlappen PC bei Fotoscenery die Framebegrenzung von z.B 20 auf 90 hochsetzt. Das nützt einem schwachen PC nicht, der kommt da ja eh nicht hin.

Also ich habe einen schnellen Tower PC mit 3,4GHz und einen langsamen PC ein Notebook mit 2,53 GHZ der natürlich unter gleichen Sceneryverhältnissen arge Probleme hat.

Anhand beider kann ich diese Sachverhalte eindeutig nachvollziehen auch in Sicht Upper Frame Rate Limit und LOD Target.

Auch bei einigen Bekannten bei denen ich das an deren PCs getestet habe ist das nachvollziehbar.



Auch die Blogs der Microsoft Entwickler spiegeln dieses wieder.

Bis auf diese besondere Geschichte mit den Auswirkungen von LOD Target.

Als letzte Möglichkeit bleibt aus meiner Sicht nur noch der LOD bei Mesh übrig der hier unter LOD Target beieinflusst werden könnte.

Egal wie LOD Target steht es wird allerdings bei mir immer der höchstwertige LOD Level erreicht der im aktiven Mesh vorliegt.

Allerdings benötigt auch der höchste LOD Level eine Zeit bis dieser geladen ist.

Ev. gibt es hier eine Beeinflussung der Zeit wie schnell das abläuft entsprechend eingestellten LOD Target und erreichter Frames.

Hier habe ich mir ein paar Testmöglichkeiten ausgedacht.


Ok lassen wir diese Thematik. Ev. gibt es bei dem ein oder anderen doch Unterschiede die auf den PCs auf die ich bisher Zugriff hatte nicht aufgetreten sind.




Achtung, etwas was ganz wichtig bei solchen Aussagen wie Deiner ist, ist folgendes.

Innerhalb einer abwechslungsreichen Landclasscenery gibt es extrem unterschiedliche Belastungszustände. Wer jetzt ohne spezielle Testscenery eindeutige Vergleiche anstellen möchte, müsste sicherstellen, dass er beim Vergleich exakt die selben Flugzustände vorliegen hat.

Also identische Uhr / Tageszeit bei frisch aufgesetzten FS. Exakt gleiche Fluggeschwindigkeit, gleiche Höhe, gleiche Flugrichtung, gleiche Wolken, Sichtbedingungen, AI Traffic usw. identisches Laden von Addons, weiterhin keinerlei den FS störenden externen Prozesse.

Ich waage es zu bezweifeln, dass ein normaler Anwender dies alles bei seinen Aussagen berücksichtigt. Er wird also kaum stabile Zustände haben.

Ich habe dieses bei meiner Messreihe berücksichtigt.

Ich habe weiterhin mit einem Testmesh und einer speziellen Landclasstestscenery gearbeitet die im Gegensatz zu normaler Landclasscenery eine eindeutige Beurteilung über den aktiven MIP Level zulässt.


Es wurden zunächst alle anderweitigen Prozesse beendet. Nur noch der FS zeigte während der Messungen Aktivität.


Autogen AI Traffic und veränderliches Wetter usw. waren bei dem Test des Upper Frame Rate deaktiv. Keine anderweitigen Addons waren aktiv.

Es wurde auch nicht geflogen.

Der FS wurde im Slewmodus über eine gespeicherte Flugsituation aufgerufen.

Dann wurde ein extern eingeleiteter dauerhaft reproduzierbarer Koordinatensprung an immer die selbe Koordinate ausgelöst.

Die Bodenscenery ist dann schlagartig unscharf. Jetzt wurde gemessen wieviele Sekunden der FS benötigt um den höchsten MIP Level je nach eingestellten Upper Frame Rate zu erreichen. Diese Werte kamen in die Kurve.

Bestimmte Upper Frame Rate Werte und zugehörige Ladezeiten habe ich mir rausgepickt.

Nun wurden weiter Testa mit Upper Frame Rate auf unendlich bzw. auf begrenzten 90 Frames gemacht.


In dieser Messreihe wurden reale relativ konstante Lasten über geschlossene Wolkenschichten erzeugt. Geschlossene, da alles andere keine halbwegs stabilen Frames gewährleistet.

Über Anzahl der Wolkenschichten und dessen Höhe wurden Frameraten erzeugt die auch in der vorigen Messkurve auftauchen.


Es ergaben sich unter realen Lasten erstaunlich identische Ladezeiten, was aus meiner Sicht den Sachverhalt eindeutig bestätigt.

Anschliessend wurde das dann bei realen Flügen mit unterschiedlichen Fluggeschwindigkeiten getestet. Das selbe Ergebnis wie bei der Messreihe allerdings logischerweise nicht mit ganz so stabilen sauberen Kurvenverläufen.

Der Grundverlauf war aber identisch.

Dieser Kurvenverlauf selbst sollte bei allen Anwendern ähnlich sein. Sie verschiebt sich allerdings je nachdem wie die Gesamtperformance ist, bzw. wie andere Addons zu dem Zeitpunkt X das System gerade belasten.

Selbstverständlich wird dieses auch durch andere Prozesse die ev. nur hin und wieder laufen beeinflusst.

Der normale Anwender kann so etwas an der gemittelten angezeigten Framerate natürlich nicht beurteilen. Microruckler bekommt er an der Framerate nicht mit.
Er bemerkt sie aber optisch ev. im Flug.



Die Tests bezüglich LOD Target sahen anders aus.

Dazu konnte man einiges in diesem anderen Thread lesen. Ich habe später noch anderes ausprobiert speziell auch zu den 3D Wolken die keine sind. Alles ohne nachweisbare Funktion des LOD Target.