- This topic has 47 replies, 17 voices, and was last updated 10 years ago by
.
-
Posts
-
On my current large map I have around 400 road vehicles, 30 trains, and at the end of each month on the 30/31st it will freeze for about 20-30 seconds, game is borderline unplayable. I have AMD 6300 4.2 (overclocked) R9270x, 8 gig ram. Win 8 64
I have abvout 8 citys 1000+ pop, my largest being 1600.
My workaround is to only have the game Playing minimized while I play something else, and come back, Pause it, then build new lines ETC, hit play, minimize, play something else come back 30 mins later to see how its getting on, this is not really the way I should have to play this game!
Ok, firstly the only reason you would need to rewrite the code from day one, even to implement multi-threading, would be if the code was bad in the first place.
Secondly, implementing multi-threading is pretty easy. The difficulty comes in trying to get the threads to work together and not crash the program.
Without knowing how the game has been coded it’s impossible to know how big a job it would be to implement multi-threading. Also, you can only optimize a code so much, so the game really does need to be multi-threaded to get the performance people desire. A comment from the devs would be nice on this topic.
A comment from the devs would be nice on this topic.
The devs never comment on such topics… There were so many topics and requests to make the game multi-threaded – with no answer. They just don’t know how to do it, so they are trying to gratify us by fixing not so bad issues. I really don’t need depot doors or automatic replace or even american dlc when I am not able to play the game at all! The game should be multi-threaded from the very beginning and I am sure the devs know it. The game is very nice, but is sooo badly coded. I don’t have a superpowerful PC, but I am able to run much more HW demanding games smoothly. I understand the devs don’t want to rewrite the whole game, but that’s their problem, if they had implemented multi-threading at the beginning, everything would have been fine.
@coujou , I wouldn’t say the game is “badly” coded. From what I’ve seen in the game and how I’d assume it would be put together, the code is pretty decent. You can only ask a single core to do so much work no matter how good the code is.
With regards to multi-threading, it’s a hard thing to learn, so don’t give the dev’s to much stick if they don’t know how. When you make a multi-threaded program you can actually make things SLOWER if you don’t get it right, because multi-threading has significant overheads when it’s compiled.
However, if the dev’s can’t do it themselves, then they need to hire someone to do it. If it doesn’t get done things are only going to get worse the more stuff they add to the game.
I set all settings to lowest, I am on an SSD, still freezes for about 20 seconds, and zooming out gives a frame rate of 20~ I have to remain zoomed in for a decent framerate!
screenshot of game http://cloud-4.steamusercontent.com/ugc/44240844337973583/49F12E4F219F392B541554915015872D004491C9/
I did a analyse of current Train Fever.
Short:
2 Threads are used for the actual game (extra threads for various other stuff like sound ignored)
Thread 1 is the main thread, and the second one does prepare data for internal building simulation/line calculation while you play.
Every month thread 2 is joined with thread 1, and the calculation results used. A new thread 2 will be started…
If thread 2 takes longer then the month (either to fast setting, to much vehicles), you get a month end freeze, as thread 1 waits for thread 2 to finish calculating. This isn’t GPU or HDD limited, while joining may be effected.
You can follow my analyse (in German) here:
http://www.train-fever.net/index.php/Thread/2135-Was-macht-TF-Intern-und-warum-es-ruckelt/Conclusion:
Currently only massive single thread cpu power for thread 2 helps avoiding the month end freeze with later or complicate games. (or you sell all your vehicles and like to look at AI cars)I had indeed just noticed that the game does use 2 threads, so it’s not entirly without multithreading:
and it can max out the CPU on both threads without being on the turn of the month
http://utopia.modpro.be/tf_mt.png
I did a assembler code analysis, albeit on the Windows Version, so I have a pretty good understanding.
Sure. Thread 2 runs in parallel and will finish it’s calculation (in background). Then the thread will sleep until thread 1 joins thread 2. (= Waiting for thread 2 to be finished) If thread 2 isn’t finished yet, you get a full stop for thread 1. You see a freeze.
The windows and linux version are almost identical. I am actually used the debug data from the linux version to understand the windows version.Some Ascii Art:
Ascii Art 1 & 2 shows the gane time progressing from left to right, first is a month freeze compared to a GPU problem in Ascii Art 1. Ascii Art 3 shows a normal join between Frames at month ends. Ascii Art 4 if a join can’t fit anymore in a frame because GPU commands eat all time already.
Sidenote: I wish I could directly work on the code to fix these bugs and performance problems.
Ok guys. Herr is the thing. Threading from programmers perspective is just a method of organizing the execution of code. What yoy are discussing her is concurrency – which is doing things in parallel. The popular term of “threading” is used interchangeably with “concurrent”. For a programmer tym these are different things.
Btw – i would also like to read the sources.
Btw2 – hi eis_os 🙂
And you know what? The average gamer doesn’t give a fuck what causes lags and what could be done to solve it 😀 The developers should anyhow make the game run smoothly even after 200 years ingame/forever. I understand that computing all the paths of citizens and vehicles is HW demanding, but that’s not my problem. When you advertise your game with some minimal HW requirements, nobody expects huge performance drops after few hours of playing when the HW is twice better than the requirements.
Well it’s good to hear that the game does use some threading at least. But I, at least, was talking about asynchronous threading and not the synchronous threading described by eis_os.
But at least it’s a start, which means that it shouldn’t be such a huge job to improve performance.
Couldn’t agree more. The game is ADVERTISED as being suitable for a certain min spec. Most of us exceed the spec and yet the game still become unplayable after a couple of hours use.
Conclusion= This game is not fit for purpose and the developers are guilty of FALSE advertising and certainly in the UK at least, are guilty of breeching the sale of goods act.
Summary
All goods must be:- as described
- of satisfactory quality and
- fit for purpose
If they’re not, the retailer is in breach of contract and you have a claim under the Sale of Goods Act
In the UK at least, this is THE LAW, plain and simple. Just because this is a product that is downloaded rather than bought in a shop doesn’t mean the developers can make unproven claims and release a product that is NOT FIT FOR PURPOSE.
Yes, it’s the same in the czech civil code and as far as I know, it should be the same in the whole EU, since a directive sets it. And it doesn’t matter that they are from Switzerland, in the case of collision of laws, the consumer’s national law has to be used.
What I see as a problem is that the game was released in September 2014. Now it is January 2015 and still no solution for the biggest pain in the ass a.k.a. performance issues. The devs have known about it all the time and released ONE performance update and said that “huge lags are history”. Sorry, but I still have brutal lags, so this only update did not help at all.
- The forum ‘General Discussion’ is closed to new topics and replies.