[Blockierte Grafik: http://ftp.train-fever.net/flaggen/gb.png] in A short overview regarding calculations, multi core usage and end-of-the-month waiting times in Train Fever, Build 5080:
Die Deutsche Version gibt es hier.
First of all, the obvious: Train Fever uses multiple threads. In the following text, I will refer to the "main game", respectively, the stuff that is presented to us on the screen as "main thread". In this main thread, the more calculations have to be done, the lower the frame rate (fps) will be. The more calculations can be outsourced to different threads, the more fluent the game will run.
Currently, Urban Games has achieved to swap out some of the calculations from the main thread to different other threads. These other threads run in parallel to and the operating system schedules the threads to the cores of the processor. Important to note: one thread may be executed on multiple cores, but the execution will be sequential, thus showing only a low percentage of usage on each core when e.g. using windows task manager. Mutliple threads can also be executed on only one core. In this case, they have to share the computation power of this core and each thread will be throttled down. In the best case, each thread can run on its "own" core and all threads are executed in parallel.
With increasing complexity of a save game, respectively the number of persons / vehicles, the calculation gets more and more complex and time consuming. In older builds, this was noticeable by dropping frame rates. With build 5068, Urban Games swapped the path-finding to a separate thread and the fps should in general increase. However, some players experience longer lags / waiting times at the end of each month. This can be explained as follows:
In Train Fever, the "overlaying" time unit is a "month". At the end of each ingame month, all calculations have to be finished before starting the new month. By swapping out calculations to different threads, the main thread may run faster but at the end of the month, all calculations have to be finished nonetheless. If for example the path-finding takes 2 minutes to complete its calculations but the month is over after only 1 minute and 30 seconds, the player has to wait the remaining 30 seconds until the path-finding algorithm is finished. If the game is paused - or even speed up - during the month, the duration of a month varies, while the duration for the calculations stays about the same, only increasing with increasing complexity of the save game. When playing with 4-times the speed all month, it is more likely, that the player will experience a long lag at the end of the month. Pausing the game during a month will more likely lead to shorter - or no waiting times.
Please note: parallelization of algorithmsdo not speed up the calculation itself. If the path-finding slowed down the main thread by two additional minutes (resulting in much longer months, resp. lower fps), the calculation will still take two minutes when calculated in a separate thread. Of course, If one month also takes about two minutes, the game was speed up due to parallelization and no lags are present. However, if the calculations take up more time than the main game thread, lags will be experienced. The only options of speeding up the algorithms, would be choosing a different, faster implementation of the algorithm or to parallelize the algorithm itself (which is not always possible).
This thread should not be considered a instruction of "how to play" to not get lags. I only try to explain the background information for you guys to hopefully understand the "problem".
One last information: If you have a fairly modern PC, and still have low fps, consider choosing the "low texture" option. The graphics still look good and the fps can increase quite much. Most modern graphics cards are "bored" by the calculations for Train Fever but do not have sufficient memory, due to the tremendous amount of graphical ram needed by Train Fever is many objects are on the map.
Update regarding Build 5112:
Most important, players reported freezes at the end of each game month. We have identified the problem and it is fixed now. Because since the last update, the game runs faster during the months, on certain systems (parallel) simulation calculations which need to be finished at the end of each month were still in progress and caused these freezes.
I can confirm this on my machine with lags not exceeding more than 2 seconds even on large maps on full speed.
[line][/line]
Information collected and provided by @Xanos
Sources: own experience and observation, hints by Urban Games, patch notes, code analysis of Build 4831 by @eis_os
