OMSI ruckelt stark trotz guter Grafikkarte

Wie oft soll das Problem denn hier noch Erläutert werden?! Benutzt doch einfach die Such Funktion und gib ein "Omsi ruckelt" - und wenn Du dir die Mühe machst und ein paar Threads durchschaust dann ist deine Frage bestimmt beantwortet

Omsi, ist wie bekannt, ein sehr CPU-Lastiges Programm.
Wo meine 3.8 GHz meines Prozessors voll ausgelastet sind, langweilt sich meine GTX550ti mit 10% zu tode.

Kurzfristig würde ich alle Hintergrundprogramme wie Skype und andere Clients schließen, damit sich der Prozessor mit der größt möglichen Leistung Omsi widmen kann. Bei der Grafik kannst du ruhig herrumprobieren. Nimm dir einen Nachmittag zeit, und versuche das Optimum der Einstellungen für dein System zu finden.

Längerfristug würde ich an deiner Stelle einmal mit dem Tast-Manager die Auslastung des CPUs überprüfen, und etvl. über einen neuen Prozessor nach denken. Omsi 2 wird auch nicht eine schwache CPU überspielen können

Servus,

Weil Omsi etwas unglücklich programmiert wurde, und eher auf die Simulation, als auf die Grafik geachtet wurde. Wenn wir schöne Regeneffekte und sonstige Grafische Spielereien hätten, würde die Grafikkarte auch mehr gefortert werden würden.

Zum Thema Prozessor:
Ein Pentium ist generell schon etwas älter, und leistungstechnisch nicht ganz das optimum. Ich würde zuerst schauen, welche Sockel dein Prozessor/Mainboard hat: Angenommen es ist der 775er Sockel: Hier würde nur ein Core2 3.0 GHz Quadcore in Frage kommen. Sollte es ein 1155er sein, vergiss den letzten Absatz und greif zu einem I5 4670...

Ich würde aber eher in ein neues AM3+ Mainboard (meines mit USB3 um 50€) und in einen Starken AMD investieren (z.B: FX4170/61x0)
Ich hab mit meinem "alten" FX4100 eigentlich nie mit der Performance Probleme. Wenn du Intel treu bleiben willst, käme nur ein I5 in Verbindung mit einem Intel-Mainboard in Frage. Jedoch kommt das um einiges teurer...

Zitat

Wieso macht M-R Software aber das es eher CPU auslastend ist?

Zitat

Weil Omsi etwas unglücklich programmiert wurde, und eher auf die Simulation, als auf die Grafik geachtet wurde.

Das hat weniger mit vernachlässigter Grafik zu tun. Im Gegensatz zur Zugsimulation muß in einer Bussimulation wesentlich mehr berechnet werden. Die Zugsimulation besteht aus einer Strecke mit KI-Verkehr. Links und rechts passiert nichts nennenswertes.
Bei einer Bussimulation ist aber in allen vier Himmelsrichtungen bis zu gewissen Entfernungen KI-Verkehr (mit und ohne Fahrplanberechnung), und Passanten etc. ständig zu berechnen. Würden jetzt hier noch aktuelle Grafikdarstellungen hinzukommen würden eine ganze Reihe von Usern mit ihren Fußhupen als PC einpacken können. Soll heißen: Man kann froh sein, dass Omsi derzeit auch auf älteren PCs noch läuft.

Wobei man sagen muss dass es weniger an dem Aspekt hängt, dass OMSI auf "Simulation" programmiert wurde. Mit Multithreading kann man hier einiges herausholen, sodass mehrere Dinge gleichzeitig berechnet werden können. Ein Thread (oder zwei) werden das an sich nicht packen um die ganzen Berechnungen durchzuführen. Bei mir wird immer nur ein Kern auf 100% getrieben, die anderen beschäftigen sich derweil mit Elektronen zählen...

Trotzdem: Dein Prozessor ist etwas schwach auf der Brust. Zu hohe Grafikeinstellungen führen ebenfalls zu mehr Berechnungen die den Prozessor betreffen. Das merkt man sehr, wenn man sich mal die Prozessorauslastung anschaut. Vielleicht kann man OMSI auch eine höhere Priorität zuweisen oder über den TaskManager anordnen, dass OMSI auf z.B. Kern 2 ausgeführt wird. Hat aber (für mich) keinen merklichen Effekt gebracht.

Zitat von FranzBauer

Wobei man sagen muss dass es weniger an dem Aspekt hängt, dass OMSI auf "Simulation" programmiert wurde. Mit Multithreading kann man hier einiges herausholen, sodass mehrere Dinge gleichzeitig berechnet werden können. Ein Thread (oder zwei) werden das an sich nicht packen um die ganzen Berechnungen durchzuführen. Bei mir wird immer nur ein Kern auf 100% getrieben, die anderen beschäftigen sich derweil mit Elektronen zählen...

So einfach ist es nun auch wieder nicht. Bestimmte Dinge müssen nacheinander berechnet werden, weil das Ergebnis der vorhergegangenen Berechnungen bekannt sein muss. Wie will man zum Beispiel die Kollisionsabfrage und Berechnung der Bewegungen der KI parallelisieren? Die Kollisionsabfrage muss warten, bis die Positionen der KI-Autos berechnet wurden. Anderes Beispiel: wie soll das Spiel die Belastung der Stoßdämpfer berechnen, ohne Geschwindigkeit, Beschleunigung, Lenkeinschlag usw. vorher berechnet bzw. vom User-Eingabegerät abgegriffen zu haben? Vor allen Dingen, wenn man zu Beginn der Entwicklung nicht schon Planungen für eventuelle Parallelisierungen angestellt hat, ist das Auslagern bestimmter Methoden in eigene Threads extrem kompliziert und mit großen Änderungen verbunden.

Zitat

[...] habe die Grafikkarte HD 8650 [...] Intel Premium CPU G620 [...]

Wie genau bist du denn an eine HD8650G-GPU gekommen? Normalerweise ist die nur in den AMD-APUs verbaut. Von daher kann diese Information eigentlich nicht richtig sein. Lade dir mal GPU-Z herunter und schau, was der dir als Grafikchip anzeigt. Desweiteren heisst es "Intel Pentium"

Zitat

Du kannst noch probieren deine Grafikkarte zu übertakten.

Wenn die CPU der limitierende Faktor ist, macht es überhaupt keinen Sinn, die Grafikkarte zu übertakten.

Zitat

Bestimmte Dinge müssen nacheinander berechnet werden, weil das Ergebnis der vorhergegangenen Berechnungen bekannt sein muss.

Klar, aber z.B. das nachladen von Kacheln, das Rendern der Spiegel und z.B. Sound können parralel ablaufen. Dazu können noch Schatteneffekte, Reflexionen von z.B. Passanten mithilfe der Positionsdaten parralel ausgeführt werden.

Zitat von FranzBauer

Klar, aber z.B. das nachladen von Kacheln, das Rendern der Spiegel und z.B. Sound können parralel ablaufen. Dazu können noch Schatteneffekte, Reflexionen von z.B. Passanten mithilfe der Positionsdaten parralel ausgeführt werden.

Jain. Man müsste abwägen, ob die von dir genannten Dinge sinnvoll sind. Die Auslagerung von Schatteneffekten, Reflexionen usw. würde z.B. keinen Sinn machen. Was würde es bringen, 50 mal in der Sekunde die Schatten zu berechnen, wenn nur 25 Bilder pro Sekunde gerendert werden? Das wäre verschwendete CPU-Zeit. Zumal der Thread während des eigentlichen Render-Vorgangens angehalten werden müsste, damit sich während des Rendervorganges nichts mehr an den Daten verändert. Sonst könnte es zu Phänomenen kommen, die an Tearing errinern. Gleiches gilt auch für das Rendern der Spiegel. Und wenn die Threads alle aufeinander warten müssen, ist der Geschwindigkeitsvorteil ganz schnell wieder eingestampft

Allerdings hast du Recht, wenn du sagst, dass es Sinn macht, Dinge wie das Nachladen der Kacheln in einen eigenen Thread auszulagern. So wie ich MR verstanden habe, ist dies in OMSI 2 auch bereits geschehen. Allerdings wird das nicht unmittelbar mehr FPS bringen - eigentlich werden dadurch eher die kleinen und großen Ruckler vermieden, die sonst durch das Nachladen von Kacheln entstanden sind.