Very low performance - analysis by a professional programmer

At this point in time my review is the highest rated negative one, so I thought I might thow my 3 cents to the discussion and justify my negative opinion of the game.



This is going to be part 1 - Performance, or frame rate issues.



I'll start with an important disclaimer. I am a software developer with approximately 10 years of professional experience. The precise field I work with is not games development, but it is a related - I do visual electronics design software, so things such as routing, drawing and GUI design are related to TpF.



Moreover. I once led an effort to create a spiritual sequel to Transport Tycoon called Transport Empire. For that project I have made an extensive research into 3D graphics, scene management and related fields.



Additionally - what I do below is what I intuit from how the game works and what I know. I might be wrong as I did not see the source code.



So. Let us start.



The game is divided into two major performance eaters - graphics and simulation.



If you want to see how much each of those causes problems enable Steam FPS overlay.



Load up a sensibly crowded save game and then, just pause the game. This stops the simulation and thusly the major burden is graphics. Now fly around the map and you'll see that viewing stuff, especially cities, up close causes frame rate drops. As well as looking at several cities or big clusters of objects.



Then. While paused go to a corner of the map and look _away_ into the void and see the frame rate. You should get the maximum this game can muster.



Now unpause. At this moment simulation dominates and graphics does not so much. This is the frame rate at which the engine just needs to decide that nothing of substance is to be drawn, and running simulation taxes your CPU.



I own i7 5820k with radeon 290, gobs of memory and an ssd. I loaded an almost complete USA mission 6. My score is, at max detail:

- Looking and Houston with paused - 13fps

- Looking at the void with paused - 48fps

- Lookingat the void with simulation running at 1x - 39fps



We can clearly see that this game is very bad at managing display of several boxes.



So let's start with graphics.



TpF level of detail system is totally broken, which leads to massive performance loss, even on powerful machines. Games such as Skyrim or Far Cry have shown that drawing extensive scenes is perfectly possible with high frame rate. Why then TpF is unable to do this? What passes for graphics in TpF should run at flat 60fps on just about any 5 year old PC. At least for an average sized game ( say - 50 trains, 500 trucks and 50k of people on the map ).



Answer requires some prefacing.



Modern GPUs are very proficient at processing gobs upon heaps of triangles and gigabytes of textures. By modern, I mean 10 years old or younger. What is been a bottleneck is scene complication. Roughly speaking - drawing 10000 triangles with 10000 textures is much slower then drawing 1000000 triangles with one texture. Most techniques used in modern games are about ensuring that the most variety is achieved with least so called 'draw calls' or 'batches'. The whole hubub about Vulkan/DX12 is because they allow multi-threaded access to the GPU and thus allow to core-count increase of draw calling - old APIs allow single threaded access only.



TpF and TF are very expedient with their draw calls. When I was playing TF, I have shortened the draw distance for people, trees, little doodads and private cars to about 100 meters and removed chimney smoke emitters. Frame rate went up by 50%. This leads me to believe that TpF engine is very, very poor at managing what it displays - such as using a technique called 'instancig' and/or restricting particle emitters and animated people to closest LoD level, among other things.



Moreover - TpF LoD is static, written into the object configuration file, and not calculated dynamically from the volume of the object bounding box and screen resolution. Not all objects even have all lod levels and some objects are displayed in their full glory even if they are 1km away.



But that is not all. TpF LoD seems to be just a simple reduction of polygon count. As I already said, modern GPUs don't really care all that much unless you go to absurd levels ( Hairworks, cough, cough ). A proper LoD system would switch to a more efficient 'draw call' saving method of drawing content. For example - far away cities should be drawn as a piece of static geometry with a simple greyish/bluish color. Essentially a whole city would be a single 'draw call'.



I assume some of those problems are because TpF is generating its buildings procedurally ( there are lua scripts for that, for those intrested ) and thus each building in a city is a single draw call. This gets expensive as city size goes up.



Speaking of cities, do you see all those people in the city? All of those are animated using a technique called 'skeletal animation' which, if not implemented correctly, is very, very CPU intensive.



TpF is very, very expedient when it comes to detailing loads of little, pointless things, which eat into the performance as well. For example train car interior. Loads of people drawn where none should be. Performance loss. Another example is trackage - which might look fine at close zoom, but as we go 20-50 meters above it quickly turns into expensive show of garbled pixels, because even the best AA cannot make it look good. All that at the expense of the CPU.



You might have noticed that dragging long stretches of track, and especially, bridges is very slow and choppy. This is because while doing so you are seeing a long stretch of geometry - trackage, bridges and whatnot, which was created CPU side and then copied into the GPU. This operation is extremely memory and CPU intensive and will murder any modern computer with descrete graphics. This could be solved if instead of dragging the entire model we merely dragged its much simplified silhuette made of cubes and quads.



TpF tries to hide simplicity of its world by going into absurdly high resolution textures and models. This might look somewhat good, however it comes with a cost written in loading times, memory footprint and memory bandwidth.



The last thing graphics wise, which causes major performance loss is insistance of TpF to open loads of windows with a viewport in it. Trains, pedestrians, trucks, planes - all are capable of opening one. While those seem to be very small, they are a _major_ performance eater, especially if there are several of them opened at once.



What can be done:



Right now as immediate relief:



Graphical settings for:

- visible particle systems : none | essential ( engine main chimney, if exists ) | all

- visible agents : none | close ( 75m ) | far ( 125m ) | all ( as lod dictates )

- detail visibility : none | close ( 150 m ) | far ( 250m ) | all ( as lod dictates ) ( benches, lanterns, bushes, private cars, rocks etc )

- interiors : none | all

- track/road dragging : simple ( silhuette ) | full



In the long term TpF needs to learn to manage what it displays efficiently. Basically it needs to switch to more draw call friendly methods of displaying stuff as this stuff is further away.



I think that fixing the graphical part of the issue is more pertinent because, frankly, most people never reach a stage of simulation that is significant enough to cause significant performance loss. Speaking of which.



Another performance eater of the game is its simulation - that is all those trains running around, trucks being stuck i traffic and people strolling the streets in a search of purpose.



Let's start with a sour note for UG team. You people done goofed.



Strategic games are, by their very nature, CPU intensive. As the size of the map goes up, the amount of stuff that needs to be taken care of grows linearly with _area_ of the map. So switching from 5x5km map to 10x10km increases the CPU load four times. This was apparent 10 years ago in Supreme Commander. A game that allowed to play massive maps with massive amount of units. Some online matches could make the simulation crawl at 1/8th of design speed (altho still at 60 displayed fps on my then GPU - GTX 8800). That involved thousands of running AIs.



However, most strategic games are composed of weakly interacting agents doing their thing. Which means that competently designed simulation should be easily spread to several threads. In all honesty, a game such as TpF should spread easily to even the beefiest single socket CPUs these days. Not linearily, but it should. Ashes of the Singularity spreads to at least 8 cores.



That being said. Not much I can gather from how the game behaves, except for some oddities when it comes to the infamous "end of month" slowdown. This is most likely because UG did not spread whatever calculations the game is performing uniformly all over the entire game month, instead they bunched them and the end result is widely known.



However, there are a few issues regarding performance which makes me suspect of much being amiss.



First of all - you might have noticed that the game tends to slow down with longer play sessions. This suggests that TpF is suffering from memory fragmentation - this causes the game to get progressively slower. Which in turn makes me believe that UG did not roll off their own memory manager.



However, there is also an alternative explanation of this phenomenon. In programming there is a thing called "computational complexity" which, in shortest description, determines how fast the need for processing power grows as the simulation goes up. The thing is, that in certain algorithms it may happen that doubling the size of the thing calculated causes 4 fold increase in the need of processing power. TpF might suffer from this because, as the complexity of the transportation network goes up, so goes the processing power needed for agents to find their way to destinations.



The typical sign of such problem is a rapid deterioration of performance as complexity of the simulation creeps up. This gets compounded by lackluster graphical performance, which quickly will bring any machine to its knees.



However, this is theorycrafting - without a peek at the game's source code and without proper profiling it is difficult to judge, as those issues are not as apparent as graphical stuff is.



Overall however, the game seems to have loads of potential for optimization. At this moment I think that most people would benefit from more efficient graphics subsystem and that can be sped up quite much by simply adding an aggresive LoD system.