Omsi 2 FPS halbiert

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    1. Mit welchem Programm hast Du ein Problem? (Hauptprogramm, Editor, SDK Tools, etc.)

    >Omsi 2


    2. Bitte beschreibe das Problem so ausführlich wie möglich. Was ist passiert oder was hat vielleicht zu dem Fehler geführt?

    >Ich habe Omsi 2 gestartet und habe Grundorf gestartet und meine FPS haben sich halbiert also 30 FPS .Gestern war es nicht so meine FPS habe ich auf 60 begrenzt.


    3. Bitte füge Deinem Beitrag eine Log-Datei hinzu, entweder im Spoiler, Code-Block oder als Dateianhang.

    4. Falls es einen hilfreichen Screenshot des Problems gibt, kannst du ihn als Beitragsanhang mit hochladen und einfügen.


    5. Gib Deine Systeminformationen an, falls es sich um ein Performance-Problem handelt. (Betriebssystem, Prozessor, Grafikkarte, Festplattentyp, Arbeitsspeicher, etc.)

    >

    Scheint dieses Phänomen von OMSI zu sein. Begrenze mal deine FPS auf 120, dann sollten es wieder 60 sein.

    Zitat von PingPong

    Scheint dieses Phänomen von OMSI zu sein. Begrenze mal deine FPS auf 120, dann sollten es wieder 60 sein.

    Das ist aber in der Tat ein Phänomen. Ich hab (mittlerweile vor Jahren?) hier gelesen dass wenn man in OMSi die Framerate sagen wir mal auf 60 begrenzt, dann hat man generell niedrigere Durchnitts-fps als wenn man es auf ;Maximum belässt. Wohlgemerkt selbst wenn man die Grenze nicht erreicht. Konnte da snicht glauben, habs ausprobiert, und konnte das bestätigen. Mittlerweile, aber auch schon auf anderem System, sehe ich dieses Phänom nicht mehr. Also keine Ahnung wovon das abhängt...


    Grundsätzlich rate ich in OMSI die Begrenzung auf dem Maximum zu lassen und dann im Treiber oder RivaTuner auf was brauchbares zu begrenzen, und zwar auf das was man im Schnitt so auf seinem System und bei seinen Einstellungen in den meisten Situationen erreicht. 60 ist hier dann sicher ein guter Wert. RivaTuner glättet dann besser die Frametimes als der Treiber. Das fps Limit von OMSI ist grausam schlecht was das betrifft.


    Henry würd ich raten zunächst eben die fps-Begrenzung in OMSi hoch zu setzen und dann wieder in Grundorf zu schauen.

    Zitat von PingPong

    Scheint dieses Phänomen von OMSI zu sein. Begrenze mal deine FPS auf 120, dann sollten es wieder 60 sein.

    Vielen Dank hat funktioniert Danke Danke

    Auch dir Vielen Dank ich habe es schon vermutet das Es daran liegt :)

    wurstbrot das war vermutlich auch von mir mal. Mir ist das mal auf meiner leeren Testkachel aufgefallen, als ich mit den Optionen gespielt habe um der Grafikkarte bisschen Entspannung zu geben, da über 200 FPS die einfach unnötig Last fahren muss. Kurzerhand die FPS im Treiber begrenzt und OMSI wieder auf max. um diesen Ausnahmefall in den Griff zu bekommen und gut war.

    Kann gut sein;-D Aber auch seltsam dass ich das nicht mehr so beobachte. Ich hatte viel mit verschiedenen Arten der Begrenzung experimentiert um zu schauen wie sich da die Frametimes verhalten und dabei ist mir eben das nicht mehr aufgefallen. In OMSI ist es tatsächlich so dass mal in Stein gemeiselte Gesetze nicht ewig und vor allem nicht überall gelten, und man immer wieder alles hinterfragen muss. So hält sich bis heute die Mär man müsse als Texturspeicher 2/3 des Video-RAMs eintragen... Nun ja, 2012 machte es vielleicht Sinn, heute wäre das Unsinn XD

    • Neu

    0 ist unlimitiert ja. Nur ob das sInnvoll ist stelle ich mal in Frage. OMSI ist ein 32 Bit Programm, wenn man das also nicht limitiert könnte das bei Karten und Bussen die texturfressend sind schneller zum Problem werden als einem lieb ist. Der Gesamtspeicherverbrauch darf bei OMSI auf keinen Fall 2 GB ohne und 4 GB mit dem 4GB überschreiten. In der Praxis heisst es dass es knallen wird knapp über 3 GB Größe der OMSI.exe. Daher würde ich empfehlen da 2048 einzutragen wenn man an der kritischen Grenze ist. Sonst aber gerne 0.

    • Neu

    wurstbrot nun, nicht ganz so korrekt. Die Texturen werden nicht vom 32-Bit Prozess verarbeitet, sondern vom Treiber der Grafikkarte. Nun ist es so, dass jedoch der Prozess nicht mehr als 4 GB Adressieren kann, demnach findet ein sogenanntes Swapping statt, wo die überschüssigen GB im VRAM wieder in den System-RAM verschoben werden. Dabei werden dann große Texturen aus dem System-RAM gelesen, was möglicherweise dieses Stottern und das lange nachladen der Texturen verursacht, weil die Daten aus dem langsamen System-RAM, wieder mit dem VRAM ausgetauscht werden müssen.


    Bedeutet, man kann OMSI schon mehr VRAM geben, aber es lädt dann deutlich langsamer die Texturen und/oder es gibt diese Ruckler.


    Meinen langjährigen Beobachtungen zur Folge, ist bei 6 GB „VRAM“ Nutzung durch OMSI dann tatsächlich Ende. Effektiv werden für den Prozess nicht mehr als 4 GB Texturen tatsächlich zeitgleich Adressiert - das ist wiederum korrekt.

    • Neu

    Ja, ist möglich dass das so läuft. So genau weiss ich das auch nicht;-D Auf jeden Fall knallt OMSI knapp über 3 GB Größe der exe durch, und meiner Beobachtung nach liegt das zu 99% an den Texturen. Nach einer dds-Kur bei wirklich schlecht texturierten Assets bessert sich das ja signifikant, und bekannterweise werden dds Texturen auch komprimiert im Video RAM gehalten. Und dennoch hilft es um die exe am Aufblähen zu hindern. Mir scheint es fast als würde da immer was im System RAM vorgehalten werden an Texturkram. Und OMSI vergisst schlecht: ein einmal erschienener Bus bleibt im Speicher samt Texturen bis sein Umlauf (!) beendet ist.

    • Neu

    Ja, sicher. Wollte auch nicht sagen, dass du mit deiner Theorie grundsätzlich falsch liegst. Es ist nur technisches Wissen, gepaart mit Erfahrungen über die Jahre. Wer auf Nummer sicher gehen will, bleibt unter 3GB - ich habe über Jahre da mehr als 6 GB drin und es läuft in der Regel problemlos. :-) Möglicherweise ist in OMSI das auch per Hardcode begrenzt, denke aber eher nicht. Jedenfalls ist in der technischen Betrachtung die Omsi.exe nicht auf max. 4 GB belastet bei diesem Swap-Vorgang, in der Theorie macht das sinn. Es gab damals auch zu 32-bit XP-Zeiten schon die Möglichkeit, dieses Swapping zb. via USB-Stick zu ermöglichen, lief aber total Scheiße und war eher was für Technik-Nerds. :-D

    • Neu

    Zu 32 Bit Zeiten (OMSI 1...) hatte ich OMSi in eine RAM DIsk gepackt und das flutschte wie Eis XD Deutlich besser als von SSD. Mit OMSI 2 wurde das Loading schlechter, RAM DIsk hat da nicht mehr gelohnt...

    Ich würde aber wieder mal probieren und mit den Werten rumspielen für den Texturspeicher. Oft genug hab ich da Probleme mit der 3GB-Grenze der exe, vor allem bei AI Listen mit viel Variation und Repaints. Meinen Trick mit dem zerschneiden von Umläufen wende ich auch nur ungern an.