Interstellar 1080p 60fps
Billie Kjergaard
KSP isn't, by a long way, the most graphically taxing game out there. Compared to the kinds of graphics demands we see in other modern games - even on their lowest settings - the graphics demands in KSP are minimal by comparison, especially in vanilla. Which makes it so frustrating how this game can grind to a virtual halt just because you wanted to install one or two mods, or because you happened to have been playing for 5 hours straight. Even though my PC is at least 7 years old (2GB video RAM, 16GB of installed RAM, an i7 multicore processor) it still more than meets the game's current MINIMUM specifications as set by Squad. The fact an old bucket like mine can still run this game fairly well, even with many mods installed, says it all. But do I sound like an entitled little gamer when I say that if I have 7GB of RAM available (as shown in Task Manager) I expect the damn thing to be able to access it, and it can't. Even in 64-bit! Or perhaps this is still more of a Windows problem than a Unity problem? Or both?
I just get the feeling that KSP could and should be able to run at least 60fps even with many mods installed, and it's frustrating that it doesn't. Depending on the scene I can get maybe 24-30fps (in v 1.6.0), but that depends heavily on how busy the scene is. While docking with a moderately sized station it can drop to 9-12fps (I thought 1.6.0 was suppose to improve multicore rendering for multiple ships, but I really can't see any difference); in maximum time warp I've seen it drop to 6fps and then shoot back up to 20 then back to 8. Indeed the framerate can be VERY inconsistent with frequent lag, and again I can't tell if it's my PC (toggling V-sync makes little difference, nor does setting a frame limit) , the mods, or the game engine. And please don't tell me to stick to vanilla; mods have defined this game just as they have defined SkyRim. Even Squad members themselves (Nova Silisco for example) contributed mods to this game. KSP just isn't appealing to me any more in vanilla, because I KNOW KSP can do so much better. The forums are always full of players suggesting or requesting new mods, especially visual enhancements, which says to me the community wants this game to be as good as it can be, and we really need to be asking if it is. Even after Unity5 and 64-bit mode were introduced.
I'm not a programmer but I can't help feeling that despite the move to Unity5 and its undoubted improvements, KSP still isn't running at its full potential; and it feels as if it never will as long as it's still using Unity. Programmers, mod-makers feel free to disagree.
My suggestion to Squad-Private Division: stop producing DLC and focus instead on continuing to improve how this game already uses available resources. No point in creating more 'stuff' for the game if in turn the game becomes so bloated and slow no-one can play it. No-one should need a StarCitizen-type setup to play this game satisfactorily, it ain't Star Citizen!
Even the top processors will have trouble keeping up with the physics, mind you, on every single part in game. People that like to build massive vessels with hundreds of parts tend to have a problem with that and have made many threads like this one.
In any case, I found that frame rate some times drops badly. I actually looked at it and found that steam overlay was taking significant amount of time even when it wasn't rendering anything. Disabling it gave some nice improvements.
CPU, specifically single core performance is the limiting factor due to all the physics calculations. Considering that this is the opposite of how 99% of games work, it's not likely to be improved, quite the contrary; newer cpu's are going the way of more and more cores, further diluting single core performance. (Currently KSP can use multiple cores if there are multiple vessels on screen, one per. You can't split a single physics object up between cores though.) Barring some huge advance in multi-threading physics calculations on a single object (no small task mind you), it just is what it is.
Why is "multi core'ing" a single physics object difficult? Well, to use a very simplified example; imagine you have one dish to wash in the sink, with one tap, one dish rag, and I give you one helper. Do you take turns scrubbing? Wasting time passing the dish back and forth? Do we break the dish in half, each wash his piece, then re-assemble them at the end? Do you hold the dish and operate the tap while he scrubs? Do any of these sound faster or neater than just washing the dish by yourself? Now imagine I give you 7 helpers! 8 people in total...how will you utilize them to wash that single dish without having them get in each others way or just complicate the process? Kind of sounds like the fastest, easiest way is still to have 1 person just wash the dish while the other 7 watch right? Now imagine that for every helper I give you, I make you all younger, thus making all of you less proficient at dish washing; who can wash a single dish faster? A lone 40 year old, or 10 4 year old's? (One powerful processor vs. several weaker ones.)
I think KSP's performance problems come from a couple of sources. Firstly, the way KSP simulates vessel physics as a set of connected rigid bodies. It's a "natural" way to do it when your vessel building works that way, and a lot of somewhat-realistic structural behaviour emerges from it. But it's inherently difficult if not impossible to multithread and CPU demand scales worse than linear with part count. Optimising the physics engine will only ever increase the part count needed to lag the game, to actually get rid of physics lag would require a completely different way of simulating vessel physics. Treating the whole thing as rigid (besides robotic joints) would do the job but then you wouldn't get the spectacular vessel explosions that the game has become famous for.
A second source is the Unity engine's problems with garbage collection. In simple terms, the entire game has to periodically freeze for the engine to do some behind-the-scenes stuff. This is why KSP often experiences regular stuttering. The problem affects any Unity game. It can be mitigated with clever programming but that requires coders to do that. Important to the current discussion, that includes developers of game mods. The garbage collection problems will only really go away when Unity fix it. (And then KSP has to be updated to use the new Unity.)
Wow, really? My game flows at stable 60 FPS with some times getting down 50 FPS. I had never encountered the problem with a ship over 200 Parts... Maybe I need to install more mods? Anyway, as everyone above said, it's the physics that kill your PC. As @cantab mentioned, unity is a garbage collector... I wish there was an engine like Unity but without the garbage part...
CPU is a finite resource - you use CPU cycles on something, you can't use that cycles on anything else. And when some CPU vendor suddenly has to disable a crucial performance feature on their CPUs due bad decisions on the past (I'm talking to you, Intel!), then suddenly a lot of CPU cycles are not available anymore and things that used to work fine now don't.
The problem with home made Add'Ons is that very few people are skilled programmers able to take the best design and implementation decisions - and the ones that are, most have very little sparing time in order to check their decisions against a nasty and harsh entity: Reality.
There're mainly two kind of memory allocations on a 3D engine as Unity: persistent ones (used for meshes, textures, code and static data) and temporary ones (used for meshes transformations, dynamic texturing, and all kind of temporary memory as the one used on "foreach" loops).
That temporary ones are the problem. At 60 FPS, each frame you draw will consume a fraction of the memory as temporary data - and almost none of "long term persistent" ones. At 120 FPS, you double the temporary memory allocation for doing the same job (one second of the game). And this is why I recommend people to use the lowest FPS they can be comfortable using - to lower the demand for that temporary data and relief a bit the Garbage Collector.
If all that data being allocated for temporary tasks each frame, instead of being drawn from the HEAP managed by a GC, could be drawn from a Mark/Sweep one, you could simply get GC out of the equation on the FPS thingy: on the beginning of the frame, the Engine would Mark the current position of the Pool, and let things eat the memory as they please. On the end of the frame, the Engine would Sweep all that memory back to the pool.
To have both managers alive at the same time, one of them would need to consume memory bottom up, while the other top down - the the GC, at the rare occasions it would need to be called, would need to carry some extra tasks to compact the memory under its control to keep it out of the way of the Mark/Sweep engine.
Of course things will not work so easy on Real Life, but yet, it's an plausible way to minimize the impact of a GC dependent language on a Real Time, Mission-Critical task as rendering a 3D World on a heavily memory hungry game.
ff7609af8f