Beiträge von chrigulix

Benutze die Tasten n und m auf der Tastatur!

Dein Prozessor hat eine eingebaute Intel HD-Graphics 4000, es kann sein, dass TrainFever im moment diese verwendet anstatt deine Nvidia Karte. Um das zu ändern musst du in der Nvidia Systemsteuerung unter 3D-Einstellungen verwalten /OrtWoSteamOrdnerVorhanden/steam/steamapps/common/train fever/trainfever.exe hinzufügen. Dabei kannst du auch noch etwas an den Einstellungen schrauben wie hier Verbesserung der Frameraten für NVIDIA-Karten! beschrieben... Hoffe das hilft

Zitat von Skullair

Es gibt bei mir häufig Probleme damit lange Tunnel oder Brücken parallel zueinander zu bauen, da sie miteinander kollidieren, auch wenn man in mehreren Schritten baut.

Dann hast du aber riesen Tunnels/Brücken, ich habe das schon seit langem nicht mehr erlebt. Diesen "Bug" gab es in der beta sogar schon bei kurzen Tunnels/Brücken, ich hab dann einfach die Doppelspur aufgetrennt und zwei separierte Tunnels/Brücken gebaut. Nach dem Bauwerk vereint man dann die doppelspur wieder. Falls du sie in mehreren Schritten baust solltest du dies auch mit dem zweiten separierten Gleis auf etwa der gleichen höhe tun, da dabei bei verschiedenen Radien wieder probleme auftauchen. Grosse Einschnitte würde ich nicht bauen! Die kosten ein Heidengeld und sehen meiner Meinung nach richtig sch****e aus.

Für mich klingt es danach, als ob du etwas zu sehr gegen die Landschaft baust. Lange Tunnels kann man fast immer vermeiden, indem man z.B. in einer Steigung dem Gelände folgt und weiter oben einen Tunnel baut. Schau dir sonst mal die Gleisbau-Challanges hier im Forum an. (Aber ja, das ist geschmackssache und wür Hochgeschwindigkeitsstrecken dürfen es schon ein paar Tunnels und Brücken mehr sein.)

Schöner einblick in die Architektur von TF. Deckt sich auch mit meiner Beobachtung, dass bei unterschiedlichen Spielgeschwindigkeiten das Lag sich am Monatsende zeitlich verändert (je schneller die spielgeschwindigkeit, desto länger darf man auf Thread2 warten).

Zitat von eis_os

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.

Hierzu noch eine frage: Wäre dieser Fall nicht eher zufälliger Natur, da gerade das std::thread::join den Thread1 ans limit bringen würde? Sprich, würde man bei einer weiteren Stadtentwicklung dann nicht schon vor Monatsende ein ruckeln feststellen können?

Ich hoffe es gelingt UG die simulation zu optimieren. Es sollten auch die gewünschten Systemkomponenten vom Spiel schon selbst genutzt werden, z.B. automatisches Erkennen/Verwenden der leistungsfähigeren Grafikkarten anstatt IntelHD sowie Erkennen und Nutzen von verfügbarem Memory, etc. Ich denke darin liegt für viele Spieler ein grosses Frustpotential und ist mitunter auch ein Grund für die mässigen Ratings z.B. auf Steam. Wird wohl nicht einfach werden, gerade letzteres, für mehrere OS und deren unterschiedlichen versionen umzusetzen, aber ich empfinde es als ein "Muss".

Deine totale Einwohnerzahl ist nahe am maximum einer 16bit Zahl mit vorzeichen (32767). Vielleich will das spiel einen overflow verhindern wobei die Zahl auf 0 gesetzt würde und reduziert/stoppt das Bevölkerungswachstum. Es hiess ja immer, dass bei 10'000 Leuten schluss sei, daher bist du wohl am Limit...

Mal ne frage: wie ist eigentlich die Performance bei diesem Spielstand und welche PC-Komponenten hast du in deiner Kiste?

Hmm, nicht schlecht dieses Update. Bei Autoreplace wäre noch ein "now" Button praktisch, dann könnte man die Fahrzeuge jederzeit ersetzen und nicht erst nach 100% der Lebensdauer.

Aber etwas anderes ist mir noch (negativ) aufgefallen. Ich habe wieder Performance-Problemen am Monatsende (hängt nicht mit auto-safe zusammen), das Spiel läuft sonst flüssig. Doch Ende Monat bleibt es für ca. 3-5 sekunden stehen. Hatte mit demselben Safegame kein Problem zuvor. Teilt ihr diese Beobachtung, oder spinn ich?

Hallo erstmal!
Schönes Forum habt ihr da!

Zitat von BaZo

Wie sich herausgestellt hat der Zufallsgenerator einen sehr Morbiden Humor. Ein Schelm wer böses denkt....

Also dieser Effekt ist durchaus erklährbar. Wenn man ein Programm schreibt, das einen Zufallsgenerator verwendet, dann schreibt man den nicht selbst, sondern greift auf Systemprogramme zurück. Bei linux kann verwendet man in der Regel /dev/random bei Windows bin ich mir nicht so sicher aber es könnte der CryptGenRandom sein. Ein Zufallsgenerator ist ja eigentlich eine rekursive Folge, die bei unendlich vielen anwendungen eine Gleichverteilung ergibt. Dabei ist der Seed quasi der startpunkt dieser Folge. Nun gibt es zwei Möglichkeiten wie die unterschiedlichen Karten zustande kommen:
1. Die beiden Generatoren brauchen unterschiedliche algorithmen (die Folge is nicht gleich)
2. Der Seed wird anders umgewandelt. D.h. wenn man "a" als Seed wählt, kann es sein, dass der Generator von Linux den buchstaben anders in eine binäre Zahl verwandelt als der von Microsoft. Dies würde sich am einfachsten testen lassen indem man den Seed "1" wählt, da dieser nicht unterschiedlich interpretiert werden kann (1 ist binär immer noch dasselbe).

Ich denke jedoch, dass es vorallem an Punkt 1 liegt aber ein test mit Seed "1" werde ich mal bei gelegenheit durchführen, habe Linux und Windows auf meiner kiste.