Transport Tycoon Forums

Seeing that TTD runs on a single core processor I was wondering what exactly slows ones games down.

Does having lots of train signals have anything to do with it?

Any views?

There are too many factors to give a simple answer to this question, but big factors are (somewhat in order of importance):
- Lots of vehicles.
- Large map
- More specifically lots of ships (although it's not as big of a problem as before, I guess this is still important).
- Some NewGRFs sets, ie ECS with many industries on the map used to take a fair chunk of processing power due to all animations. Not sure if this is still noticeable if you have lots of vehicles.

Will it ever be possible to recode TTD to run on multiple cores and system resources?

LordNokon wrote:Will it ever be possible to recode TTD to run on multiple cores and system resources?

IIRC, that has already been discussed. It's not just a minor change, it would need a great redesign of the source.

For you, the best solution is probably more in using a better desktop (openttd is not a such heavy game, anyway) or in tuning the game/your gameplay accordingly to your resources.

What are you doing to have a such resources problem ? Until recently, i used to play on a p4 with 1Go Ram (already running KDE), and it was fine.

If you are not doing anything special, you should try to figure out if there is not some problem on your desktop.

LordNokon wrote:Will it ever be possible to recode TTD to run on multiple cores and system resources?

there's lots of different "possible"s, depending how much effort you're willing to spend. "the impossible just takes a bit longer", they say.

that said, the effort would likely be so high that you should rather write a new game from scratch, so you get rid of most of the other design limitations this game has. so "make OpenTTD (truly) multicore" is rather on the "impossible" side. there are bits and pieces you can parallelize here and there, but maybe you get 15-20% speed increase out of it, never 100% like you could with two independent threads (or more with more threads), as you cannot untangle the data dependencies without sacrificing some core features (especially multiplayer). and you get a performance decrease for people who have just one core (think not only old computers, but handheld devices, dedicated servers, etc.

This might sound naive... But I'm not a programmer so I really wouldn't know.

But how hard would it be recoding a game of 4mb-12mb against any new games sizing 7GB-18GB to be able to using maximum resource available

LordNokon wrote:This might sound naive... But I'm not a programmer so I really wouldn't know.

But how hard would it be recoding a game of 4mb-12mb against any new games sizing 7GB-18GB to be able to using maximum resource available

Of those huge games, about 7-18GB is graphics, videos and sounds. I would reckon the actual amount of logic is less than the amount of logic in OpenTTD.

Take a first person shooter. What kinds of calculations do you have? Some updating of the location of the actors, possibly some AIs running around, some handling of shooting/flying objects, and finally a lot of fancy 3D drawing, lighting and effects. So... you have a game state of maybe a few hundred variables? You just clone the game state and then let AIs do their thing and update the locating the next cycle, you update the game state for the changes the players caused and flying objects, and then you pass that to the drawing engine. The last will take most time, however you can split up most calculations by just dividing the area that needs to be drawn into <number-of-cores> different sections and let them be drawn concurrently.

Now OpenTTD. What kinds of calculations do you have? Lots and lots of vehicles moving, including pathfinding (imaging trying to find a route to your holiday location and all you can see are pieces of the map in 100 by 100 meter), AIs doing pathfinding calculations, cargo being moved around, signals being updates. This game state has thousands, tens of thousands and maybe even a hundred thousand variables. Thus copying the game state is too expensive; often you can notice when an autosave happens because the game momentarily freezes. The time of that freeze is the time needed to just copy the game state.
Now you would say, oh well, just let the vehicles do all their expensive stuff concurrently. However, what happens if two vehicles are nearing the same signal block at the same time. In multiplayer this causes problems if player A gets train 1 there first, and thus passing into the signal block, when player 2 gets train 2 there first (different scheduling by the OS or something); then the game states are out-of-sync. Okay, lets split it on vehicle type; same problem with level road crossings, and at stations. What if for player A a road vehicle loads the cargo instead of the train that does it for player B. Similarly with a vehicle unloading before another vehicle loads or vice versa. This basically means that all vehicle/cargo logic needs to be run sequentially. If you add all these dependencies there is very little that you can split in the game logic; basically everything is depending on vehicles/cargos in some way. Tree growth -> lumber mill -> cargo production, flooding -> station (part) flooding -> cargo movement, disasters -> vehicle destruction, town growth -> cargo production.
The things that can be split off are usually not game logic related; actually drawing, although the determination of what to draw must be in sequence with the game logic due to the time needed to clone the game state, music playback, savegame compression, sound playback. Interestingly all these things that can be 'easily' done in a separate thread are already done in a separate thread.
If you want to split things in the game logic, then massive changes need to be made regarding the moving around of cargo and only then there might be some ways to split the game logic in independent threads. However, that would mean delaying cargo handling/moving/payment by a tick.

LordNokon wrote:This might sound naive... But I'm not a programmer so I really wouldn't know.

But how hard would it be recoding a game of 4mb-12mb against any new games sizing 7GB-18GB to be able to using maximum resource available

http://www.ohloh.net/p/openttd attributes to OpenTTD's source code 59 person-years worth of work.

LordNokon wrote:But how hard would it be recoding a game of 4mb-12mb against any new games sizing 7GB-18GB to be able to using maximum resource available

If we'd include zBase in the OpenTTD download it would become +- 280MB. Do you think the effort of recoding OpenTTD would suddenly increase by 2000%? That alone shows that the size of the graphics have no relation to the effort of coding.

Just as a side note. What I find actually kills performance most is the renderer. Trees, in particular. If you set the trees to be completely transparent, expect some nice speed boosts for laggy games.

Please do excuse the bump, but I do feel it was something worth noting. And the topic isn't that old anyway.

I am playing a 2048² map, I have almost 2000 trains going around, 100 ships

can I expect the game to run fluently? ^^

schorfi wrote:I am playing a 2048² map, I have almost 2000 trains going around, 100 ships

can I expect the game to run fluently? ^^

You're the only one who can test if it runs fluently on your PC. It might, given a fast PC and simple networks, mostly canals instead of open sea for the ships and not zooming in or out. Than again it might not, if any of the above is not true. You are definitely stretching the limits.