Beiträge von eis_os

Hallo

Kurz und knapp:

• Deine Grafikkarte hat zu wenig Grafiksspeicher. -> Versuche es mit weniger Texturqualität. TF fängt an zu Swapen und lädt die Texturen von der Festplatte.
• TF benutzt zur Hauptberechnung höchstens zwei Threads (zwei CPU Kerne, Version 4831), ein Kern kann einfach überfordert sein.

Eine Analyse zu dem CPU Kern Problem
Eine Teil-Code Analyse mit Linux Debug Daten, Windows Version 4831 und Beobachtung

TF macht im Endeffekt bei einem DayChange:

BuildingSimulator hat mehrere Felder mit Informationen, diese sind mir unbekannt.
Die Informationen in den Feldern ergibt einen Gesamt-Status A, B, C des Train Fever Haupt-Threads.

Im Programcode von BuildingSimulator::DayChange

Ist der Gesamt-Status A:

BuildingSimulator::PrepareThreadData
Mache einen Clone der Engine Teile, vom Transport Netzwerk, Stationen, Linien usw.

Starte einen neuen Thread für die Berechnung (mit den Clone Daten)
-> TF nutzt nun 2 Kerne für das Spiel und berechnet die Häuser im Hintergrund (wohl auch die Einwohner)

Ist der Gesamt-Status B (Monatsende?):
Benutze std::thread::join -> Warte bis Thread 2 fertig mit der Ausführung (Berechnung) ist.
BuildingSimulation::ProcessResult -> Verarbeite die errechneten Daten
TownDeveloper::Run(BuildingSimulation const*)
IndustryDeveloper::Run(BuildingSimulation const*)
und dann werden die Daten wohl weggeworfen.

Gesamt-Status C:
Mach hier gar nichts, der zweite Thread kann gerade im Hintergrund am laufen sein.

Zusammenfassung:
BuildingSimulation::ProcessResult in "Gesamt-Status B" scheint die Berechnung des Thread2 zu nutzen um die Daten im Hauptthread zu ändern.
Umso größer das Transport Netzwerk wird, um so langsamer wird Thread2 da es mehr Daten berechnen muss.

Wenn es gut läuft ist Thread2 schneller fertig in einem Monat als Thread 1. Thread 1 kann die Daten schnell genug im Status B verarbeiten.
Resultat: Spiel läuft flüssig.

Dann gibt es da noch Varianten wenn es hängt:
a) Thread 2 ist zu langsam auf dem CPU Kern, Thread 1 muss warten.
b) Thread 2 ist schnell genug (zwei Kerne werden genutzt, wenn Thread 2 fertig ist, nur noch ein CPU Kern von Thread 1)
Das Zusammenfassen der Daten in Thread 1(Nur ein CPU) braucht zu lange.
c) Thread 2 ist zu langsam (zwei Kerne werden aber genutzt) dann ist das Zusammenfassen der Daten zu langsam (ein CPU Kern wird genutzt)

d) GPU / OpenGL Limitierung. Thread 1 hat schon zu viel Zeit verbraten im Frame um Daten zu Grafikkarte zu schicken. Das Mergen im Thread 1 hat keine Rest-Zeit mehr übrig.
Hier hilft die GPU Einstellungen runter zu schrauben.

Vielleicht versteht Ihr nun warum es keine einfache Lösung gibt und es mehrere Probleme bzw. Lösungsansätze gibt:
- CPU Leistung bei einem Thread ist zu wenig.
- GPU Leistung zu wenig, schaltet die Grafikeinstellungen runter, zum Beispiel Texturqualität.

PS: Da TF sehr viel mit Hashes/Malloc und Locks arbeitet, gibt es da noch CPU cache misses, mutex/lock congestion, memory fragmentation (sehr schönes Beispiel alte Firefox Versionen). Also nicht gerade ein einfache Thema.

Ja. TF hat mehr als zwei Threads offen. Dies kann man zum Beispiel mit Sysinternals ProcessExplorer sehen. Unter anderem für Steam, Soundausgabe, Grafikkartentreiber, ist hierbei um das Thema einfacher zu halten nicht berücksichtigt.

Ich benutzte zur Analyse die erste öffentliche Linux Version für Funktionsnamen (Debugdaten) + Windows Version 4831

Nunja, ich kann nicht behaupten das mein Spiel noch flüssig läuft eher das Gegenteil ... , bin im Jahr 2228. (4. Mods, ne Lok, und zwei org. Fahrzeuge erweitert, und Gleismagnete, Texturen kann man ausschließen )

Steam mag keinen Debugger und lässt TF immer crashen, von außen kann man aber trotzdem etwas sehen.
TF hat eigentlich zwei Threads, 1. TF selber und 2. OpenAL. (Sound) (Die auch Arbeiten und nicht warten)

Am Monatsende wird ein neuer Thread erstellt.

Zwei Möglichkeiten:
a) Thread läuft, Spiel läuft weiter, Thread beendet. (Perfomance wird geringer)
b) TF bleibt mit einer harten Denkpause stehen, wenn der Thread fertig ist/geschlossen wird, geht auch TF weiter.

Wenn ich die Glaskugel nehme, würde ich auf den internen BuildingSimulator tippen, der als neuer Thread gestartet wird.
Es gibt einen Debug String in der Exe, BuildingSimulation::PrepareThreadData und nach dem hängen werden in einer Stadt meistens neue Häuser gebaut.

Zum Thema Threads. Sie sind kein Allheilmittel. Es scheint so das TF erstmal im Hauptthread Arbeitsdaten erschaffen muss. Der Hauptthread scheint nicht immer weiter arbeiten zu können, warum auch immer.
Das kann darin liegen, das ein Lock gehalten wird, es einen allgemeines Locking Problem besteht oder das Locking zu viel Zeit verbrät.

Bei meinem Test war der Thread gerade irgendwo in eine Listenfunktion und die Liste scheint mit "Ist Voll" Fehlern laut Stack beschäftigt zu sein, aber ohne Debugger der auch bei mehreren Threads Probleme bereiten kann ist das immer schwierig.

-edit-
Man kann vieles mit höhere Verarbeitungsgeschwindigkeit per CPU Kern erschlagen. Und ja, Intel Core iX CPUs haben eine höhere Single Thread Performance.

Das war genau anders gemeint, das die derzeitigen Waypoints nicht für Straßen funktionieren und somit nichts bringen. Und wie gesagt, geht es um Strassen bzw. Gleise die eben noch verlegt werden müssen. Eine Option, die anstatt einen Hügel aufschüttet/einen Hang kreiert und eben dann Stützwende nutzt. Oder Objekte die mir ermöglichen eine Rampe/Trog zu bauen auf deren ich dann die Straße/Gleise bauen kann.

Nur für Strassen bringen Waypoints gar nicht und ich möchte Strecken bauen (Strasse/Schiene) wo ja normale Gleise erst gar nicht gehen. Der Häusercode macht ja aus meiner Innenstadt Strecke schon ungewollt Stützwände, nur man kann die Strecke nicht mehr umbauen, da man keine neue Schiene mehr am alten Abschnitt bauen kann. Der Tunnel Portal Code macht mich auch immer wahnsinnig.

Hier nochmals die Zitate, bitte beachtet das es ein beiläufige Anfrage zu einem anderen Thema war, und es nur eine Richtung angibt und keine festen Fakten sind!

Zitat von eis_os

PS: Eine Option um Stützwände zu bauen wäre schön, damit man auch einen Bahndamm durch eine Stadt bauen kann

Zitat von Mikael

Nein Stützwände werden nicht kommen, wir konzentrieren uns auf Bug/Crash-fixing und notwendige Features.

Marcin Grzegorczyk hat das damals für TTDPatch umgesetzt (buildonslopes, so 2004), ich hab das dann auch für unter eine Brücke ermöglicht mit higherbridges. Das hat dem Spiel eine ganz neue Dimension eröffnet...
Leider kann man TF in der Spielmechanik überhaupt nicht in verändern. Optimierter compilierter C++ Code ist kaum zur einer Mitarbeit zu bewegen, auch die Updates werfen eine Analyse immer zurück.

-edit-
PS: Für einen Programmierer ist es etwas anderes ob man nur den Anstrich oder eine Datendatei importiert (sprich Model) oder sagen wir mal den Brückencode ändert. TF zum Beispiel reserviert für Brückenpfeiler Kollisionsdaten und dies unabhängig vom Modell.
Wenn man an dem Code rehen könnte, wären Brücke über vieles mehr möglich. Die Lua Schnittstelle wird nur zum einlesen von Daten genutzt und hat auf die interne Spielmechanik gar keinen Einfluss. Oder Urban Games baut explizit einen Parameter für etwas ein, das ist aber nicht im Sinne neue Problemlösungen ohne Urban Games zu schaffen...

Also mit Stützmauern sieht es eher düster aus:

"Nein Stützwände werden nicht kommen, [..]"

Ich würde mal sagen Konkurrenz belebt das Geschäft. (Ich hab mich gegen die Entwicklung eines eigenen ModManagers entschieden für TF in der jetzigen Form, sollte sich TF aber doch noch weiter entwickeln, schließe es aber nicht aus. )

Die Download ID auf train-fever.net wird für jeden Upload neu vergeben.
Das kann so also irgendwie nicht funktionieren. Wenn kann man nur den Webdisk Eintrag definieren, das ist aber nicht die Download ID.

Hallo

Ich schlage vor das mediziner den Thread abspaltet, und die Diskussion in einen eigenen Thread verschiebt.
Änderungen an der Abstimmung würden dann direkt als neues Post von mediziner darunter stehen und als neu gekennzeichnet.

Mal schauen:

http://forum.zusi.de/viewtopic.php?p=154901#p154901

Spontan: Zusätzlich zu den genannten Optionen:

1. Quellcode freigeben (Ich hab einfach zu viele Ideen, *träum*) oder eine API zu besseren Erweiterung (sprich wirklich neue Funktionen für das Spiel)
2. Fahrzeug erneuern
3. Frei platzierbare Objekt API
4. Die Möglichkeit Stützwände oder ähnliches zu bauen, damit man auch Tunnel und oder Brücken in eine Stadt bauen kann ohne alle Gebäude zu entfernen.
5. Overlay Filesystem damit man Addons besser installieren kann bzw. eine Script API für mehr Einfluss.
6. Erweiterung der API zum Erstellen von Depots und Bus und LKW Haltestellen um mehrere Straßenanbindungen.
7. Anständiges API damit man Brückenpfeiler* wirklich entfernen kann und/oder die Abstände zu beeinflussen...
8. Änderungen der Engine: Das entfernen von Objekten aus dem Spiel, Spielstand ermöglichen.

* Auch wenn die Pfeiler keine Mesh-Kollisionen haben, reserviert TF den Platz.

Für Leute die gerne Lesen:
http://www.stellwerke.de/signal/

Nur das DirectX auch keine gute API ist oder war, auch Multi-Threading Probleme machte. Die meisten großen Engines haben mehrere Render Pfade, also OpenGL (ES), DirectX 9 / 11 usw.
DirectX läuft natürlich auf einem Microsoft System besser und hat aber auch schon mehrmals die API gebrochen. (Vista hat schon Beispiel bei OpenGL Nutzung den Desktop wieder per CPU gerendert und Nettigkeiten, das war für OpenGL gar nicht gut)

Grafiktreiber sind immer eine Katastrophe, warum gibt es so viele Grafiktreiber "Optimierungen" für die verbreiteten Spiele nach dem Erscheinen des Spiels?
Da läuft es auch nicht rund, nur Train Fever ist eben zu unbedeutend das sich eine GPU Hersteller kümmert.
Zum Glück hat die Verbreitung von Smart Phones, WebGL, OpenGL ES dazu geführt, dass sich Treiber Entwickler mehr um OpenGL kümmern und auch MS sich nicht total verschließen kann.

GPU Umschaltungen sind immer ein Krampf.
Da wird eine DLL injiziert in dein Spiel und es während der Laufzeit verändert damit es überhaupt geht.

Den weder OpenGL noch DirectX sind dafür ausgelegt, das zwischendurch die Render-Architektur geändert wird.
Bei Browsern wird fast immer die CPU interne GPU genutzt, da sonst die Akkulaufzeit leidet bzw. das Umschalten scheitert.

Man hat sich eben an die Baustellen gewöhnt...

Das mit nicht entfernbaren Mods habe ich schon mit Mikael von Urban Games diskutiert, vor dem Patch zur Savegame Komprimierung. Daraus wird scheinbar aber nie etwas.
Der fehlenden Transparenz bezüglich Lua hat ja dieser Patch etwas eingedämmt, nun crasht TF nicht mehr kommentarlos, sondern kann auch bei einfachen Sachen eine Fehlermeldung geben,
aber wirklich toll ist die Modding Schnittstelle immer noch nicht. Für meine Ideen war und ist sie immer unzureichend.
Das die Engine mit allen C++ Optimierungen compiliert ist, ist zwar für die Performance gut, aber macht ein externes eingreifen in die exe sehr sehr schwer.
Und mit ihrem Plan TF2 herauszubringen werden Sie sich noch weniger in die Karten schauen lassen wollen.

Urban Games möchte sich soweit mir bekannt ist primär um Bug/Crash Fixing kümmern und um notwendige Features.

PS: Ich sichere mir die meisten alten Builds vor einem Update

Zum Desktop PC:
Mit dedizierte VGA Karte sollte es keine Probleme geben, es dürfen keine MS Treiber sein, die können kein OpenGL. Lucid oder ähnliche Lösung meiden und deinstallieren! Monitor an GPU,
wenn möglich in EFI/Bios interne Grafik ganz abschalten, dann gibt es in der Systemsteuerung keinen Eintrag mehr für die CPU Grafik.

Notebooks:
Sowohl NV Optimus und ATI/AMD PowerPlay haben schon immer Probleme gemacht.
Hierbei muss der Software Basis aus einem kompletten Paket bestehen, dh. alle Treiber des NB Herstellers. /Chipsatz, Intel, NV) Und hierbei gilt, diese Lösungen sind nicht mit allen Sachen getestet. Gerade OpenGL und 64Bit ist heikel. Dafür werden dann teurere Lösungen mit NV Quadro oder AMD FirePro im Profi Umfeld genutzt, mit Zertifizierung des Gesamt Systems.

Allgemein:
GPU Umschalttechniken machen öfters Probleme, zurzeit hat scheinbar Apple sogar mit einem System aus einen Guss Probleme.

Diese Probleme gibt es bei Unity Spielen, da kann man bei CIM2 bleiben oder auch mit CIM1.
Studios. Und auch bei vielen anderen...

MultiThreading und auf Kerne verteilen ist schwer.
Erst mal muss man eine Aufgabe haben die parallel Abgearbeitet werden kann,
man kann zwar seinen Code mit Locks zu müllen, dann wird es aber noch langsamer.

Und ein Msg basiertes System ist auch nicht das Allheilmittel.
Lock Free Programmierung ist schwer. Wer das wirklich verstehen will, was da noch so alles dran hängt. http://preshing.com/20120612/a…to-lock-free-programming/

Oder mal einfach nach Linux BKL oder Python GIL suchen, Ruby hat das Problem auch. C# muss den GC betreiben, dabei hält es alles an. Und bei Golang kann man auch schön sehen, das es manchmal sogar schlechter ist mehr CPU Kerne zu nutzen, wenn der Code nicht parallelisiert ausgeführt werden kann oder sollte. Deswegen sterben Insellösungen oder schwer programmierbare Systeme wie Cell oder Intel Itanium aus. Das ist zwar auf dem Papier alles schön, in der Praxis aber kaum zu lösen.

Eine Programmiersprache ist nur ein Werkzeug, und die meisten Spiele sind in C++ geschrieben, wie auch TrainFever. Deine Schlussfolgerung bezüglich der Programmiersprache ist daher falsch. Es war schon immer ein Unterschied ob man ein paar GB an statischen Daten für eine Spielwelt auf den Bildschirm zaubern muss oder eben tausend individuelle Objekte. Das sieht man auch schön an Mantle, DirectX 12, OpenGL Next. Der Overhead der Anweisung ein Objekt darzustellen ist höher als das Objekt dann wirklich zu zeichnen.
Aber eine Parallelisierung von Aufgaben war und bleibt immer schwierig. Ob die Nutzung einer vorhandenen Engine die besseren Wahl gewesen wäre sei dahin gestellt, meistens finde ich diese Spiele eher ein Rückschritt.
(Im Sinne von Spielspaß, nicht im Sinne von Technik)

Da TF sehr viel FileIO hervorruft (Eine Art Swapping der Texturen) sollten alle Hintergrunddienste abgeschaltet werden die Dateioperationen überwachen.

Es gab scheinbar ein Lastproblem auf dem Server, theoretisch und praktisch machbar die Webdisk auszulesen. (Bis auf RAR5 Format und dann als Ausgabe im JSON Format)

Bis auf weiteres lasse ich es aber Ruhen, bis ich ein paar Cache Routinen neu geschrieben habe und dazu habe ich gerade keinen Antrieb.

Nunja, TF benutzt OpenGL und dann auch noch 64 bit.
Eine Ferndiagnose ist immer schwierig.

Als erstes mal das Steam Overlay abschalten, dann Train Fever,exe direkt starten, dabei per Rechten Maustaste über der exe, Nvidia als GPU nutzen bzw. für die Exe Datei einen Eintrag im Treiber erstellen für volle Leistung.

Die NV GPU hat bei neueren Laptops keine direkte Verbindung zum Display, d.h. es erstellt ein Bild, und die Intel GPU muss das dann ausgeben, deswegen ist das abschalten des Treiber keine gute Idee.

Wenn Repo X und Repo Y, sagen wir train-fever.net/cimexchange.net den selben Mod hat, bekommt man doppelte Einträge bei den genannten Vorschlag. Die ID sollte im Paket sein, damit man die Infos auch nach dem Download noch hat...

PS: So als Info das man sich das vorstellen kann was der Server liefern kann/sollte. (Das Format ist nebensächlich, JSON, XML, Text)
http://cim.bytetransfer.de/repo/cim.repo

Die ID Vergabe hat keiner geregelt, du hast ja für deinen Programm Namen auch keinen gefragt oder? Die ID liegt in einer Datei/Dateinamen im Zip Paket.
Mein CIM1 ModManager brauchte eine <id>.modinfo in der GS Datei, dein ModManager braucht eine ini. Also warum keine eindeutige ID und Version in die Ini und gut ist?

Mediziner und das Wiki Repository auf DropBox waren als "vorauswahl" in meinem ModManger schon eingebaut und die wurden per Texteditor selbst erstellt.

Auf dem Server:
Öffne jeden neuen (öffentlichen!) Download die Zip/Rar Datei, schaue ob es eine INI gibt, wenn ja, lade die INI und finde die Metadaten,
Schaue ob eine ID schon von einem anderen Nutzer benutzt wurde, wenn ja, ignoriere die Datei und melde es bei den Admins
Trage den neuen Download in eine Datenbank inklusive Download Link und erstelle eine neue öffentliche repo Datei mit allen Downloads.

In der INI:
Die ID ist eine einmalige Angelegenheit, die Versionsnummer muss vor Release geändert werden, also sehr wenige Metadaten.

id=beton_bridge_eis_os
version=1.0

Nun kann TFMM Zips auslesen und die INI Daten zur Versionsüberprüfung nutzen.

Stepke:
Das liegt im Betreiber der Filebase Die Repo Dateien sind ja kein Hexenwerk und wie gesagt sind für jeden offen...

Hmm, sorry ich verstehe eure Probleme nicht, Datenbank Auth in der Exe? Wie bitte? Auf dem Server gibt es eine Repository bzw. Meta Daten zum Abholen, wie es jeder Paket Manager auch macht, dafür braucht es einen http Request und auf dem Server eine Software um die Metadaten zu erstellen, wenn man es nicht händisch macht.

Eine eindeutige ID (vom Ersteller festgelegt) + Versionsnummer reicht in fast allen Lebenslagen aus. Wer sich nicht dran hält und fremde IDs nutzt fliegt vom Server.

Das hat seit TTDPatch Zeiten funktioniert. (GRFID)

Mein CIM1 ModManager hat das alles in GS(CIM) Script gemacht (außer die Datei herunterzuladen und funktioniert auf Win32/OSX/Linux):
http://cim.bytetransfer.de/mod…/specs/mmfileformats.html

Hierbei war ein dezentrales System, mit mehrere Quellen im Vordergrund - sogar das Hosting auf einer DropBox Quelle war dadurch möglich.

Für meine eigenen Mods, hat ein PHP Script die .modinfos zusammen geklebt und die Repo Datei erstellt.

.edit-
Zusammengefasst:
Ein Mod/Addon Paket (Zip) bekommt vom Ersteller eine eindeutige ID, und eine Versionsnummer, dies liegt dem Paket bei.

Es gibt ein Update für ein lokales Paket, wenn die Paketquelle eine neue Datei mit der selben ID aber einer größeren Versionsnummer bereitstellt.

Ein Update deinstalliert Paket/ID mit alter Version, installiert die neue Version.

Eine neue Version darf sich nicht so ändern das ein Spielstand unbrauchbar wird, sonst muss es eine neue ModID erhalten.

PS: Die Board Download ID ist nicht unbedingt statisch, da Sie im Einfluss der Board Software liegt und mit einem Update, Server Umzug oder ähnliches theoretisch anders sein kann.