Nachladeschluckauf, Direct3D lost & High-DPI

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!

    Also bei mir finde ich sie nicht.


    Vermutlich braucht man das zweite Fenster und die dort enthaltenen Informationen. Wenn ich nämlich die Vollbildoptimierung bei mir deaktiviere, kann ich in OMSI weder Alt-Menü noch das ESC-Menü aufrufen...

    "Selten ein Schaden, wo nicht auch ein Nutzen ist."

    Zitat von Berlin&Brandenburg

    Also bei mir finde ich sie nicht.


    Vermutlich braucht man das zweite Fenster und die dort enthaltenen Informationen. Wenn ich nämlich die Vollbildoptimierung bei mir deaktiviere, kann ich in OMSI weder Alt-Menü noch das ESC-Menü aufrufen...

    Ich hab die Vollbildoptimierung deaktiviert und die Menüs sind in OMSI da. Da aber OMSI eh kein klassisches Vollbild hat, glaube ich nicht dass die Schaltfläche irgendeinen Unterschied macht.

    Kann es sein, dass die Schaltfläche mit der High-DPI-Einstellung nur angezeigt wird wenn man Bildschirme besitzt, die mehr als Full-HD unterstützen? Soweit ich weiß, wird erst ab 2k / WQHD von "High-DPI" geredet. Zumindest ab einer entsprechendenden Diagonale. Ich habe einen Bildschirm mit WQHD-Auflösung, also mit 2560x1.440px. Ich meine, dass es diese Einstellung auf meinem Notebook (1600x900) nicht gab (beide Windows 10).

    Gibt es die Option überhaupt unter Win 8.1?

    Nö, die Option gibt es auch bei keinen High-End Monitoren unter Windows 10

    Ich glaube die Option ist immer da, da man ja in jeder Auflösung skalieren kann. Und Menschen mit Sehschwächen werden je nach Bildschirm vielleicht auch bei 1080p manchmal skalieren wollen auf einem 13" Notebook...


    Ich betreibe meinen Bildschrim grundsätzlich mit 2560x1440, hab Skalierung aber global auf 100% eingestellt. Habe aber diese Option trotzdem dort, obwohl ich nicht skaliere.

    Zitat von Berlin&Brandenburg

    Ja, das wäre die Frage... Es kann gut sein, dass ich sie gar nicht habe. Oder es liegt wirklich an meinen beiden Monitoren. Die sind beide zwar baugleich, aber keine High-End-Geräte...

    Gibt es eine Checkbox, um die Skalierung bei hohen DPI-Werten zu deaktivieren?

    Ach guck, da gibts die Antwort: Windows 10 April 2018 Update: So ändert ihr die DPI-Einstellungen für klassische Win32-Anwendungen | WindowsUnited

    Nein, aber beantwortet anscheinend die Frage seit wann es diese Funktion gibt. ;-)

    Mal wieder zu den Nachladerucklern:

    Ich habe mir die Mühe gemacht und und aus vielen Repaints und auch sonst aus vielen Bussen die ganzen PNGs, JPGS und TGAs in DDS konvertiert. Anfangs auch Transparenzen und Scheiben, hab letzteres aber dann doch bei TGA belassen, denn zum Teil wurden hier die Dateien 16 und mehr MB groß im Vergleich zu 1 MB oder wenigen KB, während bei den Repaints selbst meist die Dateien erheblich kleiner wurden (vor allem im Falle von BMPs die zu DXT1-DDS wurden), in EInzelfällen wurden sie einen Tick größer als ursprunglich. Ist aber auch nicht schlimm. in der Summe bliebs gleich und die DDS Daten werden ja komprimiert im Speicher gehalten. Insgesamt gab es auch leichte Besserung beim Nachladen und vor allem seitdem echt keine schwarzen Busse mehr. Übrigens sind die Originaldateien immer noch in den Verzeichnissen der Fahrzeuge und ich habe bisher auch keine einzige Config oder CTI geändert, OMSI zieht sich automatisch vorzugsweise die DDS Texturen, sogar vor BMP.


    Mir ist aber aufgefallen, dass anscheinend auch der Bus mit dem man selbst fährt Einfluss auf das Nachladeverhalten hat. Mir ist ja schon klar dass es schwere und leichtere Busse was die Performance angeht gibt, aber ich bin immer davon ausgegangen dass die schweren eben auf die Frameraten drücken und nicht auf das Nachladen. Ich hatte in der gleichen Session bei Fahrt mit dem Citybus i280 schon einige arge Stotterer unterwegs vor allem wieder an den Kachelgrenzen, nach Umstieg dann in einen Solaris bei gleichen OMSI-Settings aber vergleichsweise butterweiche Fahrt. Also eventuell stören manche Scripte das Loading auch, allerdings ist der i280 kein Digitalmonster sondern eher ein alter analoger Bus mit wenig Systemen. Scriptmässig könnten aber die Soundscripts drücken, warum allerdings auf das NAchladen ist mir nicht ganz klar. Bei der Framerate würde ich es verstehen oder solche sekündlichen Stocker wie gewisse DFI-Anzeiger-Scripts verursachen (und keiner sich je deswegen beschwert hat...). Wobei ich die Soundscripts für nicht schwerer als die von Morphy halte.

    Servus

    Auch ich habe das 2. Auswahlfenster nicht, jedoch ein Feld "Skalierung bei hohem DPI Wert deaktivieren". Mache ich dort einen Haken rein ist alles in Omsi viel schärfer und selbst kleine Schriften (Strassenschilder, Ki-Bus Ziele, IBIS...) sind sogar auf Entfernung lesbarer geworden. Nur sind jetzt auch sämtliche Menüs in Omsi winzig geworden, das Umschalt-Z Menü ist sogar fast garnicht mehr lesbar weil es so klein ist. Omsi wird bei mir über meinen Fernseher (Bildschirmauflösung 3480x2160, 125cm Diagonale) auf die Glubscherl geworfen. Die Framerate ist minimal weniger geworden (25-27FPS statt 28-30), Omsi ist auf 30 begrenzt, aber die Nachladeruckler sind fast kaum noch vorhanden. Nehm ich den Haken wieder raus sind sämtliche Menü´s lesbar groß aber die Schriften im Spiel und auch die Grafik wieder leicht verwaschen. Auf den Kompatibilitätsmodus hab ich verzichtet denn da gabs keine unterschiede.


    Gibts da irgendeinen trick wie ich zumindest die Menü´s in gewohnter Größe bekomme ohne auf die schärfere Optik zu verzichten?

    Es grüßt der Chaos Lokführer 8o

    Nein, denn das wäre ja die Skalierung, und die betrifft in OMSI dann das ganze Bild. Leider hat damals keiner daran gedacht dass man die UI-Größe von der sonstigen Darstellung entkoppeln muss. Ein großes Problem bei älteren Spielen.


    Der nur geringe fps Verlust wundert mich garnicht. Ich bekomme fast gar keinen Unterschied wenn ich diverse Antialiasing-Geschichten einstelle. Ich glaube nur bei 2x2 Supersampling habe ich was gemerkt, was in etwa der gleichen Pixelmenge dann entspricht. War nicht viel, aber da es "nur" AA war war der kleine fps-Verlust in keinem Verhältnis zum Ertag, da ich mit anderen AA-Modi bei 0% Leistungsverlust ähnlich gute Ergebnisse erzielt habe. Bei nativen 4K ist der Mehrwert am Bild aber höher.


    Weiter zum Nachladen:

    Wieder habe ich den Framelimiter in OMSI rauf gesetzt, diesmal auf 41 oder gar 45 fps. Je mehr fps, desto erträglicher das Nachladen, da offenbar OMSI dann das gleiche zwischen den Frames geladen kriegt, bei mehr fps sind aber die Abstände natürlich deutlich kürzer. Die Limitierung auf klapp über 30 hat zwar so manchen Frameratensprung verhindert, aber wohl auch das Nachladen ausgebremst. Da ich Gsync einsetze sind aber Frameratensprünge fast irrelevant und nicht wahrnehmbar, ausser sie sind sehr hoch, daher ist glaub ich nun das Limit bei über 40 sinnvoller. Nebenbei fährt es sich mit 40 einfach viel besser als mit um die 30.


    Da bei mir auf machen Karten mangels Material leider keine AI-Varianten fahren können: wäre es nicht machbar in diesen Bussen statt z.B. Morphys ZF/Voith Sounds für den AI-Sound aus anderen Bussen Sound-Configs zu verwenden die "Leichter" sind? Ich meine unter sound_ai was einzutragen aus einem anderen Fahrzeug, also auch ohne den ganzen Krempel zu kopieren. Oder muss das immer im gleichen Ordner des Busses sein? Das könnte auch für Entlastung sorgen.

  • Moderator

    Hat den Titel des Themas von „Nachladeschluckauf & Direct3D lost“ zu „Nachladeschluckauf, Direct3D lost & High-DPI“ geändert.

    Nach der Erweiterung meiner AI List häuften sich wieder Freezes beim Nachladen gerade zu Spitzenzeiten. Klar ist glaub ich dass das ganze vor allem mit Bussen zu tun hat, weniger mit KI-Autos (außer man würde hier übertreiben). Allerdings ist die AI-Liste die ich hier erweitert habe auf Fikcyjny Szczecin eigentlich recht human: es fahren KI-Versionen der Stadtbus-MANs und M&R MANs rum, die recht bekannt sind dafür gut für den KI-Einsatz zu sein. Dann aber noch z.B. der Solaris II in der PL-Version, in der AI-List allerdings reduziert auf Voith-Varianten, damit ja keine ZF-Scripts noch die fps ruinieren, inklusive eigens reduzierten AI-Sound Configs, wo alles unnötige rausgeflogen ist. Leider ist da Fahrzeug trotzdem nicht ganz sauber, sieht man schön an den ganzen Meldungen in der Log, dass ein Haufen Texturen im Mesh entweder nicht eingetragen sind oder nicht mit der Modelconfig übereinstimmend, was glaube ich schon im Muttermodell "Solaris BVG" von Alterr der Fall ist. Könnte in der Summe nämlich auch OMSI überwordern, wenn z.B. an der Kachelgrenze gleich 4 Fahrzeuge der Sorte geladen werden. Allerdings habe ich im SPielbebetrieb "nolog" aktiv, um in solchen Fällen zumindest die Schreibzugriffe zu begrenzen. Ich weiss noch nicht ob ich mir noch die Mühe machen sollte mit einem Hexeditor in den o3d-Dateien die Texturzuweisung da wo es geht zu korrigieren, oder nicht... Für einen simplen Test ob es was bringt und wenn ja wie viel es bringt ist mir der Aufwand schon zu groß, deshalb würde mich da Eure Erfahrung interessieren. Nur zur Klarstellung: diese Busse spucken in der Log keine Fehler in den Scripts aus, sondern nur das übliche mit den Texturen. Könnte mir vorstellen dass das in der Summe reinhaut. Hier mal ein Beispiel:


    Mit einem Hexeditor und Prüfung der Modelldateien könnte ich da sicher 70-80% von beseitigen...


    Das andere was eine Rolle spielen könnte ist die Tatsache dass eigentlich jeder Bus davon eine andere andere Repaint-Textur hat. Vor allem weil in dieser Version sonst keine Wagenummer oder Kennzeichen möglich wären. 4 bis 5 verschiedene Repaints auf einmal an der Kachelgrenze könnten auch für Schluckauf sorgen, selbst wenn die SSD diese eigentlich mit links schafft, und auch wenn sie alle mittlerweile im dds Format vorliegen.


    Ein Test mit entrümpeltem Vehicles Ordner brachte übrigens nur ernüchterndes Ergebnis: nach vorübergehendem Rausschmiß von 70-80% des Inhalts verbesserte sich die Situation nur so minimal dass es man es zu Messfehlern zählen könnte. Ich weiss allerdings nicht ob vielleicht das simple Vorhandensein von vielen Repaints bei einem Bus und/oder vielen CTI-Dateien nicht auch eine Rolle spielt. Würd ich vielleicht demnächst testen... Glaub ich aber eher nicht.


    Etwas anderes teste ich momentan auch aus, wird aber etwas brauchen bis ich da konkret was zu sagen kann:

    Insbesondere wenn auf einer Karte viele Straßenbahnen und Züge zum Einsatz kommen, schnellt irgendwann die Anzahl der Fahrplan-KI nach oben, die dann ja auf die fps drücken. Das kennt ja auch jeder: nach dem Start von OMSI hat man in der ersten Runde gute fps, später wirds dann an gleichen Stellen geringer. Grund ist dass viele Fahrplan-Fahrzeuge in der Zwischenzeit geladen wurden und auch wenn sie nicht mehr zu sehen sind die Gesamtperformance belasten. Man kann das zwar insgesamt in den Optionen begrenzen durch den Regler "maximale Anzahl an Fahrplan-KI", allerdings hätte man je nach Karte unter Umständen irgendwann keine KI mehr die entgegen kommt, denn der große Trugschluss ist hier ja dass sich der Maximalwert auf die aktiven Kacheln bezieht. Tut er nicht, es gilt für die gesamte Karte! Und: ein Gelenkbus zählt doppelt, ein 3-fach-Gelenkbus dreifach und bei Bahnen kann sich nun jeder denken was das bedeutet. Und einmal geladen machen diese Fahrzeuge keinen Platz mehr für weitere, außer deren Tagesfahrplan ist zuende. Jetzt bin ich hingegangen und habe die Fahrpläne für Bahnen aufgeteilt, so dass sie nach einer Runde wirklich weg sind, so dass sie trotz einer Oberbegrenzung Platz machen würden für zig andere Busse. Ich bin mal gespannt... Denn eventuell macht es dann auch Sinn bei Buslinien Touren zu trennen die z.B. einmal morgens rausfahren und dann nachmittags, denn sie würden in der Zwischenzeit nicht gelöscht werden, selbst wenn sie ins Depot fahren. Reine KI-Linien könnte man auch entsprechend behandeln und so wertvollen Platz schaffen. Da muss ich aber noch über die Zeit beobachten.... Fakt ist dass ich normal gerne mal über die grenze von 200 Fahrzeugen geschossen bin, aktuell sind es dadurch um die 100.

    Zitat von wurstbrot

    Etwas anderes teste ich momentan auch aus, wird aber etwas brauchen bis ich da konkret was zu sagen kann:

    Insbesondere wenn auf einer Karte viele Straßenbahnen und Züge zum Einsatz kommen, schnellt irgendwann die Anzahl der Fahrplan-KI nach oben, die dann ja auf die fps drücken. Das kennt ja auch jeder: nach dem Start von OMSI hat man in der ersten Runde gute fps, später wirds dann an gleichen Stellen geringer. Grund ist dass viele Fahrplan-Fahrzeuge in der Zwischenzeit geladen wurden und auch wenn sie nicht mehr zu sehen sind die Gesamtperformance belasten.

    Grundsätzlich kann ich den Verlauf der Performance bestätigen und auch dass die einmal "gesehenen" Busse scriptmäßig irgendwie weitergeführt werden, selbst wenn sie nicht mehr sichtbar sind. Die Idee, dass die Fahrzeuge zum Ende ihres Umlaufs entladen werden, hatte ich noch nicht. Ich habe nämlich beobachtet, dass Busse oft einfach an der Kachelgrenze stehen bleiben.


    Also Beispiel: Ich fahre um 8:00 im X10 vom Zoo nach Teltow. Um 8:05 fahre ich über die Kachel X und weil ich zügig fahre, gerät ein Bus hinter mir aus dem Sichtbereich. Um 9:30 komme ich aus der Gegenrichtung wieder auf Kachel X an. Mir kommt jetzt ein Bus entgegen, der schon von außen als die Fahrt von 8:05 Uhr mit +85 Minuten identifiziert werden kann (z. B. weil das KI-Ziel nur 1x am Tag geschildert wird). Hilft das vielleicht für eine Experimente?