Multi-core support please!

[iTwins]

thank you, ALL for continuing supporting this awesome game. This is most definitely one of my all time favorite game even after all these years. Keep up the good work!

Anyways, suggestion:

Multi-core support?

I've been playing OpenTTD for quite a long time already and noticed that the game gets extremely slow, both CPU and graphics, even on a Core2Quad, nVidia SLI, 8gb RAM (but only WinXP x86). Any plans to support mult-core systems? That would be even more awesome. And when it does, be sure to remove the maximum 200 planes limitation

Many thanks in advance!

PS. How come there is a 200 planes limitation but you can have 250 trains (or more)?

PSS. The biggest plane only carries 400 passengers? Whatever happened to the Airbus A380 clone that can carry 800+?

[Yexo]

OpenTTD won't support multiple cores in the near future, as that will create lots of problems (mostly with multiplayer desyncs);

About the 200 plane limit, go to "configure patches" -> "vehicles" and set "Max aircraft per player" higher.

[Roujin]

And for different sets of aircraft, try some newGrfs. I recommend Aviators Aircraft Set

[ProDigit]

And for different sets of aircraft, try some newGrfs. I recommend Aviators Aircraft Set

Bad thing about multicores is that sometimes they are only 1,2GHZ per core.

I ran openTTD on a 2600 just fine, and it should run on a 2GHZ core processor just fine as well.
This would translate to a 4GHZ dualcore, or 8GHZ Quad core; even with large maps; since the game only uses 1 of the (multi)cores.

If you're experiencing troubles with a configuration like that, then something else must be wrong on your pc.

[planetmaker]

And for different sets of aircraft, try some newGrfs. I recommend Aviators Aircraft Set

Bad thing about multicores is that sometimes they are only 1,2GHZ per core.

I ran openTTD on a 2600 just fine, and it should run on a 2GHZ core processor just fine as well.
This would translate to a 4GHZ dualcore, or 8GHZ Quad core

You are mistaken. A 2GHz dual core is two CPU where each(!) runs at 2GHz. The CPU clock frequency isn't split among logical CPU units.

[Wolf01]

OTTD runs really better on my poor old laptop with 512MB and a 3.02GHz Intel P4 with 64MB ATi video card than in my flaming new desktop with Intel core2 duo 6600 2.4GHz (each core), 2GB of ram and nvidia 7950 with 512MB

At least in the laptop it runs more smoothly

[Zephyris]

I second that, my 2.8Ghz laptop runs it better than my 2.4Ghz quad core, but my quad core runs it along with TF2, Blender rendering, a load of image editing programs, windows media player and VLC

And on topic; multicore support is unlikely due to the fundamental structure of the game - there is very little that can be separated. CPU killer is all the pathfinding and vehicle movement code. This can't easily be separated to run on separate cores - the movement of one vehicle can affect every other vehicle. This is particularly obvious with trains and signalling, road vehicles and crashes with trains, and general cargo movement...

[ProDigit]

OTTD runs really better on my poor old laptop with 512MB and a 3.02GHz Intel P4 with 64MB ATi video card than in my flaming new desktop with Intel core2 duo 6600 2.4GHz (each core), 2GB of ram and nvidia 7950 with 512MB

At least in the laptop it runs more smoothly

Try to open taskmanager, to see if one process is or isn't taking lots of CPU while playing.
Also try to play the game in windowed version (or fullscreen if you allready did) and tell us if that makes any difference.
I'm running the OpenTTD v0.6.0 on both my single core Athlon 2600XP+ 1G 333Mhz ram, and my Core2duo T5500 (1,6Ghz x 2) with 2GB of DDR 2 4300 just perfectly fine!

Allthough I do have to say that running the game fullscreen I can't skip forward to fast forward the game, since it'll be running as fast as normal speed.
I do however can run windowed mode, and fast forwarding the game goes very well there!

[ProDigit]

I second that, my 2.8Ghz laptop runs it better than my 2.4Ghz quad core, but my quad core runs it along with TF2, Blender rendering, a load of image editing programs, windows media player and VLC

And on topic; multicore support is unlikely due to the fundamental structure of the game - there is very little that can be separated. CPU killer is all the pathfinding and vehicle movement code. This can't easily be separated to run on separate cores - the movement of one vehicle can affect every other vehicle. This is particularly obvious with trains and signalling, road vehicles and crashes with trains, and general cargo movement...

I am not 100% sure, but I thought windows XP also made use of the first of the multicores?
If like you say the finding routes for busses takes lots of CPU, it would be nice to let that be done by the second CPU?
Most pc's nowadays are either single, dual or quadcores. and most of them are single and dual cores.
If the game runs fine on a single core, above mentioned methode would work on nearly all multicore computers.
I wonder if it's really needed to run the game on 4 cores.

If you'd run it on 2 cores each of only 1,66Ghz, essencially you'll be running a 3Ghz processor, and have some load off the first processor, which is often adressed by windows itself.

[Zephyris]

One of the major limits for fast forwarding is the palette cycles, try turning off full animation If you want to fast forward when window. On a new map this changes my fast forward speed from ~2 days per second to ~1 year per 5 seconds.

If you'd run it on 2 cores each of only 1,66Ghz, essencially you'll be running a 3Ghz processor.

And if your running it on 4x2.4Ghz thats essentially a 9.6Ghz processor.

The advantage of multi core support wont be seen now particularly, its more future proofing. If the future trend of processors is only to increase the number of cores then OpenTTD can never have bigger maps and more vehicles than now.

[Wolf01]

OTTD runs really better on my poor old laptop with 512MB and a 3.02GHz Intel P4 with 64MB ATi video card than in my flaming new desktop with Intel core2 duo 6600 2.4GHz (each core), 2GB of ram and nvidia 7950 with 512MB

At least in the laptop it runs more smoothly

Try to open taskmanager, to see if one process is or isn't taking lots of CPU while playing.
Also try to play the game in windowed version (or fullscreen if you allready did) and tell us if that makes any difference.
I'm running the OpenTTD v0.6.0 on both my single core Athlon 2600XP+ 1G 333Mhz ram, and my Core2duo T5500 (1,6Ghz x 2) with 2GB of DDR 2 4300 just perfectly fine!

Allthough I do have to say that running the game fullscreen I can't skip forward to fast forward the game, since it'll be running as fast as normal speed.
I do however can run windowed mode, and fast forwarding the game goes very well there!

I have winXP, OTTD uses only the first core, I always play on windowed mode (1280x1024) and with large maps.. fast forward is not so fast
I must say I can play with 2 OTTD opened with the same savegame with no problems, one day after 3 hours I found anoter OTTD game running in background and I never noticed it, probably I launched it, loaded the savegame, did some stuff on internet and launched again it to play (but I didn't check if they ran on the same core or not)

[Core Xii]

And on topic; multicore support is unlikely due to the fundamental structure of the game - there is very little that can be separated. CPU killer is all the pathfinding and vehicle movement code. This can't easily be separated to run on separate cores - the movement of one vehicle can affect every other vehicle. This is particularly obvious with trains and signalling, road vehicles and crashes with trains, and general cargo movement...

I don't know anything for sure of course since I'm not developing this game, but I heavily doubt vehicles take each other into account when they choose their paths to their destinations. If this were the case, pre-signals would be pointless since trains would know how to get to the optimal tracks themselves.

Pathfinding, assuming OpenTTD uses something like A*, is actually quite possible to multi-thread. The thing is, multi-threading is not the easiest of programming concepts to grasp nor implement.

Rendering can also be multi-threaded, at the cost of extra memory. One thread renders the terrain while another one draws the vehicles on another canvas, then finally merging the two... etc.

[Zephyris]

See the arguments here, Im just regurgitating what I have read!

[Maedhros]

I don't know anything for sure of course since I'm not developing this game, but I heavily doubt vehicles take each other into account when they choose their paths to their destinations. If this were the case, pre-signals would be pointless since trains would know how to get to the optimal tracks themselves.

Trains are dependent on signals for which route they choose. If a vehicle has cleared the end of a signal block by the time the pathfinder gets to it on one client but not another the following vehicle might take two different paths on each client, which leads to a different game state on both clients and therefore a desync.

Edit: Rubidium's post here explains in more detail - thanks for reminding me, Zephyris.

[Rubidium]

Rendering can also be multi-threaded, at the cost of extra memory. One thread renders the terrain while another one draws the vehicles on another canvas, then finally merging the two... etc.

IF you like to draw ALL vehicles over the background, then you can do that, but... if you like vehicles that go behind a building to disappear partly, or vehicles that go into a tunnel disappear when the visually go into the tunnel you cannot multithread it.

Also about rendering (read building the GUI) and doing the simulation: you can make that multithreaded... *BUT* it means doubling the amount of memory and memcpy-ing the *complete* game state [0]. Complete being the several megabytes needed for the map array and then the other several megabytes to the rest like vehicles and such. It would ALSO mean that virtually NONE of the existing code is actually useable because they all use the same data backend. This would then mean probably adding about 50% extra lines of code to actually do the drawing multithreaded.

[0] Think about starting autosave every 1/30th of a second. Ever noticed the game to 'lag' a very little around the beginning of a month? Well, now imagine that to happen 74! times a game day.

Furthermore there has been a very naive implementation of this: not copying the game state and letting the GUI read the non-stable, crash causing intermediate game states. This implementation was about 5 to 10% slower on single core processors and 0 to 5% faster on multicore processors.

So now I ask you: is cloning the game state just to get 5% more speed on multicore processors and 10% less speed on singlecore processors really worth it plus the extra random crashes that are unfixable without causing slowdowns worth it? Doesn't copying several megabytes of game state eat a vast part of the 5% more speed on multicore processors?

[Core Xii]

IF you like to draw ALL vehicles over the background, then you can do that, but... if you like vehicles that go behind a building to disappear partly, or vehicles that go into a tunnel disappear when the visually go into the tunnel you cannot multithread it.

Yes you can. You just can't optimize it not to draw the vehicles that don't need to be drawn. The solution to the problem you describe is simple and well-known, and it's called a Z-buffer. When we draw a pixel on the terrain canvas, we also store its depth. Same for vehicle canvas. Then, when we merge the two, we draw the pixel from the two that has the least depth.

[Rubidium]

And what takes the most time in the whole rendering process right now, i.e. what scales the worst? It is determining which thing needs to be drawn in front of what other things. Sadly enough this is a O(n^3) algorithm.

Furthermore there are many 'hacks' to get everything rendered correctly, which I fear do not work with 'just' a simple Z-buffer, unless you mean that the O(n^3) algorithm I described before. How to actually define the 'magic' Z-buffer depth value so everything goes right [0]?

And how much speed does it take to actually draw the sprites? Because you first need to draw the complete landscape sprites, then draw the complete vehicle sprites and then 'if' your way over those arrays to create the final image. This would probably cost at least 4 times as much memory than we need now; a 256 depth z-buffer most likely is not enough and the thing we draw on is 8 bits. Furthermore, how much does this tactic degrade the speed of single core? Very likely much more than one would gain for multicores.

But as you are so confident about this, maybe you could show a non-glitchy proof of concept of your approach. My bet is that you are sacrificing more than what you're gaining.

[0] Vehicles are 8 pixels height, tunnel entrances are 8 pixels high and the catenary needs to be placed between there. Now magically give those the correct Z-buffer levels please. 'Simply' using X+Y+Z+bounding box isn't possible.

[fonso]

And you don't even need to implement z-buffering manually. There are things like OpenGL that implement much of that. Plus you get to use the GPU for drawing which should give another speed benefit.

Edit: this post is outdated. I haven't read Rubidium's before posting

[Rubidium]

About OpenGL: http://www.tt-forums.net/viewtopic.php?p=676957#p676957 (take special notice of DaleStan's comments)

[Core Xii]

How to actually define the 'magic' Z-buffer depth value so everything goes right [0]?

You can take it directly from the other depth algorithm that determines what goes in front of what, no?

This would probably cost at least 4 times as much memory than we need now; a 256 depth z-buffer most likely is not enough and the thing we draw on is 8 bits. Furthermore, how much does this tactic degrade the speed of single core? Very likely much more than one would gain for multicores.

Everything in computing is a trade off between something and something else. Like I said, it can be done at the expense of memory. However seeing as how OpenTTD barely uses any memory at all, especially for drawing, a 4x increase is negligible to the speed increase gained. As for single-core systems, just don't do it.

But as you are so confident about this, maybe you could show a non-glitchy proof of concept of your approach. My bet is that you are sacrificing more than what you're gaining.

To prove it would be to implement it. You're not seriously suggesting I should pick up the source and do it myself? I have absolutely no experience with this game and its engine. With the effort it'd take, I'd almost make a new game of my own.