Auch, wenn das Thema in verschiedenen Foren schon öfter angesprochen wurde, möchte ich dieser Problematik ein eigenen Thread widmen.

Und zwar geht es um die CPU-Auslastung beim OTTD Spielen.

Ich spiele OpenTTD MiniIn r8928, welches ja bekanntlich PBS unterstützt - bis heute Fehlerfrei.

Ich spiele eine Karte in 2048x2048 mit meinem Intel Centrino Duo T2250 2 Kerne á 1,73 Ghz bei Tageslänge 20.

Seit einigen Monaten (im Spiel) ist mein Spiel auffällig Langsam und ruckelig geworden. Ich habe vor einigen Jahren mit PBS angefangen zu spielen, habe es mit der Zeit dann auf der ganzen Karte eingeführt.

Mittlerweile ist das Spiel unschön langsam geworden.

Ein Teil dessen ist zweifelsohne auf PBS zurückzuführen, jedoch hab ich in ziemlich kurzer Zeit eine massive Performance-Einbußen festgestellt. Testweise habe ich mal PBS ausgemacht, es lief deutlich flüssiger - gut, beim Einschalten gab es dann gleich 654 Tote - Zusammenstoß 2er Züge auf einer eingleisigen Strecke (zum Glück vorher gespeichert )

Dann beschäftigt mich noch eine Frage zur Performance von PBS:
PBS ist ja sehr Recourcenhungrig, wodran liegt dies?
a) an der Anzahl der Signale?
b) an der Anzahl der Fahrten, welche gerade innerhalb eines PBS-Blocks verkehren?
c) an der Anzahl der Felder, welche von PBS-Signalen begrenzt werden (also der Abstand zwischen 2 Signalen)

Zu dem Thema hab ich mich schon einmal geäußert, die Frage im TT-Forum bzgl. der MultiCore-Fähigkeit ist leider noch nicht gestellt.

Link zum Beitrag

Screen mit CPU-Auslastung

Aktueller Speicherstand

Meine config.cfg (NewGrf beachten)

PBS ist dreckig programmiert und hängt von der globalen Wegfindung ab. Darum ist es auch noch nicht "im Trunk".

Könnte es nicht auch an der Anzahl der Fahrzeuge, Flugzeuge etc liegen? Muss ja alles irgendwo irgendwie berechnet werden.

Indirekt ja. Es liegt an der Kombination von übergroßen Karten und dieser globalen Wegfindung. Wie der Name andeutet, wird der Fahrweg komplett bis zur nächsten Station berechnet, und kontinuierlich, weil sich durch Baumaßnahmen ja was ändern könnte.
Bei TTD wurde der Weg nur 64 Felder im voraus berechnet und die restliche Orientierung erfolgt nach Luftlinie. Bei den kleineren Karten reicht das meistens, aber trotzdem verfahren sich Züge manchmal. Deswegen wurde diese globale Wegfindung eingeführt, was aber ja ein Flop war.

Ist das ein Hinweis darauf, dass man YAPF für Züge ruhigen Gewissen deaktivieren kann um CPU Last zu speichern?

RK schrieb:Wie der Name andeutet, wird der Fahrweg komplett bis zur nächsten Station berechnet, und kontinuierlich, weil sich durch Baumaßnahmen ja was ändern könnte.

Dies würde also für die von mir erdachte Option c) bestätigen.

Ich habe eingleisige Strecken, die ich eine Zeit lang mit PBS ausgerüstet hatte. Ist eigentlich eine feine Sache. Nur die Rechenlast wurde dadurch massiv in die höhe gezogen, wie ich nach Rückbau auf normale Signale festgestellt hatte.

Gibt es hier wen, der sich mit der Programmierung von PBS im MiniIn auskennt? (zumindest ein klein wenig)

Ich habe vorhin ein wenig im TT-Forum nach PBS im MiniIn umgesehen, konnte aber nur wenige Hinweise auf die Probleme finden. Es wurde nur gesagt, dass es unordentlich programmiert sei und die dev's es nur mit geringerer Priorität weiterentwickeln bzw weiter nach hinten stellen.

An der Anzahl der Fahrzeuge könnte es theoretisch auch hängen, nur hat das Spiel angefangen zu ruckeln, als ich nur Gleiskörper bearbeitet habe und nicht großartig an den Fahrzeugen gebastelt habe. Zur Info:
520 Züge
32 Straßenfahrzeuge
104 Schiffe
126 Flugzeuge

Ist die neue globale Wegfindung für die Schiffe eigentlich auch so rechenintensiv wie die für Züge?
YAPF für Schiffe funktioniert ja nicht, da fahren die Schiffe nur auf einem Fleck hin und her.

Der_Paul schrieb:Ist das ein Hinweis darauf, dass man YAPF für Züge ruhigen Gewissen deaktivieren kann um CPU Last zu speichern?

YAPF (Schon wieder eine Wegfindung) ist der neue Ansatz um eine effiziente Wegfindung zu entwickeln.

Bei Schiffen läuft diese aber Amok und erzeugt auch viel Rechenlast. Jedenfalls war das so als ich letztes Mal Schiffe verwendet habe.

Und wie is die neue globale Wegfindung bei Schiffen? Viel oder wenig Rechenlast?

Also als erstes wäre es gut, aufzuhöhren verschiedene Wegfindungen miteinander "verbal" zu kombinieren. Bei Flugzeugen hast du immer eine bestimmte Luftlinie, die x-bleliebige Flugzeuge gleichzeitig fliegen können.
Bei Straßenfahrzeugen geht dies nicht, da nur auf Straßen/Tramwegen gefahren werden kann. Auch können hier nur eine bestimmte Anzahl Fahrzeuge "mitmachen". Zudem muss noch eine etwailige überhohlung miteinberechnet werden .
Bei Zügen fällt dann die Überhohlung weg, dafür gibt es 4 (mit PBS 5) verschiedene Signale, die nochmal extra berechnung brauchen (Einfahrt / Ausfahrt mal 200 gibt schon gut rechenlasst).
Und dann gibt es Schiffe, die auf direkten (Manhatten) Weg selten ans Ziel kommen. So haben sie einen direkten 360° Radius um zu agieren. Hierbei den richtigen Weg zu finden, tile per tile, ist eine ganz Andere Sache.

Also bitte höhr auf eine Wegfindung mit einer Anderen zu vergleichen, sie folgen alle unterschiedlichen Bedingungen.

RK schrieb:PBS ist dreckig programmiert und hängt von der globalen Wegfindung ab. Darum ist es auch noch nicht "im Trunk".

DragonGuard schrieb:Dies würde also für die von mir erdachte Option c) bestätigen.

DragonGuard schrieb:c) an der Anzahl der Felder, welche von PBS-Signalen begrenzt werden (also der Abstand zwischen 2 Signalen)

Nein! Sicherlich hat alles einen Einfluß: Anzahl der Züge/Schiffe/., Menge der Weichen, wieviele Gegner, etc, etc, etc .
Trotzdem hat RK Recht. Wärend du alle Kriterien einzeln verdoppeln kannst ohne Performenzstörungen zu merken, reichen schon wenige PBS Signale zum Einbruch.

DragonGuard schrieb:Ich habe eingleisige Strecken, die ich eine Zeit lang mit PBS ausgerüstet hatte. Ist eigentlich eine feine Sache. Nur die Rechenlast wurde dadurch massiv in die höhe gezogen, wie ich nach Rückbau auf normale Signale festgestellt hatte.

Im Nachhinein die eigene Frage selber zu beantworten .

DragonGuard schrieb:Gibt es hier wen, der sich mit der Programmierung von PBS im MiniIn auskennt? (zumindest ein klein wenig)

Sicher, zB ich. Hänge schon seid ner Weile dran, habe auch schon einen "interessanten" Code, den willst du aber nicht spielen.

DragonGuard schrieb:Ich habe vorhin ein wenig im TT-Forum nach PBS im MiniIn umgesehen, konnte aber nur wenige Hinweise auf die Probleme finden. Es wurde nur gesagt, dass es unordentlich programmiert sei und die dev's es nur mit geringerer Priorität weiterentwickeln bzw weiter nach hinten stellen.

Das lobe ich mir. Selber zu suchen, und nicht jedesmal jemanden ne PN zu schicken/ nen neuen Thread aufzumachen, respekt! Aber dennoch: RK hatte dies schon gepostet und er tut dies bestimmt nicht ohne Grund.

DragonGuard schrieb:An der Anzahl der Fahrzeuge könnte es theoretisch auch hängen, nur hat das Spiel angefangen zu ruckeln, als ich nur Gleiskörper bearbeitet habe und nicht großartig an den Fahrzeugen gebastelt habe. Zur Info:
520 Züge
32 Straßenfahrzeuge
104 Schiffe
126 Flugzeuge

Siehe meine vorigen Kommentare. Sicherlich könntest du 100 Züge weniger nehmen anstatt 2 PBS-Stellungen zu ändern, wenns dir so besser gefällt .

DragonGuard schrieb:Ist die neue globale Wegfindung für die Schiffe eigentlich auch so rechenintensiv wie die für Züge?
YAPF für Schiffe funktioniert ja nicht, da fahren die Schiffe nur auf einem Fleck hin und her.

Siehe meinen Eingangskommentar.


Gruß,
BamBam


Edit

DragonGuard schrieb:Und wie is die neue globale Wegfindung bei Schiffen? Viel oder wenig Rechenlast?

NPF und YAPF sind zwei unterschiedliche Wegfindungen, wie der Name schon sagt.

Nicht ohne Grund musst du um PBS im MiniIN zu nutzen das Eine deaktivieren und das Andere aktiviern.


Edit2: das du dich selber immer auf abwesend stellst, wärend die Leute versuchen deine Frage zu beantworten, empfinde ich als "Fragwürdig", oder bist du jetzt ne Woche auf den Malediven (und auch dann wär es interessant, warum du direkt vor Abfahrt eine Frage stellst .)

BamBam schrieb:Also bitte höhr auf eine Wegfindung mit einer Anderen zu vergleichen, sie folgen alle unterschiedlichen Bedingungen.

BamBam schrieb:Im Nachhinein die eigene Frage selber zu beantworten .

Ich habe die Fragen hier reingestellt, um zu versuchen, PBS verstehen zu lernen. Zu dem Zeitpunkt hatte ich die Strecken ja mit PBS ausgerüstet und später dann die Strecken Signaltechnisch auf nicht-PBS-Signale Rückgebaut und dann hier meine Erfahrungen gepostet, damit auch andere davon Profitieren können.

BamBam schrieb:Sicher, zB ich. Hänge schon seid ner Weile dran, habe auch schon einen "interessanten" Code, den willst du aber nicht spielen.

Ich werde ihn sicher spätestens dann spielen, wenn du ihn in deinem Nightly eingebaut hast

BamBam schrieb:NPF und YAPF sind zwei unterschiedliche Wegfindungen, wie der Name schon sagt.
Nicht ohne Grund musst du um PBS im MiniIN zu nutzen das Eine deaktivieren und das Andere aktiviern.

Ist mir schon klar

BamBam schrieb:Edit2: das du dich selber immer auf abwesend stellst, wärend die Leute versuchen deine Frage zu beantworten, empfinde ich als "Fragwürdig", oder bist du jetzt ne Woche auf den Malediven (und auch dann wär es interessant, warum du direkt vor Abfahrt eine Frage stellst .)

Danke für den Hinweis, hatte Vergessen, mich nach der Klassenfahrt wieder auf Anwesend zu stellen

DragonGuard schrieb:Danke für den Hinweis, hatte Vergessen, mich nach der Klassenfahrt wieder auf Anwesend zu stellen

DragonGuard schrieb:Ich werde ihn sicher spätestens dann spielen, wenn du ihn in deinem Nightly eingebaut hast

Das kann (leider) noch dauern .

DragonGuard schrieb:und dann hier meine Erfahrungen gepostet, damit auch andere davon Profitieren können.

Okay, dann hab ich deinen Text etwas falsch verstanden.

Gruß,
BamBam

1) BamBam, wenn Dein Code testbar ist. denk an mich

2) PBS hat z.B. in der Rev3464 noch perfekt funktioniert! Schaut Euch Save Bergig6 an! Große Karte, viele Züge.
leider habe ich das letzte, große, echte 3464er-Save nicht mehr, da es mit Mini_In-Final wieder spielbar war, habe ich weitergespielt (wie ist das eigentlich möglich?). Allerdings musste ich feststellen, das es nach einiger Zeit mächtig anfing zu hängen. Das lag aber weder an der Anzahl der Züge/Signale, noch an dem Savegame selber, das lag an dem Mini_In. Angeblich soll das Mni_In vom 31.12. besser mit PBS klarkommen, konnte es noch nicht testen. Das würde aber bedeuten, das die PBS-Probleme nicht aus dem 'angeblich dreckig programmierten' PBS kommen, sondern andere Ursachen haben könnten!

Bernhard schrieb:1) BamBam, wenn Dein Code testbar ist. denk an mich

Wie gesagt, macht euch nicht zu früh hoffnung.

Bernhard schrieb:2) PBS hat z.B. in der Rev3464 noch perfekt funktioniert! Schaut Euch Save Bergig6 an! Große Karte, viele Züge.
leider habe ich das letzte, große, echte 3464er-Save nicht mehr, da es mit Mini_In-Final wieder spielbar war, habe ich weitergespielt (wie ist das eigentlich möglich?).

Den alten Code kannst du aber nicht mehr nehmen. Zuviele Änderungen im Original Code. Ich muss zB bei mehreren Patchen die ich nutze schon wieder Änderungen machen, da sie sonnst nicht laufen würden. Und das sind nur ein paar Rev. Nummern unterschied.

Gruß,
BamBam

Hallo,

ich habe festgestellt das, sobald ich mit, wie hier schon geschrieben: einer Wegfindung ausgestellt um PBS zu nutzen Schiffe baue wird alles so dolle langsam das selbst auf einer 1024xs1024 absolut wenig geht. Wenn mein Streckennetz gut ausgebaut ist. Im Schnitt mit etwa 250 Zügen.

Um das zu vermeiden baue ich grundsätzlich PBS wirklich nur dann wenn es sich wirklich nicht mehr anders lösen lässt. Komplexe kreuzugen in Besiedelten gebieten beispielsweise, wenn die Städte Explosionsartig innerhalb von ein paar Jahren auf 25 000 und mehr anwachsen.

Weiter arbeite ich mit sehr viele Wegpunkten. Teils überfahren manche Züge innerhalb auf einer Strecke von 2-3 Screens in ner 1280x1024er auflösung 5-6 Wegpunkte. Das gleiche verwende ich auch bei komplett abgeschalteter Wegfindung für Schiffe. Weiter, das einzige wo ich schiffe wirklich effektiv nutze ist bei Ölbohrinseln!

Mit einem AMD 2800+ mit 1024 MB Ram spielt sich so ein Spiel selbst mit 1000 Zügen bei einer Kartengröße von 1024x1024 alles Wunderbar. - einzig Was ich nicht spiele sind die ganz großen Karten mit 2048x2048. Mir sind hierbei dann die Savegames einfach viel zu groß und da ich sehr oft Speichere, so alle 2-3 Monate kommen bei ner gespielten Karte so an die 2,4 GB zusammen!

Ich weiss jetzt nicht ob sich das mit Bam Bams aussage deckt, da er doch um einiges mehr weiss über Trans. als ich. Aber ich will es einfach mal niederschreiben um vielleicht einfach eine vernünftige Wegführung über sehr viele Trackpoints auch vorteile haben können.

Weiter teile ich auch Personen und Güterverkehr, was sich bei einem dennoch insich gekoppelten Netzwerk von gleisen nur über Trackpoints machen lässt. SO habe ich zumindest einen erheblichen Performance gewinn nicht nur im Spiel, sondern auch Vom spiel. - so zumindest mein Eindruck.

ABER: wenn man mal bedenkt das Transp. früher auf meinem 486/DX2 sehr gut lief und heute auf meinem Laptop nicht (Pentium Clereon 500 Mhz) ist das schon ein Phänomen für sich!

Grüße

>ABER: wenn man mal bedenkt das Transp. früher auf meinem 486/DX2 sehr gut lief und heute auf meinem Laptop nicht (Pentium Clereon 500 Mhz) ist das schon ein Phänomen für sich!

da haste aber unter MS-Dos gespielt! jetzt klaut Dir Windows einfach zu viel Performance!


Frage an BamBam. Wenn ich, wie Sacki schreibt, alle (ich sag mal) 20 felder einen Waypoint einbaue. rechnet der Compi dann jeweils nur den Weg bis zum nächsten Waypoint? Oder schaut er trotzdem wie er bis zum Ziel des Fahrplans kommt? Könnte man ggf, durch eine andere Anordnung der Bahnhöfe/Haltepunkte im Fahrplan was verbessern?

Wo wir gerade bei Methoden sind, die die CPU zum qualmen bringen. Wie böse sind die Einstellungen bezüglich der Bahnhofgröße? Da steht ja bei, kann das Spiel verlangsamen. Tut es das generell, wenn ich dort große mögliche Bahnhöfe eingestellt habe, oder erst dann, wenn ich wirklich einen großen Bahnhof gebaut habe?

Ne, also, TTDPatch braucht auch deutlich mehr Rechenpower im vergleich zu Plain-TTD

Sacki schrieb:Das gleiche verwende ich auch bei komplett abgeschalteter Wegfindung für Schiffe.

Na, dann erklär mal wie du das machst. Muss man aber schon verdammt viel Code löschen und dann ändern, das der parser sich nicht beschwert.

Sacki schrieb:da ich sehr oft Speichere, so alle 2-3 Monate kommen bei ner gespielten Karte so an die 2,4 GB zusammen!

Autosave an und auf "Monatlich" stellen. So hast du max. 16 Saves, die dann wesentlich weniger Platz einnehmen. Und "normales" Speichern nur bei bestimmten Stellen.

Sacki schrieb:ABER: wenn man mal bedenkt das Transp. früher auf meinem 486/DX2 sehr gut lief und heute auf meinem Laptop nicht (Pentium Clereon 500 Mhz) ist das schon ein Phänomen für sich!

Warum? "Damals" hast du TT oder TTD oder TTD-Windowsversion gespielt. OpenTTD ist ein eigenständiges Programm. "Damals" habe ich auch SimCity auf dem 286er gespielt. Irgendwie lässt sich dort SimCity4 nicht installieren. Gelle

Bernhard schrieb:Frage an BamBam. Wenn ich, wie Sacki schreibt, alle (ich sag mal) 20 felder einen Waypoint einbaue. rechnet der Compi dann jeweils nur den Weg bis zum nächsten Waypoint? Oder schaut er trotzdem wie er bis zum Ziel des Fahrplans kommt? Könnte man ggf, durch eine andere Anordnung der Bahnhöfe/Haltepunkte im Fahrplan was verbessern?

Denke mal du meinst mit YAPF. Habe ebend, extra für dich, mal in die Sourcen geschaut um nachzuschauen (ohne gewähr, da Code nur übeflogen): indirekt würden Waypoints die Rechenlast minimieren, aber nur unter bestimmten Umständen. Es wird ja der komplette Weg bis zum nächsten Ziel berechnet. Ist auf diesem Weg eine (oder mehrere) Abzweigung(en), schaut er auch da nach, obs a: auch zum Ziel geht und b: welcher dann schneller ist. Wenn nun direkt vorm Zielpunkt eine Menge Abzweigungen sind, rechnet der Computer von jedem tile zu jedem tile aus, welcher davon geeignet ist. Dort könnte also ein Wegpunkt helfen. Sind diese Abzweigungen hingegen am Anfang der Strecke, hält sich der Nutzen in Grenzen.


Gruß,
BamBam