Performance improvements for 0.21?

[Stealth2668]

It's not matter stock or mod parts is at all, amount of parts matter more.

I mean if the devs have some way of making their parts perform better than parts made by individuals will potentially less experience, then maybe the extra parts won't cause as much lag or something, but idk how it works.

[MR4Y]

I mean if the devs have some way of making their parts perform better than parts made by individuals will potentially less experience, then maybe the extra parts won't cause as much lag or something, but idk how it works.

Some of those less experienced individuals that made better parts now work for SQUAD. I don't think any game company should try to compete with modders.

[Stealth2668]

Ya, I'm aware of that but can you say all the modders did a perfect job on the mods? Perhaps a few of them are causing some issues and if you make a whole rocket out of them then perhaps that can cause significant slow down.

[MR4Y]

Ya, I'm aware of that but can you say all the modders did a perfect job on the mods? Perhaps a few of them are causing some issues and if you make a whole rocket out of them then perhaps that can cause significant slow down.

9 times out of 10, the game is the one causing issues, not the mod.

[Stealth2668]

I'm not saying it absolutely is the mods, just saying it MIGHT be. The point is and the main issue is the game's not optimized well and making anything big causes too much lag. I wanna try and build big projects but can't.

[sadron]

I just want a performance upgrade for when my rockets have tons of **** on them

[Lunniy Korabl]

I want for people to stop building massively inefficient rockets where most of the fuel is wasted on launching most of the fuel that is wasted on launching most of the fuel...

Seriously though, I'm sure more optimization is in the works. There's no point fully optimizing the game until all the features are in, but I think squad do a pretty good job of making each update run a bit better. I think I read somewhere that the planetary bodies will load dynamically in 0.20, which might break telescope mods but should increase performance. Hopefully there's a decent placeholder system that we can still see through telescopes. That would be rad.

[EleSigma]

The whole issue with cpu and physics performance in KSP has always spiked my anxiety about the future of the game. I'm afraid that they might hit a dead end, a point where they can't optimize the game any further due to unity limitations; forcing the team to switch engines and/or scrap a lot of features such as new planets.

That's my paranoid thoughts on the matter though.

[AlternNocturn]

Luckily for me, they announced memory improvements to the overall game. While I do eventually plan to upgrade my wimpy 2 GB of single-channel RAM to 4 gigs dual-channel, I have a 32-bit OS and the most I'll be able to use is 3.75gigs, which means the game as it is right now would still run like crap.

[Hyomoto]

Not so, Unity runs poorly on everyone's systems.

[Kuldan]

Well, to be fair, they had a big Performance Optimization Update.. we called it 0.13. (Yeah really, most of you are not here long enough to know, but load times used to be much higher before .13 .. that was before there was the .mu model for Parts and as much as I remember even before PQS Terrain.. ) .13 sped up the Game so much that it cut load times on my rig to 1/3 of what they used to be.

[lobsterbark]

Either you are exaggerating, or your on a laptop. But I do agree, ksp really needs some optimization.

[Reavermyst]

Can't wait for .2! My Kerbals will be conquering the Kerbol system at twice the speed!

[NeoMorph]

Guys it's 0.20 not 0.2... 0.2 came 18 versions ago. It's sub version twenty.

Sorry... pet peeve.

And we are getting some performance improvement in 0.20 too.

[Technical Ben]

Thats a problem with Unity itself, not KSP.

It's neither. You can add multicore support to the physics engine (it's been done by others), but it requires bespoke programming for that.

[Sabor]

Please do not listen to this at all, unity has little to no multi-core support for the physx implementation, while i5's and i7's will run the game better than mid range hardware, significantly even, it's not because of multithreading or "moar cores", it's because the sb/ib architecture is very fast in general.

In fact, for the budget minded, if you were wanting to upgrade more or less just for this game, I'd suggest an i3 dual core if anything.

I said right there in the post that it needs optimization on using multiple cores. Unity uses them but to a poor, miserable extent. Still having a beefy CPU is going to help

[Fel]

The whole issue with cpu and physics performance in KSP has always spiked my anxiety about the future of the game. I'm afraid that they might hit a dead end, a point where they can't optimize the game any further due to unity limitations; forcing the team to switch engines and/or scrap a lot of features such as new planets.

That's my paranoid thoughts on the matter though.

They paid ~$2000 for the unity license; and are a fair bit integrated into unity... I would hope that they didn't have to makeup that difference.

Unity runs mostly in a single thread, specifically physics. Because of this it is impossible for the Dev's to simply 'go multicore'. Since Unity isn't 'thread safe', it is impossible to access game objects from additional threads. I'm not sure how much help something like UnityExtender may help with this either, since at the end of the day PhysX is holding everything up too.

After wading through some of the material, one thing became apparent, OSX Refuses to play fair. (Actually, the accusations appear to be that OSX says "I'm smarter than the developer" and tries to multi-thread the process even though Unity requests to be single threaded. Working against these types of systems is bound to cause multi-platform difficulties.)

There comes to be a point when these petty squabbles should be put to an end; the kernel is SUPPOSE to make things EASIER on the developer, not more difficult by forcing platform specific quarks only to isolate developers on a particular platform to intentionally sabotage efforts to make multi-platform development. (And yes, microsoft is plenty guilty here as well with direct x or otherwise; point is just that this is clearly just squabbling, and it hurts developers in the end.)

[_Aramchek_]

I said right there in the post that it needs optimization on using multiple cores. Unity uses them but to a poor, miserable extent. Still having a beefy CPU is going to help

More importantly though, you suggested that to get the most from the game you should get a quad core with ht....not a good suggestion.

[Stealth2668]

The whole issue with cpu and physics performance in KSP has always spiked my anxiety about the future of the game. I'm afraid that they might hit a dead end, a point where they can't optimize the game any further due to unity limitations; forcing the team to switch engines and/or scrap a lot of features such as new planets.

That's my paranoid thoughts on the matter though.

I was thinking the same thing. I would assume they would somehow add multicore support in the future when the game is more developed but wouldn't that be the first thing you do since quad cores are the most popular set up? Maybe they aren't able to do it for some reason? In that case we are screwed if we want to build bigger rockets with more stuff, and with the addition of new stuff/parts in the future, performance can only go downhill from here and we're already near the bottom

[_Aramchek_]

performance can only go downhill from here and we're already near the bottom

The game runs well...if you've got the cpu power for it.

And multicore support isn't something that can just easily be thrown in to the engine.

[Stealth2668]

Needing a super cpu doesn't make the game run well, you're just powering through the problems. And I realize multicore support isn't easy, never said it was.

[lazarus1024]

The whole issue with cpu and physics performance in KSP has always spiked my anxiety about the future of the game. I'm afraid that they might hit a dead end, a point where they can't optimize the game any further due to unity limitations; forcing the team to switch engines and/or scrap a lot of features such as new planets.

That's my paranoid thoughts on the matter though.

I wouldn't be. I don't see them making the physics calculations more complex, and that is what is slowing things down. The worst you might see is that you'll never be able to build bigger rockets until you have a faster machine.

They already announced that they'll load planets/bodies dynamically instead of all at once, so there will be little to no impact to having tons and tons of them floating around out there. It is questionable to me how much of a performance impact loading them dynamically makes other than a memory footprint issue as it isn't like they are doing physx calcs with them generally.

I am sure they'll make improvements as they go along, I just wouldn't expect any "150% moar speed" to show up ever. Not unless Unity/PhysX fixes the issues with multithreading.

SQUAD could potentially do some optimization though. I don't know Unity really, but I'd imagine they could give an option in game to simplify physX calculations by allowing things like bonded parts for solid connections as an in menu option. So when two parts are attached they behave as one part (of course then you have the issue of less real life interactions).

I'd imagine they'll chip away at performance issues, but the big one is still allowing multithreading for PhysX. The good news is computers are only getting faster. Sad news is I'd personally prefer not to have to wait 3 more years to get a machine that can handle 30-40% more parts.

[Blackstar]

I don't see them making the physics calculations more complex,

One word: Aerodynamics.

Fixing that properly involves doing a lot of extra calculations to model the airflow...

[Guest]

Something that keeps getting lost in the discussion of code performance is that KSP is still under heavy development. This means the program contains lots and lots of debugging code. Debugging code takes additional cycles to run in order to do its job. Cycles that would otherwise be spent on game elements. Once the debugging code is removed, we should see an inherent improvement in performance. How much? That depends on the amount of debug code present. But 30-years experience of writing code tells me that debug code, while vital, will negatively effect performance of a program, and you cannot make a proper evaluation of a program's final performance characteristics with debug code active.

Be patient. The people at Squad are a clever lot. I'm confident they'll get things sorted out in due time.

[Zatie12]

I've noticed performance starts to drop when there are about 300+ parts. When there's 400 it's really getting laggy. When there's 500+ the lag is unbearable. And 500 parts really isn't that much, it sounds a lot but it's not. This includes all utilities, components, struts, etc etc. I started launching and building a large space station but I had to abandon the project because once I had docked together a number of modules it just lagged so much it wasn't fun to play that mission anymore. I have an Ivy Bridge 3770K running at 4.5Ghz and the main thread totally saturates out the working CPU core. I can't really throw any more CPU power at the game. The space station orbits Kerbin hoping for some performance improvements some date in the future