Diskussion zur Peformance und fehlenden Features (Build 6181)

Zitat von Tom

Laut dem Tutorial von @Kiwi-NZ dauert ein Spieltag 2 Sekunden, dem entsprechend ein Monat ca. 1 Minute und das Jahr dem zur Folge ca. 12 Minuten.Nur zur Ergänzung...

Mal kurz und grob bei dir zusammengefasst:
Map mit "viel Verkehr" -> niedrige FPS -> KURZER Monatsruckler
Map mit "wenig Verkehr" -> hohe FPS -> LANGER Monatsruckler
Richtig?

Alles anzeigen

Ich hatte halt Anfangs die Idee, dass ein großer Spielstand und die daraus hervorgehende Belastung der CPU dafür sorgt, dass die Simulation an sich langsamer abläuft. Dann hätten Hintergrundprozesse mehr Zeit, abgearbeitet zu werden. Dass "ein Tag = 2 Sekunden" fest gesetzt ist, war mir nicht bekannt.

Ansonsten trifft's die Zusammenfassung.

Guten Abend wie ich es schon mal erwähnt habe, hatte ich eine komplett Leere Map über Nacht Laufen gelassen am ohne mods ohne alles map war groß und Hügelig. Am nächsten Morgen siehe da hatte ich Ruckler so von 1-1,5 Sekunden und hatte das Jahr 2250 auf den Tacho das sollte mal jeder ausprobieren.

Zitat von Fussel

Ich hatte halt Anfangs die Idee, dass ein großer Spielstand und die daraus hervorgehende Belastung der CPU dafür sorgt, dass die Simulation an sich langsamer abläuft. Dann hätten Hintergrundprozesse mehr Zeit, abgearbeitet zu werden. Dass "ein Tag = 2 Sekunden" fest gesetzt ist, war mir nicht bekannt.
Ansonsten trifft's die Zusammenfassung.

Wäre aber eine gute Idee, wenn ed so wäre. Noch besser wäre es allerdings, wenn man, auch während des Spiels, mit Schieberegler oder so, die Zeit frei einstellen könnte. So dass man wählen kann, ob ein Tag 1, 2, 4 oder 8 Sekunden dauert.
Dies sollte unabhängig sein von der Möglichkeit der Einstellungen der Spielgeschwindigkeit (normal, zweifach und vierfach), die es jetzt bereits gibt.

Nur ob das nachhaltig die Pausen beseitigt bezweifle ich. Ich befürchte damit wird höchstens die Dauer der Pause ein wenig verkürzt.

Eine Testmap ist im Prinzip eine gute Idee, wird jedoch meiner Meinung nach nicht zwingend benötigt, da die Fakten zum Thema ja bekannt sind.

Eine grobe Skizze:

• Das Spiel läuft im wesentlichen in 2 Threads ab, welche auf 2 CPU-Kerne verteilt werden.
• Thread 1 ist für die reine Simulation (Züge fahren, Menschen bewegen sich, Gebäude werden gebaut, etc.) verantwortlich.
• Thread 2 berechnet die erforderlichen Daten, welche im nächsten Monat zur Anwendung kommen (wo fahren welche Sims hin, welche Gebäude werden gebaut oder erneuert, ect. ).
• Mit zunehmender Spieldauer scheint es Thread 2 nicht zu schaffen, innerhalb eines Monats (1 Minute) alle erforderlichen Daten zu berechnen, wodurch besagt Monatsruckler entstehen.

Angenommen, obige Skizze entspricht den Tatsachen, wie würde ich als Entwickler dem Problem begegnen, wenn ich die grundlegende Spielmechanik nicht verändern kann oder möchte?
Die Lösung scheint die Zeit zu sein. Es würde im Prinzip reichen, die Dauer eines Monats im Spiel von einer MInute auf z.B. zwei Minuten zu verlängern. Dies dürfte mehr als ausreichend sein, um alle Berechnungen vorzunehmen.
Wir hätten nebenbei noch den Vorteil, dass die Spielzeit weit weniger "rast".

Natürlich kann diese Annahme auch völlig falsch sein. Möglich wäre, nach meiner Meinung, auch, dass Thread 2 die Berechnungen zwar schafft, aber die schiere Menge an Daten, welche am Monatsende ausgetauscht werden einfach immer größer wird und durch den notwendigen Austausch zwischen den Threads diese Verzögerungen entstehen.
Hier würde ich dann eine Splittung vornehmen. Zum Beispiel die Sim-Daten an allen ungeraden Monaten austauschen und die restlichen Daten an alen geraden Monaten. So würde die erforderliche Datenmenge pro Monat schrumpfen und der Austausch schneller vonstatten gehen.

Obiges sind meine Ideen, welche wir aber nicht umsetzen können. Da wäre UG gefragt, was ich mir natürlich erhoffe.

LG Enno

Zitat von EAT1963

Mit zunehmender Spieldauer scheint es Thread 2 nicht zu schaffen, innerhalb eines Monats (1 Minute) alle erforderlichen Daten zu berechnen, wodurch besagt Monatsruckler entstehen.

Er berechnet diese Daten ja nicht den ganzen Monat über hinweg, sondern nur am letzten Tag. Das dauert am Anfang des Spiel nur eine Sekunde, später halt mehrere Sekunden. Dadurch entsteht dann der Ruckler.

Eine Idee wäre, die Bewohner getrennt zu berechnen. Nehmen wir mal eine fiktive Zahl von 8000 Leuten, die sollten von jedem ruckelfrei berechnet werden können. Die nächsten 8000 werden dann eine Woche versetzt berechnet und so weiter. Damit wird die Last nicht nur auf das Monatsende geschoben sondern gleichmäßig verteilt.
Inwieweit das mit dem Code umsetzbar ist, ohne das halbe Spiel neu zu programmieren, weiß ich natürlich nicht.

wenns nur den Monatenderuckler gäbe wärs mir ja recht egal

Zitat von OnkelTom

Guten Abend wie ich es schon mal erwähnt habe, hatte ich eine komplett Leere Map über Nacht Laufen gelassen am ohne mods ohne alles map war groß und Hügelig. Am nächsten Morgen siehe da hatte ich Ruckler so von 1-1,5 Sekunden und hatte das Jahr 2250 auf den Tacho das sollte mal jeder ausprobieren.

Hast du das Safegame noch? Wenn ja, wäre es schön wenn wir alle mal das Lag messen könnten um zu schauen, ob sich sysemspezifische Unterschiede beobachten lassen auf der exakt selben map.

Zitat von EAT1963

Eine Testmap ist im Prinzip eine gute Idee, wird jedoch meiner Meinung nach nicht zwingend benötigt, da die Fakten zum Thema ja bekannt sind.

Eine grobe Skizze:

• Das Spiel läuft im wesentlichen in 2 Threads ab, welche auf 2 CPU-Kerne verteilt werden.
• Thread 1 ist für die reine Simulation (Züge fahren, Menschen bewegen sich, Gebäude werden gebaut, etc.) verantwortlich.
• Thread 2 berechnet die erforderlichen Daten, welche im nächsten Monat zur Anwendung kommen (wo fahren welche Sims hin, welche Gebäude werden gebaut oder erneuert, ect. ).
• Mit zunehmender Spieldauer scheint es Thread 2 nicht zu schaffen, innerhalb eines Monats (1 Minute) alle erforderlichen Daten zu berechnen, wodurch besagt Monatsruckler entstehen.

Das war einmal so, vor Build 5746 & 5751. Damals war das Lag aber auch länger, wenn man die Spielgeschwindigkeit erhöht hatte, weil dadurch der überlastete Thread noch weniger Zeit hatte und das thread.join() dadurch am Monatsende noch länger warten musste. Allerdings hat sich seither einiges getan und das Problem wurde einiges komplexer, siehe auch meinen Post auf dieser Seite: http://www.train-fever.net/ind…date-5746-5751/?pageNo=14 (ungefähr in der Pagemitte). Auch heute noch hat TF auf meinem Rechner bis zu 11 Threads laufen.

Edit von Grimes: Beiträge zusammengefügt. Bitte Doppelpostings vermeiden und die bearbeiten Funktion nutzen. @chrigulix

Edit von Chrigulix: Sorry for that!

Ich wollte nur noch einmal darauf hinweisen, das die Berechnereien zum Monatsende ja schon ausführlich diskutiert wurden.
Bei einem Patch hat UG für flüssigeres Spielen während den Monats gesorgt (mehr FPS?) und sich dafür grob ausgedrückt den Monatsendruckler (wie war das mit Unwort des Jahres?) eingefangen.

Interessant ist aber anhand der Problemschilderungen, dass es da anscheinend gravierende Unterschiede gibt:
Bei den einen liegt die Dauer bei ausgebauten Spielständen "nur" zwischen 1-2 Sekunden und wird noch als erträglich empfunden, bei den anderen sind es aber 5 Sekunden und mehr.
Nach Angaben einiger Foristen "scheinen" Spieler mit weniger gut motorisierten Rechnern (z.Bsp. Laptops, niedrigere FPS) kürzere Pausen ertragen zu müssen, während leistungsstärkere Rechner (höhere FPS) für mehr Ärgernis sorgen.

Deswegen hier noch einmal meine Antwort auf @fidos Bericht:

Zitat von Tom

Mal kurz und grob bei dir zusammengefasst:
Map mit "viel Verkehr" -> niedrige FPS -> KURZER Monatsruckler
Map mit "wenig Verkehr" -> hohe FPS -> LANGER Monatsruckler

Vielleicht gibt es da einen Zusammenhang?

Soweit ich in Erinnerung habe, hat UG die Pfadfinderei auf einen zweiten Thread ausgelagert (citiation needed).

Der "Hauptthread" sorgt demnach für das Malen der Bilderchen und noch irgendwas.
Je mehr Frames pro Sekunde angezeigt werden, umso weniger Zeit bleibt für andere Berechnungen in dieser Zeit.
Deswegen wären die FPS bei den Spielern mit laaanngem Ruckler interessant.
Und wie es mit VSync gehalten wird.

Nur eine Vermutung. Vielleicht kann sie bestätigt oder widerlegt werden...

Zitat von Tom

Der "Hauptthread" sorgt demnach für das Malen der Bilderchen und noch irgendwas.
Je mehr Frames pro Sekunde angezeigt werden, umso weniger Zeit bleibt für andere Berechnungen in dieser Zeit.

Widerspräche das nicht aber der Definition von Parallelverarbeitung mittles Multithreading? Es geht doch gerade um die Entkopplung von sich nicht beeinflussenden Berechnungen usw. Also eben dass genau NICHT Thread 1 auf Thread 2 warten muss.

@DarkMo,

Zitat von Tom

Soweit ich in Erinnerung habe, hat UG die Pfadfinderei auf einen zweiten Thread ausgelagert (citiation needed).

Bleibt die Frage, was der "Renderthread" außer Rendern eventuell noch zu tun hat.
@eis_os hatte da mal vor einiger Zeit entsprechende Analysen gemacht.
Ich weiß aber nicht, ob die für den Zeitpunkt der Einführung des zweiten Threads noch gültig sind.

Guten Tag Com nein habe das Safegame nicht mehr da ich TF nicht mehr Spiele, schaue zwar ab und an rein mit der Hoffnung das ja eventuell doch noch was Passiert so das man TF eventuell wieder mal Spielen könnte,

aber wie ich sehe passiert seitens UG nichts schade für die Com.

Bin dann erst mal wieder weg.

Mir ist da letzte Woche was aufgefallen, als ich auf dem 2. Monitor mal den Taskmanager und so Temp und Auslastungsanalyse Tools mitlaufen hatte.
Es lief auf meinem 4/8 Kerner weit mehr verteilt über alle Kerne als gedacht. Ich mach mal ne Videoaufnahme während des Spielens von den Tools und Taskmanager, bin gespannt was dabei raus kommt.

gruss Nando

Kurz und knapp, alle Berechnungen auf X Threads müssen irgendwann wieder zueinanderfinden, sollte die Zeit reichen, ist es flüssig, sonst macht TF eine Gedenkpause.

Was macht TF Intern und warum es ruckelt

So, ich wollte eine Beobachtung die ich während dem Spielen machte mit Euch teilen. Finde dieses Resultat interessant, da wir ja immer davon ausgegangen sind dass die Kerne der CPU's zu sehr ausgelastet sind und nicht nachkommen. Und das daraus Ruckler enstehen. Nun was ich da nun aufgezeichnet habe wiederspricht dem und zeigt auch dass nicht nur Stur 2 Kerne belastet sind.

Aber schaut selbst:

Meine Workstation:
Intel Core I7-950 Bloomfield Sockel 1366 OC @3980Mhz
6 GB DDR-3 1600Mhz Ram (ist nicht so viel ich weiss, ist meistens auch bis 80% belegt)
Nvidia GTX980 auch leicht OC alles Wassergekühlt
Spiele auf 1920x1080 Fullscreen Modus

Ingame Grafikoptionen alles auf High einzig Textur Kompression ist an (sonst ist es einfach unspielbar )
Vsync ist an.

Die 1. Karte ist eine neuere vom Vorgänger Build, Groß, hügelig mit viel Wald und Schönbauelementen.
- 120 Mods aktiv 10 Städte ca. 12k Einwohner
- 54 Züge davon 5 Güter- und 4 Personenlinien
- 176 Strassenfahrzeuge davon 7 Bus- und 11 Güterlinien
- 382 Trams 38 Linien

Durchwegs akzeptable Frameraten auch in den Städten von mind. 20 Frames, aber Monatspausen von 3-5 Sekunden. Vor dem OC waren die wie gesagt noch 1,5 Sek länger.

Die 2. Karte ist eine alte ca. März/April erstellt, Klein 9 Städte mehr Einwohner und auch Fahrzeuge, erstaunlicherweise dort absolut keine Monatspausen! Dafür nur 12-30 Frames auf der Karte und so ein ständiges Mikroruckeln.

Gruss Nando

Edit: Fazit fehlt noch :

Es scheint dass sich, zumindest bei mir, die Last auf mehrere Kerne relativ gleichmäßig zu verteilen. Ich konnte keine Einzel Kern 100% Auslastung feststellen, auch während der 'Ruckler' Pausen.
Die GPU langweilt sich, einzig der VRAM schnaubt weil viele Texturen ihn beschäftigen. Der ist meistens ca. 80-90% voll

Es überrascht mich ein wenig, zumindest die effektive Auslastung der einzelnen CPU-Kerne

AMD FX(tm)-6300 Six Core 3.50 GHZ
Nvidia Geforce GTX 750ti
Windows 10.
16 GB Ram.

ALLES auf On (meistens)

und;

Maximal 2GB Ram in Verwendung
und dazu noch das bei mir nur 1 Core (3,4-3,5 GHZ) überhaupt belastet ist.
Die anderen spielen in der zeit Poker oder sowas.

trotzdem; Monatsruckler standart 1-2 Sekunden
und FPS schwankt teilweiße stark.

Während eines Monatsende werden kommt es zu einem Thread Join, dabei wird nur ein Kern belastet und eine ganze Menge an Daten verschoben, die passen in keinen CPU Cache.
Microruckler sind ein Zeichen für zu viel Passagiere auf dem Screen

Zitat von eis_os

Kurz und knapp, alle Berechnungen auf X Threads müssen irgendwann wieder zueinanderfinden

Das ist richtig.

Zitat von Shuttle

Build 5068 (January 30)
- Improved general performance (pathfinding is now computed in a separate thread)
- Improved “end-of-month” performance (that is e.g. when towns construct new buildings)

Es wurde die Wegfindung auf einen Thread ausgelagert. Wird noch etwas auf dem "Render-Thread" laufend berechnet? Wenn ja, was und wie?
Wenn ich mich richtig erinnere, ging der 2. Punkte nach hinten los und sorgte für folgenden Nachschlag

Zitat von Shuttle

Build 5112 (February 4)
Fixed / reduced freezes at the end of each month

Und jetzt noch mal zu den FPS, da @Nando in seinem Post oben ebenfalls eine Abhängigkeit von FPS und Ruckler beschreibt.
Ich habe keine Ahnung von OpenGL, wie da ein "Render-Loop" aussieht und wie die Zeit zwischen Rendern, Animation, Logik etc. verteilt wird.
Vielleicht hat hier jemand etwas Hintergrundwissen.

Zitat von Nando

Es scheint dass sich, zumindest bei mir, die Last auf mehrere Kerne relativ gleichmäßig zu verteilen. Ich konnte keine Einzel Kern 100% Auslastung feststellen

Die Kurve des Task-Managers ist da nicht sehr genau. Auch weist der Scheduler einem Thread nicht immer den gleichen Kern zu. Alle rechenwilligen Threads möchten mal auf einen Kern, deswegen verteilt sich das auf der Fieberkurve. In deinem Video ist aber mit Anstrengung eine Prozessorauslastung um die 25% zu erkennen:
100% Auslastung bei 8 Kernen -> alle Kerne am Anschlag
50% Auslastung bei 8 Kernen entspricht 4 von den 8 Kernen am Anschlag. Tatsächlich verteilt das der Scheduler über alle 8.
25% "entspricht" dann ungefähr zwei Kerne am Anschlag.
usw.

Hallo Zusammen,

Spiele zurzeit auf einer kleinen, flachen Karte, Startjahr 1850, aktuell 1898, mit 11575 Einwohnern, Grafikeinstellung maximal, i.d.R. ca 40-50 fps (Steamanzeige)

Mein System:
Win 7 Home Premium 64 bit
Prozessor Intel i7-4820K, 3,7 GHz, 8 CPUs
16 GB Ram
GeForce GTX 770, 4 GB
Auflösung 1920 * 1080 32 bit

Monatsruckler 10-11 sec

"towngrothfactor" z.Zt. 0,5, zuvor 2,0, gefühlt die gleichen "Ruckler"...

Macht nicht wirklich Spass so zu spielen.

Grüße Marc

Zitat von eis_os

Kurz und knapp, alle Berechnungen auf X Threads müssen irgendwann wieder zueinanderfinden

und

Zitat von Tom

Das ist richtig.

... ganz ehrlich? Ich finde das NICHT richtig! Es kann gut sein, dass es in TF so ist, aber dann ist es eher purer Aktionismus denn wirkliches Multithreading. WENN es so gelöst ist, dann steht man als Programmierer dabei vor dem Problem, möglichst gleichmäßig rechenintensive Aufgaben zu finden und auf die CPU's zu verteilen. Der Vorteil: Ich habe doppelte CPU-Power, aber wer zuerst fertig ist muss unweigerlich auf den anderen warten. Um das zu minimieren braucht man eben möglichst 2 Algorythmen die die selben Rechenzeit brauchen - prinzipiell. Wer sich bissl mit Betriebssystemen auskennt, der weis, dass das eigentlich unmöglich ist ordentlich hinzubiegen.

ECHTE Paralellität erreicht man nur durch voneinander UNABHÄNGEN Berechnungen/Aufgaben. Punkt. Und da muss nichts mehr zusammen geführt werden irgendwie so dass da Wartezeiten entstehen. Einfaches Bsp: Ein Thread macht die Wegfindung, ein anderer die Zielfindung. Die Wegfindung nimmt den aktuellen Standort plus das aktuelle Wege-Netz und sucht dort den besten/günstigsten Weg. Die Zielfindung bestimmt eben jenen Zielpunkt, was liegt in Reichweite, wo will der Sim gerade hin. Solange der Zielfindungsthread noch arbeitet nimmt der Wegfindungsthread schlicht die alten Werte und rechnet damit ungestört weiter. Sobald die Zielfindung durch ist, aktualisiert sie den Wert (das ist auch noch bissl knifflig OS-intern, aber das soll hier mal aussen vorgelassen werden) und die Wegfindung rechnet plötzlich mit diesem Thread. Beide arbeiten völlig unabhängig voneinander, da muss nix aufs andre warten. Das ist Multithreading

Und richtig echtes Multithreading ist auf nem Computer eh nich wirklich möglich, bei all den vielen Diensten und Prozessen die da laufen und vom Sheduler regelmäßig unterbrochen und von der CPU geholt werden. Man teilt sich die popeligen 4 Kerne halt nich nur mit sich selber, sondern gut und gerne mit 60 anderen Prozessen

Zitat von Tom

Ich habe keine Ahnung von OpenGL, wie da ein "Render-Loop" aussieht und wie die Zeit zwischen Rendern, Animation, Logik etc. verteilt wird.
Vielleicht hat hier jemand etwas Hintergrundwissen.

Logik ist definitiv CPU, Rendern GPU und Animation würde ich als Teils/Teils ansehen. Die CPU lädt die Daten in den Speicher, also Texturen, Shader, Objekt-Daten... und das wird dann zur GPU geschickt. Was die GPU rendert ist völlig losgelöst von der CPU. Allerdings ist für ein dynamisches interagieren halt immer wieder neuer Input von der CPU nötig. Ändert sich die Ansicht werden die Matrizen geändert und neu zur GPU geschickt, muss ein Objekt animiert werden, also seine Position/Ausrichtung/Größe ändert sich, müssen die Daten erneut zur GPU gehn. Die RenderPipeline selber aber ist dann halt völlig unabhängig. Allerdings bin ich soweit auch noch nicht vorgedrungen, zumal mein altes Projekt leider mit der Platte unterging. Multiple Framebuffer, Blur-Effekte, SpecularMaps, LightMaps (oder wie das heisst)... da hatte ich schon paar schöne Spielereien drin Atm verzweifel ich schon an der Darstellung meiner indexed Array Daten xD Glaub damals hab ich einfach vbo's/vao's genommen.

Müsst ich auch mal wieder weiter basteln.