Beiträge von wurstbrot

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.

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

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.

Zitat von James O'Neill

Das klingt interessant. Magst du dazu vielleicht mal generell ein Tutorial erstellen? Würde sicher viele hier, inkl. mir, interessieren.

Es gibt bei YouTube eins für XPlane, das gilt analog eigentlich auch für OMSI. Da geht es vor allem um die Separierung der Threads auf einzelne Kerne. Hier muss man dann aber im Einzelfall gucken was sinnvoll ist für einen selbst. In meinem Fall macht z.B. Sinn ein Profil anzulegen und die OMSI.exe auf die zweite Hälfte der Kerne zu legen (Threads 8-15, Alle OS-Sachen, Virenscanner und Google Chromes etc auf 0-7 oder gar 0-4 / 0-2 je nach dem...), wobei ich immer noch nicht ganz sicher bin ob nicht gar jeden zweiten ab 8 dann wegen SMT. Dann gibts noch I/O Prioritäten die man festlegen kann, Speicherpriorität, und Prozesspriorität, hat aber meiner Meinung nach kaum bis wenig Auswirkung. Das alles ginge auch ohne Tool, aber wär äußerst mühselig mit dem Taskmanager, gerade für die ganzen im Hintergrund laufenden Prozesse, Hier kann man einfach alle markieren und denen Einstellungen zuweisen.

Hier der Link zum Tutorial:

Die schwarzen Busse sind übrigens doch nicht ganz weg, und ein paar Hänger gabs auch wieder;-D Ich wundere mich trotzdem was da denn passiert dass die OMSI.exe so radikal schrumpft...

OMSI nimmt doch die Auflösung vom Desktop, kann also theoretisch auch in 4K und mehr laufen...

Zitat von Marcel V.

Was mir in den Sinn kommen würde, ist die max. Speicherbedarf der hochauflösenden Texturen auf 8 GB ( 8192MB) hochschrauben oder den Kompatibilitätsmodus von OMSI - falls eine externe .exe angelegt wurde, auf Windows 7 einzustellen

Ein 32 Bit Programm wird alle Speicher zusammengezählt (RAM+Auslagerung+VRAM) nicht mehr als insgesamt 4096 MB nutzen können, auch nicht mit dem 4 GB Patch. Wie der Name schon sagt ermöglicht dieser bis zu 4 GB zu nutzen. Und da müsste man Glück haben, denn die Speicherverwaltung von OMSI ist schon überfordert mit viel weniger. Ich wüsste aber auch keinen Nachteil einer solchen Einstellung in der Praxis, nur bringen wird das nix.

Bei Bahnen jeglicher Art kann es sein dass die generell die Performance drücken, nicht nur dort wo man sie sieht. An vielen orten fällt es nur nicht auf weil die Performance ausreicht. Es scheint auch nicht davon abhängig zu sein wie oft wo eine Bahn fährt, sondern ob überhaupt irgendwann eine fährt. Örtlich sind es dann wiederum die Modelle der Bahnen und dass es Fahrplan-KI ist, also wie bei Bussen.

Möglicherweise hilft es auch den realrail-Eintrag in der Global zu entfernen, dann sollte man aber auch die AI-Liste von Bahnen befreien und dafür sorgen dass keine Bahn-Fahrpläne aktiv sind, in dem Fall also aus dem Fahrplan-Order verschieben.

Ob das grundsätzliche drücken auf die Performance abhängig ist davon ob realrail verwendet wird in der Karte oder nicht kann ich gerade nicht sagen, aber möglicherweise ja.

Die Partikel machen kaum bis garnix aus. Ich finde kann man ruhig bei 1000 lassen und auch für andere Fahrzeuge ankreuzen. Partikel in Reflexionen habe ich noch nicht getestet, aber hier könnte es Unterschiede geben. Einfach bei Regen ausprobieren und an- und ausschalten.

Grundsätzlich ist es so dass Darius zwar mitunter die performantesten KI-PKWs macht, aber seine Busse in der AI leider harte Brocken sind. Bei Problemen würde ich auch testweise andere einsetzen: zum Testen mal Spandau-MANs, auf dauer dann eben schauen was genau man nimmt. Wenn Du Bad Hügelsdorf hast könntest Du für die C2 testweise den dortigen C2 probieren, ich glaube für ihn gibt es auch Hamburger Repaints. Der Volvo ist glaub ich etwas genügsamer, aber sicher auch kein Performance-Wunder. Die Stadtbus-MANs kann man in den AI-Versionen nehmen, ebenso die Stadtbus-Urbinos, was aber beides eher nicht so zu HH passt, zumindest nicht in der Masse. Alters' O530 wäre auch ne Überlegung, aber wenn dann die ungemoddete Fassung, nix Ecomat/Ecolife etc.

Nachbarkacheln auf HH würde ich auf 1 belassen. So schlimm ist es nicht und bringt einiges. Der Öko-Modus mit dem Umschalten funktioniert meiner Meinung nach nicht zufriedenstellend, und kann Dir nach einem Wechsel der Sicht manchmal zurückfallen in mehr Kacheln, obwohl es beim Fahren schon auf 1 zurückgesprungen ist.

Und in einer dicht bebauten Stadt wie HH bei Bedarf maximale Objektentfernung runterschrauben. Das hat erheblichen Einfluss (weil es zählt nicht nur die Sicht nach vorne sondern auch nach hinten und in die Seitenstraßen. Hier liegt viel Einsparpotential was abgerufen werden kann.

Zu guter letzt: in Hamburg scheint mir alles was mit Bahn, Zügen, U-Bahnen etc zu tun hat enormen Einfluss auf die Performance der ganzen Karte zu haben. Das sollte das erste sein was man reduziert. Bin mir nicht sicher ob diese Dinge auf der letzten Fahrplanpriorität liegen sodass man nur eine Stufe runterschalten müsste, kann man sich aber so editieren.

Editier am Besten im Titel den Namen des Busses. "i280" nennt man eigentlich die Citybus i260/i280 Reihe von Bustrainz (Payware). Mich hat der Titel auch etwas irritiert, da ich zufälligerweise gerade auch mit den "Rollbändern" dort kämpfe, aber eben vom i260/i280 ;-D Ich meine dass die Freeware-Ikarusse sich einfach "Ikarus 260/280" nennen ohne das behelfsmässige kleine "i".

Schon bei den Repaints wird das immer durcheinandergewürfelt, und man weiss nie so recht für welche Version genau was ist, manchmal sieht man es erst an der der Ordnerstruktur nach dem Download.

Nachtrag 2:

Dass die Speicherverwaltung von OMSI sagen wir mal seltsam ist war mir ja bekannt. Dass es ohne virtuellen Speicher abschmiert auch (hatte das vor Jahren mal probiert). Gestern aber doch was sonderbares entdeckt: ich bin zur HVZ in Fikcyjny Szczecin gefahren, hatte mir dort nach X10 Vorbild die Verkehrsdichte in Lastrichtung erhöht mit separater AI-Klasse und wollte das ausprobieren. Nun ist vor allem meine Bus-AI da nicht gerade optimal, denn es scheint üblich zu sein für jeden Wagen ein separates Repaint zu machen, da sonst nicht mal die Kennzeichen angezeigt werden. Dann gibt es natürlich keine AI-Versionen der Busse sondern mit Morphy-Sounds und Getrieben versehene Busse, die als Spielerbus toll sind, in der AI allerdings suboptimal, und natürlich PNGs zu hauf. Ein schwarzer Solaris kam also relativ oft vor wenn viel unterwegs war. Ich habe aber während der Fahrt etwas in Process Lasso rumgedoktort (ein Tool welches in jedem wärmstens empfehlen kann, nicht nur für OMSI) und hab spaßeshalber bei OMSI.exe auf "Virtuellen Arbeitssepicher trimmen" geklickt. Eine Funktion die ich nie genutzt habe bisher, da ich das Tool eigentlich nur zum klaren separieren von Prozessen auf einzelne CPU-Kerne nutze, damit Spiel und Rest (OS etc) wirklich getrennt laufen. Ergebnis: OMSI.exe schrumpfte von etwa 1,4 GB auf etwa 150 MB (!), und ich erwartete sofort eigentlich einen Absturz. Aber nix, lief astrein weiter und wuchs dann erneut, aber vielleicht auf nur 600 MB. Irgendwann das Spielchen nochmal wiederholt. Im Spiel selbst nix negatives bemerkt, nur immer mal geguckt im Debug Fenster viele KI-Busse so aktuell rumfahren, es waren knapp 200. In dieser Spielsession kam mir danach kein einziger schwarzer Bus entgegen, völlig unnormal wo ich ja weiss wie suboptimal das eingesetzte Fahrzeugmaterial ist. Noch überraschender war aber dass an den Kachelgrenzen die Nachladeverzögerungen deutlichst geringer waren und eigentlich nur zu spüren waren in den Bereichen wo es vorher auch mal Freezes gab, aber dort war es auch nur noch minimal. Ich kam aus dem Staunen echt nicht raus, zumal ich glaube dass die Größe der Exe sich deshalb reduziert hat, weil das Tool Teile in den virtuellen Arbeitsspeicher verfrachtet hat, oder zumindest in einen Cache im RAM. Aber offenbar hat es Tante OMSI sehr gut getan. Selbst bei OMSI 1 hatte ich noch nie gesehen dass die exe so klein war.

Jetzt beobachte ich das mal längerfristig bevor ich mir wirklich die Mühe mache alle PNGs and TGAs anzugehen, oder es dann halt mache wenn ich richtig viel Zeit habe. Unabhängig davon lege ich jedem ans Herz das besagte Tool mal zu testen, gerade auf Systemen mit deutlich mehr als vier Kernen. Bei Ryzen 8-Kernern der ersten zwei Generationen zum Beispiel kann man so auch vermeiden dass OMSI (und auch Lotus) seine Threads auf beide CCX verteilt, aber alleine die Trennung beim Spielbetrieb bringt einiges. In GTA 5 habe ich so jeden verbliebenen Mikroruckler eliminiert, bei Xplane stabilere Frameraten und in OMSI auch paar FPS rausgekratzt vor allem in Momenten wo das Betriebssystem halt trotzdem meint irgendwas rumwurschteln zu müssen. Vor allem auf guten, vielkernigen Systemen bringts was, könnnte aber auch durch ähnliche Maßnahmen bei kleineren helfen.

Nachtrag:

Also die Große macht echt nix. Hab bei zwei bussen von 4096x1475 auf 4096x2048 hochskalliert, was mir sehr weh tat, aber auf 1024 runter wollte ich dann auch nicht. So viel Pixelverschwendung;-D Problem beim Skallieren war dass mir der Alpha der PNG erstmal flöten ging. Hab das per IrfanView gemacht und war mir nicht sicher welche Einstellung ich brauche beim Abspeichern des Zwischenstandes. Überhaupt sind PNGs mit Transparenzen für mich noch seltsam. Bei TGAs sehe ich in Photoshop zumindest den Alphakanal, bei PNGs kann ich manchmal nur raten. Dann hatte der Bus auf einmal keine Scheiben mehr;-D

Ich bräuchte also ein Tool bei dem ich direkt klipp und klar sehe ob da eine Alpha drin ist oder nicht, auch bei PNGs. DXTbmp hat ja einige Möglichkeiten, aber es skaliert automatisch runter, hätte also ohne zu fragen aus der Textur 4096x1024 gemacht, was ich nicht wollte.

Und dann gibt es ja noch bei den Alphas Unterschiede, ob die nur 1 bittig sind oder mit Abstufungen. Ist mir auch nicht ganz klar wie ich das erkennen soll.

Beim Zielformat würde ich natürlich gerne die kleinste Dateigröße vorziehen, aber da gibt es unterschiede. Ich denke für Häuser etc reicht DXT1 ohne Alpha, bei Bussen wäre es auch für Dinge aus dem Innenraum sinnvoll anstatt stur DXT3 oder DXT5 anzuwenden. Das wichtigste wäre aber die Außentextur: mach ich eigentlich DXT5, aber ist das nötig?

Ich glaube nicht dass dds bevorzugt wird aufgrund der Stellung im Alphabet. Hat man nämlich das gleiche mit bmp und dds, Verweis auf bmp in Modell und Config, nimmt sich OMSI trotzdem die dds. Also offenbar ist es das erste wonach es sucht, danach die anderen Sachen.

Und komischerweise reicht es nicht nur die benötigten Repaints zu bearbeiten. Wenn beim Ausgewählten Busmodell andere Repaints drin sind die aber aktiv nicht genutzt werden weder vom Spieler noch der AI Liste, lädt OMSI diese trotzdem gerne rein. Ich hatte auf Grunddorf einen Bus getestet bei dem ich die Bearbeitungen testen wollte und als ich mir die geladenen Texturen auflisten ließ kamen da Dateien zum Vorschein die garnicht relevant waren.

Zitat von Einsamer_Wolf86

Servus zusammen,

jetzt hab ich mich auch mal getraut Bad Hügelsdorf anzutesten, gleich zu Beginn mal den Linienwechsler 301/316, an nem Werktag um 7:22 ab Hildegardplatz mit dem A40. 3 volle Runden hab ich absolviert und kann mich folgender Passage anschließen:

Zitat von wurstbrot

Der 301 hat genug Fahrgastaufkommen um mit einem Gelenkzug bedient zu werden, da waren es hingegen beim 316 nur maximal 20, 25 Fahrgäste zeitgleich.

Die Ehrenrunde in Malg würde ich weiterhin dem 314 zuschlagen, welcher bei geraden Fahrten (2, 4, 6 etc.) über Malg, und bei ungeraden Fahrten (1, 3, 5 etc.) über den Wanderweg verkehrt. Anschluss vom Hbf kann man herstellen indem der 314 am Klinikum 2 Minuten nach dem 316 fahrt, und Richtung Stadttheater 2 Minuten vor dem 316 am Klinikum ankommt um einen Anschluss an den Hauptbahnhof zu gewährleisten.

Die Steigungen sind hinter Malg zum Schloß hoch auch nicht von schlechten Eltern, da musste ich den Karrn ordentlich treten bis ich dann mal oben angekommen bin, das ist maximalst etwas für einen gut motorisieren Solobus, aber nichts wo ich freiwillig nen Gelenkzug hochjagen würde...

Vor allem find ich ja das alte Schloß echt niedlich Das würd ich auf jeden Fall gegen etwas größeres austauschen dass auch 150 Stellplätze auf dem angrenzenden Parkplatz verdient, wobei das fast schon zu schade ist wenn es gänzlich im Nirvana verschwindet wenn es denn erstzt werden sollte.

Alles anzeigen

Ich beziehe mich nicht auf das Fahrgastaufkommen in OMSI selbst, denn das kann man ja steuern und einstellen wie man lustig ist. Mir geht es bei der Überlegung eher darum ob es zu einer Stadt wie "Bad Hügelsdorf" und den Gegebenheiten dort passt. Es ist und bleibt eine Klein- bis Mittelstadt mit Dörfern drumherum. Jetzt schau Dir mal die Fahrpläne in solchen Gegegenden an und den Fahrzeugeinsatz, auch in Touristengegenden. Sowas wie "Schloß" wird meist nicht mal mit einer einzigen Linie bedient, die Touris werden eher mit Reisebussen geshuttelt, und abends beim Ausgehen werden Taxen genommen und keine Linienbusse. Dennoch würde ich das Schloß mit einer Linie bedienen, nur eben dünner. Und an besonderen Tagen kann man Shuttles fahren lassen ohne Umwege. Ein dünnerer Takt heisst ja nicht weniger Fahrspaß, und komplett auf Gelenkbusse muss man ja auch nicht verzichten.

Die letzten Änderungen sind prima, vor allem die separate parklist und Überarbeitung der Privatauto-AI. Wenns weiterhin an bestimmten Stellen hackt im Laden (der große Kreisel vor dem Hauptbahnhof war ja auch so eine Stelle) könnte man auch hier überlegen zu separieren: für diesen Bereich könnte es helfen nie NormalCars auszuschalten und eine spezielle Klasse einführen, die in der AI List separat wäre und dünner belegt sein kann (oder auch nicht, kann man ja dann anpassen). Das würde auf manchen Systemen enorm dazu beitragen dass sich OMSI nicht verschluckt, ohne an anderen unkritischen Stellen die Vielfalt einzuschränken. Außerhalb der Stadt macht es nämlich überhaupt nix aus wenn einem ganz verschiedene Autos entgegen kommen, selbst aus den Halycon AI-Packs, was super Modelle sind, aber leider in kritischen Bereichen zu den Problemen erheblich beitragen würden.

Zitat von Lµkas

Das Problem beim Größen verändern ist halt auch, dass das Mapping verloren geht - oder man verzerrt die Textur, was Nachbearbeitungen schwieriger macht.

An sich kein Problem, denn gemappt aufs Modell wird sie wieder entzerrt. In Einzelfällen kann es aber tatsächlich problematisch sein. Dummerweise zerhaut mein Konverter jede Textur die mit "krummen" Auflösungen nach DDS exportiert wird. Würde eigentlich auch dazu neigen sie krumm zu belassen, daher geh ich auch lieber eine Stufe rauf um die Auflösung quadratisch zu machen, und runter nur wenn der Unterschied wenige Pixel sind.

Der Unterschied BMP - DDS ist eigentlich nur dass DDS komprimiert ist, und auch komprimiert im Speicher gehalten wird. BMP macht auch keine Probleme, verursacht nur überproportional große Datenmengen beim Laden, was bei den heute üblichen Texturgrößen eine Rolle spielt.

Es ist sogar noch einfacher: Ist eine gleichnamige DDS Datei im Verzeichnis vorhanden, nimmt OMSi diese bevorzugt, egal welche Endung in der Config eingetragen ist, im repaint oder im Modell. Man brauchts nicht mal löschen, außer man möchte den Speicherplatz nicht verschwenden... Sauberer wäre es dennoch wenn direkt DDS genommen werden würde und auch eingetragen. In OMSI 1 hat das zumindest paar Milli/Nanosekündchen ausgemacht und sich in der Masse bemerkbar gemacht. Eventuell erübrigt sich das aber mit Abschaltung des Loggens.

Ich hab ja Tools um sowas zu bearbeiten, kostet halt viel Zeit, da man doch immer gucken muss zum Beispiel ob die Texturen im Quadratischen Format sind. Konvertiere ich also direkt eine PNG mit 2048x1475 bekomme ich eine kaputte Textur. Die muss ich entweder auf 2048x1024 oder 2048x2048 wandeln. Und wie oft übersieht man da einen Alpha-Kanal, weshalb ich bei TGAs sehr vorsichtig bin. Mit viel Mühe geht das aber. Bei so Sachen wie Matrix würde ich mir das dann sparen.

Ähm ich könnte also `Texturen aus den Vehicles in den Textur-Ordner schmeißen wenn sie sich gleichen? Noch nie probiert;-D

Jetzt mal nach etwas länger:

Direct3D Device Lost kam nicht mehr vor. Denke das wird am Kompatibilitätsmodus liegen. Längere Freezes gab es schon, ich meine aber dass die KI-Autos hier die Übeltäter waren. Ich hatte in den AI Listen vereinzelte Halycon AI-Pack-Autos drin, aber eigentlich recht sparsam. Sie scheinen aber wirklich zu heavy zu sein für den AI-Betrieb. Die Kombination aus Spandau-Autos und Hamburg-Autos flutscht besser als auch wenn nur ein einziges Halycon-Auto in der Liste ist. Ohne diese kann ich fast die Menge verdoppeln. An manchen Stellen drückte eine Häufung dieser Autos sogar auf die fps um gut ein Drittel, was für mich nicht akzeptabel ist.

Sorgen machen mir noch einige Busse von denen es keine KI-Versionen gibt und Repaints die ganz wild png, jpg oder tga als Format nutzen, obwohl schon seit Jahren bekannt ist dass OMSI einzig und allein das dds Format liebt. Das wird nämlich auch die Engine überlasten, und genau diese Kandidaten sind dann mal eben schwarz aus der Entfernung. Möglicherweise verschluckt sich OMSI beim Laden manchmal auch daran.

Btw: "maximale Anzahl von Bussen" in den Optionen bezieht sich doch im Gegensatz zu den anderen AI Einstellungen auf den gesamten Verkehr auf der ganzen Karte, oder? Wenn ich z.B. 50 einstelle, fährt eben auch nur auf der ganzen Karte max 50 Solo bzw. 25 Gelenkbusse rum? Das ist schon wichtig für flächenmässig große Karten.

Zitat von Lenny21

Ist nämlich falsch. Man kann es "darstellen" bzw. demonstrieren, genau so wie 144 Hz. (In einem Slomo Video)

Und die Kamera mit der das gemacht wird läuft exakt mit der Frequenz wie just in der Millisekunde das abgefilmte? Und das Abspielgerät auf welchem man sich das anschaut auch? ;-D Nein...

Vsync verzögert nur die Bildausgabe um das Tearing zu verhindern. Das funktioniert auch, zulasten eines erheblichen Input Lags und Reduktion der Tatsächlichen Bildraten. Sinkt im 60 Hz Modus die Bildrate unter 30 fps, halbiert sie Vsync defacto auf 30, damit die Bilder wieder übereinstimmen bzw exakt teilbar sind mit der Bildwiederholfrequenz. Dreifach gepuffert ergibt das ein besseres Ergebnis 60->40->20 etc, der Lag wird aber noch größer. Bei Freesync und Gsync gibts das nicht, beziehungsweise erst wenn die fps höher sind als die Monitorfrequenz. Deswegen ist es ratsam dafür zu sorgen hier nicht über diesen Wert zu kommen und knapp drunter in-game zu limitieren.

Tearing ist aber nur das eine was man los wird mit G/Freesync. Die synchronisation der Frames mit der Bildwiederholfrequenz hat zu Folge dass das Bild geschmeidiger ist. Und das kann man eben nicht abfilmen, Tearing schon. Der Monitor läuft dann eins zu eins mit der Grafikkarte mit und ändert seine Frequenz entsprechend dauernd. Deshalb ist das "sync" hier wirklich synonym für synchron, während Vsync nur verzgört. Der Monitor läuft weiter mit der gleichen Frequenz, die Grafikkarte liefert ihm die Bilder so dass er bei voller Freqenz bzw den entsprechenden Teilern gut bedient ist. Mit "synchron" hat das wenig zu tun, ist aber in vielen Situationen besser als nix. Nachteil von Vsync sind auch enorme Sprünge der tatsächlichen Bildraten, die teilweise auch nicht von den Countern angezeigt werden. Sinkt man in einem Spiel von 60 auf 59 fps im Vsync Modus, macht man tatsächlich einen Sprung von 60 auf 30 bzw. 40 dreifach gepuffert. In Omsi sieht man dann zum Beispiel die Autos im KI Verkehr zwischendurch zittern, obwohl die fps augenscheinlich sich kaum geändert haben. Wäre Gync aktiv würde da nix zittern, da die Synchronisation das ausgleicht. Wäre aber ein "echter" enormer Sprung von zum Beispiel von jetzt auf gleich von 60 auf 40, würde man das auch merken. Abhilfe wäre hier OMSI auf einen sinnvollen, aber erreichbaren Wert über der Free/Gsync-Schwelle zu limitieren, z.B. zwischen 35 und 40 fps, je nach Karte. Gegen irgendwelche Mikroruckler die durch Skripte verursacht werden hilft aber alles nix.

Input-Lag bei OMSI:

Man könnte meinen bei OMSI spielt er keine Rolle. Tut er aber doch. Wenn man halbwegs Bildraten erreicht jenseits der 30 fps und das Spiel konstant läuft merkt man den Unterschied beim Fahren schon sehr, insbesondere in Gefahrensituationen wo schnelle Reaktion gefragt ist. Bei aktiven Vsync hat man das Gefühl der Bus würde einen Tick zu träge reagieren. Tearing hab ich im übrigen in OMSI seltenst gesehen, weshalb ich auf den Einsatz von Vsync in OMSI auch ohne G/Freesync verzichten würde. Vielleicht hat man welches wenn man öfters die Aussenansicht verwendet, keine Ahnung... Bei anderen Spielen ist Tearing ganz schön übel.

Zitat von Lenny21

Wenn man das Bild freezt, kann man es manchmal erkennen.

Wenn sich Deine Aussage auf Gsync oder Freesync bezieht: nein, auch dann nicht. Denn erstens ist die Aufnahme mit einer festen Bildwiederholrate und zweitens spielt es Dein Monitor ebenfalls mit einer festen ab. Du würdest keinen Unterschied sehen, auch nicht im Standbild. Es geht quasi nur mit eigenen Augen vor einem solchen Gerät. Wenn Du jetzt aber zum Beispiel in ein Geschäft gehst und es Dir zeigen lässt, musst Du schon sehr kompetente Verkäufer haben dass die Dir echt was präsentieren können z.B. einen mit / ohne Vergleich.

Übrigens geht der Effekt natürlich etwas flöten je höher die Bildwiederholrate ist. Bei 144 fps / Hz ist es natürlich weniger wahrnehmbar als bei 30 bis 60. Allerdings finde ich diese Technik perfekt eben für diesen Bereich, und finde es eigentlich sogar schade dass es nicht schon ab 20 greift.

Das hatte ich auch vor einer Weile nach einer längeren OMSI-Pause, bei mir scherte aber der Bus irgendwie dann immer etwas nach links beim aktivieren der Maussteuerung (bei mir mit Leertaste). Lösung war banal: im Alt-Menü rechts unten auf Steuerungen gehen und dort schauen dass keine andere Steuerungsart aktiv ist. Einfach da rumprobieren, dann sollte beim aktivieren der Maussteuerung über den Hotkey nicht diese seltsame Neuausrichtung passieren, die für das Problem sorgt, sondern der Stand von vorher beibehalten werden.

Doch, bei Office merkt man auch einen Unterschied, aber sicher nicht zwischen 60 und 75 Hz. Aber zwischen 60 und 120 oder 144. Vor allem beim Scrollen von Texten oder Verschieben von Fenstern etc.

In OMSI bringen mehr als 60 Hz nix, da OMSI in den allerwenigsten Fällen über 60 fps kommt. Dafür also einen Monitor anzuschaffen mit viel Hz bringt nicht viel. Allerdings bringt es schon was auf Gsync oder Freesync zu achten. Hier wird die Bildwiederholrate mit der Framerate synchronisiert und das macht einen spürbaren Unterschied, mal unabhängig davon dass dann Phänomene wie Tearing der Vergangenheit angehören. Allerdings ist hier darauf zu achten ab wie viel Hz/fps der Modus überhaupt greift. Meist ab 30 bei Gsync und ab etwa 40 bei Freesync. Je niedriger der unterste Wert ist wäre hier besser, da wir uns in diesen Bereichen meistens bewegen. Man muss dann auch dafür sorgen dass OMSI aber mindestens diese 30 fps liefert (oder wo auch immer die untere Grenze beim gekauftem Modell ist). Und wenn man nie Gsync oder Freesync in Anwendung gesehen hat, der kann es direkt sein lassen nach Videos zu suchen die das demonstrieren, denn es geht nicht, kann man nur direkt am Gerät sehen (oder besser gesagt fühlen). Im Falle von OMSI würde ich sagen man merkt es vor allem am viel geschmeidiger vorbei fahrenden Autos. Oder wenn die fps-Rate dann mal von 30 auf 29 springt und man wieder im normalen asynchronen Modus ist wie ohne diese Technik.

dds ist glaube ich sowieso aus den unterschiedlichsten Gründen das beste Format für Omsi, wenn ich da hand anlege würde ich das am liebsten dann direkt auch in dds umwandeln. Allerdings wie schon erwähnt, selbst beim löschen der bmps bleibt das Ergebnis das gleiche. Muss mal schauen, vielleicht fehlt da (dann bei der TGA...) der Alphakanal, aber ich glaube in dem Fall würde das doch auch ohne Nässe seltsam aussehen?

Interessant ist auch dass manche Markierungen bei Nässe ganz fehlen, andere wie hier die Gras-Textur haben (was wohl eher Durchsichtigkeit bis zum Boden ist...)

Gibt ein paar, aber erstmal teste ich das an folgender:

/Splines/Linie_poziome/P-10-6m_v2.sli

Gibt auch das gleiche als /Splines/Lodz/Linie_poziome/P-10-6m_v2.sli, aber im konkreten Fall wird auf die oben genannte zugegriffen.

Ist wohl irgendeine Kopie+Modifikation aus SimpleStreets schätze ich.