"All-Around Optimizations, upgrading Unity" in .23, what does it mean?

[cy-one]

Heya, I just read through http://forum.kerbalspaceprogram.com/content/234-0-23-Update-News and was curious about that part.

* All-Around Optimizations

We’re going through each line of game code and making sure things are getting done as efficiently as possible. We’re also optimizing the asset loaders to reduce loading times, and upgrading to the latest version of Unity, to take advantage of all its new tweaks and fixes.

Does anybody know what those "new tweaks and fixes" are and how we will notice them?

[Mihara]

The optimizations are just that -- going across the code and tweaking every little inefficiency you see without actually changing the structure. It remains to be seen just how thorough with it they really are and how much it helps, but it can make a lot of difference if done in a sufficiently massive fashion..

As for Unity tweaks and fixes, check the release notes for latest version of Unity, which is 4.3, and compare it to 4.2, which I think is what it was previously: http://unity3d.com/unity/whats-new/unity-4.3

[cy-one]

That's too... "dev'y" for me I'm more curious about if and how the user will see those changes. More parts before the game slows down? Less lag when switching from non-physics to physics-render (flying near a station and crossing that ~2.5km border), etc?

[MiniMatt]

Unity is the game engine used to create KSP. Like other game engines (CryEngine, Source etc) it's an environment within which one can hang scripts & art and tie the whole thing together & add some tricks of it's own like lighting, physics calculations etc. Game engines can introduce bugs which would be common to all games created with that engine & that version, like, for example, memory leaks on instantiating objects & art. So game engines get updates to remove those bugs - but programmers working on their own games have to test those new versions with their existing code to make sure no unforeseen problems or incompatabilities are introduced. As such, a new version of Unity does not mean that every mid development game can just switch over to the new version.

As for how we'll notice them, I think I recall a quote saying something like a PC which is currently struggling at 20fps to display a 400 part ship can, under the new KSP version, display a 700 part ship at 40fps.

So largely we should perhaps be looking for better display of larger ships and a guess at better loading times between scenes (like VAB to launch pad etc).

[Gemberkoekje]

That's too... "dev'y" for me I'm more curious about if and how the user will see those changes. More parts before the game slows down? Less lag when switching from non-physics to physics-render (flying near a station and crossing that ~2.5km border), etc?

The goal is to make the game smoother in all cases (So everything you describe) without actually changing the game.

They've specifically described that a system which could run 400 parts at 20 FPS, the same system can now run 700 parts at 40 FPS.

[cy-one]

As for how we'll notice them, I think I recall a quote saying something like a PC which is currently struggling at 20fps to display a 400 part ship can, under the new KSP version, display a 700 part ship at 40fps.

So largely we should perhaps be looking for better display of larger ships and a guess at better loading times between scenes (like VAB to launch pad etc).

Squeee, this would be so unbelievably awesome... I like building huge stations, like the ISS (never build that, as I like to build "own stuff"), as they just look amazing... But it's always a chore building them... Or docking some ship to them.

It would be so great if I would be able to handle more parts in my game... \o/ Let's hope that will turn up similar to this.

Edit: As two people now have said the same thing... Do you remember the source of it? Not doubting it, but would like to see/read it myself

[-RanZ-]

As for how we'll notice them, I think I recall a quote saying something like a PC which is currently struggling at 20fps to display a 400 part ship can, under the new KSP version, display a 700 part ship at 40fps.

That would be a massive upgrade. Do you remember who said that? I have a hard time believing it is that great of an upgrade but it would be sweet if it was.

[Murph]

I think they mentioned the performance in the KerbalKon opening stream. There's many factors which go into performance, so it's not an absolute guarantee that everyone will get double performance for their large ships, but hopefully most people will get at least some improvement. It all depends on what was the limiting factor for you in 0.22, since it's not going to help all that much if the real problem was a chronic shortage of RAM in your system, for example.

[Comrade Jenkens]

The goal is to make the game smoother in all cases (So everything you describe) without actually changing the game.

They've specifically described that a system which could run 400 parts at 20 FPS, the same system can now run 700 parts at 40 FPS.

WHAT!!! That's a huge upgrade. 400 parts is generally the largest ships I can tolerate atm so this will really help.

My bottleneck is my processor, an I5 3570K.

[Santoron]

That would be a massive upgrade. Do you remember who said that? I have a hard time believing it is that great of an upgrade but it would be sweet if it was.

It came from one of the Kerbalkon streams a couple days ago.

I know what you mean, it's the kind of news you can't help but be skeptical of until you see it yourself, but several of the Kerbalkon streamers specifically praised .23's responsiveness and increased performance. It is easily my most anticipated feature of .23!

[-RanZ-]

WHAT!!! That's a huge upgrade. 400 parts is generally the largest ships I can tolerate atm so this will really help.

My bottleneck is my processor, an I5 3570K.

That's not a bad CPU, just OC it!

[cy-one]

My bottleneck is my processor, an I5 3570K.

i5 2500

RAM isn't an issue, as I have more RAM than 32bit-KSP can handle, sadly.

[Rizendell]

I would have REALLY liked to see "Fixed the audio popping while the engines are firing between loops of the same sound bit".

[Comrade Jenkens]

That's not a bad CPU, just OC it!

Not a clue how to do that, even replacing my old processor was a new experience. Too bad KSP can't really use my RAM or GPU.

I'm very exited to find out how optimised KSP will be by version 1.0!

[Rizendell]

Just saw this in the unity patch notes "•Added support for some DirectX 11.1 features (low precision shader variables, UAVs in all shader stages, logical blending operations etc.); note this works on DX11.1 runtime only (Windows 8 and up)."

So they are moving towards dx11.1 but it seems they forgot about 64 bit still... which is just laughable.

[Murph]

Just saw this in the unity patch notes "•Added support for some DirectX 11.1 features (low precision shader variables, UAVs in all shader stages, logical blending operations etc.); note this works on DX11.1 runtime only (Windows 8 and up)."

So they are moving towards dx11.1 but it seems they forgot about 64 bit still... which is just laughable.

I sincerely doubt that they "forgot about 64 bit". The simple fact of it is that Unity has had showstopper bugs on 64-bit for Windows and OSX. KSP is not alone in being unable to go to 64-bit. They can't fix fundamental bugs in the Unity engine itself, they have to wait until the engine is finally fit for purpose on 64-bit.

[Commissioner Tadpole]

This might help with my Duna base.

[DMagic]

Mu was the one who mentioned that performance jump, the 700 part craft at 40fps, but he also said not to read too much into that, it's just one person's experience.

And an i5 3570k is about as good as you can get in terms of CPUs for KSP. The higher end i7s and Xeon CPUs don't really make any difference because they are all about multiple cores and threads. Even at stock speeds that CPU will do better than all but a handful of other options.

[_Aramchek_]

Not a clue how to do that, even replacing my old processor was a new experience. Too bad KSP can't really use my RAM or GPU.

I'm very exited to find out how optimised KSP will be by version 1.0!

Eh, just ignore all the "ram" talk anyway, people on this forum don't generally seem to understand how ram affects performance in a game. It's not a magic bullet that improves framerate.

Your cpu is fine, I run a 3570k@ 4.5ghz and the game is nice and snappy, as for overclocking, here's a nice in depth guide. It's not tremendously difficult or dangerous, just follow the guide.

http://www.overclock.net/t/1247413/ivy-bridge-overclocking-guide-with-ln2-guide-at-the-end

[Eric S]

So they are moving towards dx11.1 but it seems they forgot about 64 bit still... which is just laughable.

The Unity devs haven't forgotten about 64 bit, there are bug fixes listed for 64 bit clients, and one showstopper that was 64 bit windows client specific. I just don't think they're focusing on it. I don't know too many games that are severely restricted due to 32 bit addressing space. KSP happens to be one of them, but that by itself doesn't mean that the problem is common enough for the devs to prioritize it.

[Vrana]

Eh, just ignore all the "ram" talk anyway, people on this forum don't generally seem to understand how ram affects performance in a game. It's not a magic bullet that improves framerate.

Usually, people on this forum do not wish for more RAM or a 64bit version because of framerate. They do it so they can install more mods. At the moment there is a limit as to how much you can mod the game and this limit is set by the amount of RAM available to the 32bit game engine.

[Arran]

I sincerely doubt that they "forgot about 64 bit". The simple fact of it is that Unity has had showstopper bugs on 64-bit for Windows and OSX. KSP is not alone in being unable to go to 64-bit. They can't fix fundamental bugs in the Unity engine itself, they have to wait until the engine is finally fit for purpose on 64-bit.

Funny you meantion this, check for the giggles the dev posts on Planet Eplorers, also an indy game build on the Unity Engine, and for the new build that bout to released, they stumbled on a last minute Game Breaking bug in the 64Bits version, and are considering if they cant fix the issue, they might prospone the long awaited 64Bits version of PE, and only release the 32Bits version again..

I can understand SQUADS chouse to keep the 64bits version on hold if i follows Pathea's endevours on Unity and notice a very simulair developing "simularities" atm they doing alot of preformace tweaks, and adding more and more to the game..

Totally different games, and all, they hardly can compare on every front, cept the issues and "work-arounds" due unity clashes with the devs visions, and how the game "matures", there they seem suddenly striking alike.

[_Aramchek_]

Usually, people on this forum do not wish for more RAM or a 64bit version because of framerate. They do it so they can install more mods. At the moment there is a limit as to how much you can mod the game and this limit is set by the amount of RAM available to the 32bit game engine.

If you'll read around a bit, you'll see that several people have previously stated that ram "improves framerate and the part count of individual ships", and the post I quoted in fact seems to contain that type of reasoning.

Not the "moar mods!" mentality you describe.

The people clamoring about ram all of the time have introduced the idea that if only the game could address more memory, it would run FASTER, clearly that is NOT how things work, BUT, the people with lesser know how in relation to computers seem to have adopted this idea because it sounds good if you don't genuinely know better through no fault of your own.

It shouldn't be defended or encouraged to spread such ideas.

[Eric S]

If you'll read around a bit, you'll see that several people have previously stated that ram "improves framerate and the part count of individual ships", and the post I quoted in fact seems to contain that type of reasoning.

Yes, people have claimed that, but for every person that has, two people have disagreed saying that 64 bit code would provide a minimal at best speed increase, the real win is the game not crashing when mods use too much memory. That is brought up all the time, sometimes by people that don't even realize that the problem is that they're running out of memory.

None of which affects whether Squad should put more effort into hammering out bugs (I'm in the camp that thinks 64 bit Unity for win is the issue, it's not Squad that is holding it up), or even what optimizations are in 0.23.

On the memory front, Scott Manley mentioned that 0.23 compressed textures in memory, instead of keeping them all uncompressed, which should help quite a bit.

[Themohawkninja]

I can't really say for sure just how things are being optimized, but I can give you a small example of what an optimization might look like.

In programming, all of the values for the game (like ISP, thrust, etc.) are held in what are known as variables. When a programmer initializes a variable, your computer allocates a certain number of bits for that variable (the number of bits depends on the data type, whether it is a whole number, a number with decimal places, a letter, or what have you). What an optimization might look like in this case, would be a programmer using a smaller sized data type (perhaps a 16 bit variable instead of a 32 bit variable) for the same variable, since that variable will never exceed the new (and therefore certainly not the old) limit (if you want to know how much a variable can hold, the equation is (2^(number of bits))). This reduces the amount of memory that the game takes up, and therefore (in a game like KSP) would allow the player to build and fly larger ships, cause bigger explosions, or whatever the optimized variable affected without lagging the game.