Core Xii wrote: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?