dedicated optimization patch

[chuckbillrow]

because Unity does not allow multi-threading the resources available to KSP are rather limited so what we need right now is to get all the things that are already in the game running as efficiently as possible before we add more stuff

[NoMrBond]

Allocating dev resources on optimizing means delaying features by diverting dev time to something which will likely break when adding features or changing systems

Worst case might even involve locking in things to prevent breaking optimizations, which given the games alpha state might be counterproductive

[jwenting]

correct. Performance tuning is the last thing you want to do before release. Doing it earlier usually only leads to more work.

Of course there are exceptions, like when something causes such a severe performance drop it breaks the product, but that's not the case here.

[Nachtwind]

because Unity does not allow multi-threading the resources available to KSP are rather limited so what we need right now is to get all the things that are already in the game running as efficiently as possible before we add more stuff

Like others said.. that would be useless. It would mean to spend too much time on stuff that surely will be broken again sometime sooner or later.

*edit*

Also.. considering the community uproar when the first information to .21 leaked i would think that a performance-only patch would lead to a civil war in this forum...

[leax256]

*edit*

Also.. considering the community uproar when the first information to .21 leaked i would think that a performance-only patch would lead to a civil war in this forum...

so do I need to ready the SRBs?

[Beeman]

Apparently waiting 'till your major features are all implemented before you heavily optimize is a bad and outdated idea. That was pointed out to me in another thread a week or two ago by someone who's undoubtedly more knowledgeable about this type of thing than I am. Of course, his source was a Microsoft employee's comment on it from something completely unrelated or somethin' like that....and may very well not apply to a smaller studio with a much, MUCH smaller budget than that of a company like Microsoft.

Also, SQUAD can't really do anything about multithreading physics calculations. That's entirely up to the Unity developers...and given the popularity of KSP, I would expect them to be working on their solution to this problem right now. I mean, independent developers are falling in love with Unity left and right and increasing the performance for how Unity handles physics would not only benefit us and SQUAD, but anyone who wants to make a physics-heavy game in Unity. But maybe it's difficult for them to figure that out just right. Maybe they have to reorganize a lot of their previously established Unity code to make it work the way we need it to. I wouldn't know so I'm just trying to be patient about it.

All in all, I'd say just wait it out. There's a LOT of games coming out this fall, so maybe some of the more casual players should spend less time in KSP for a few months, though still load it up from time to time for testing purposes and to just play it 'cause it's still fun in all its laggy glory. I mean, I hadn't really played KSP practically at all between .14/.15 and .21 and I really enjoyed all of the progress that they made thusfar. Though I'm still waiting for career mode before I start getting too extravagant with my missions.

I don't know, taking a break to play other games for a while would certainly help a lot of people who're getting more and more frustrated with lack of major optimizations that may or may not be impossible for SQUAD to do right now so that's my...perhaps overly simplistic opinion on the matter.

Edited August 26, 2013 by Beeman

[leax256]

I would think that a optomisation of some sort would be made around the end of the alpha stage as part of the begging of the beta stage.

[Anton P. Nym]

I'll throw in that optimising now, before Unity gets multi-threading or x64 support, could lock in the current lack of same until the retail release... I'm willing to wait on optimisation until there's more progress on the overall game, myself.

-- Steve

[jwenting]

Apparently waiting 'till your major features are all implemented before you heavily optimize is a bad and outdated idea. That was pointed out to me in another thread a week or two ago by someone who's undoubtedly more knowledgeable about this type of thing than I am. Of course, his source was a Microsoft employee's comment on it from something completely unrelated or somethin' like that....and may very well not apply to a smaller studio with a much, MUCH smaller budget than that of a company like Microsoft.

as you've obviously no clue, best you stop saying things like that.

Nobody says you don't take performance into account when writing software, but you do NOT do premature optimisation for the heck of it.

And no, doing optimisation at the end of your development cycle is NOT an outdated concept.

So you don't write things knowing it'll be slow if you can write it to be more performant now, but you also don't spend a lot of time now to make things faster based solely on the idea that it might not be fast enough at some indeterminate point in the future.

And you NEVER microoptimise unless you have evidence that doing so is going to give a macroscopic positive effect on performance.

[Guest]

Never say never. There are issues that can and should be fixed.

[Beeman]

as you've obviously no clue, best you stop saying things like that.

You seem angry about my response. Try not to be, I"m just a simple fool who tries to maintain a generally unbiased outlook on most things and if people much smarter than myself are going to correct me when I'm being ignorant, I'm more than happy to be learning something with everyone else.

Of course, I feel the need to ask...you did see where I said that was something that was pointed out to me, right? I did fully admit more than once to not being very knowledgeable about this sort of thing. I mean, my previous understanding of the topic was...as you say; that it was best to wait 'till your major features were implemented before you start optimizing the poots out of your game. Then, as I said, that apparently Microsoft standpoint on microoptimization was pointed out to me. Pointed out to me is the important part of that. It's not what I'm saying, it's what was pointed out to me.

That said, I recall...several patches ago Harvester mentioning that he was rewriting a lot of the game's code to make newer features work better and to make it easier to add newer features in the future. This was...around .15/.16, I believe. So they know what they're doing with their code, more or less. That's why I went on to say that it's best to just be patient.

I mean, most of my response was saying how it's best to be patient about this type of thing focusing on one factoid that I regurgitated that..as I said may well not apply to SQUAD, is kind of silly. Just calm down, relax and let the discussion flow naturally. Idiots like myself will be glazed over by the intelligent peoples' responses, you don't have to point out when we're being too ignorant in such a way as you ignore half of what I said.

[Psycix]

This suggestion would multiply your FPS during launch

http://forum.kerbalspaceprogram.com/showthread.php/43740-The-war-against-lag-Anti-lag-fairings

[Guest]

This suggestion would multiply your FPS during launch

http://forum.kerbalspaceprogram.com/showthread.php/43740-The-war-against-lag-Anti-lag-fairings

A mod that helps performance. That is an excellent idea and gets right to the root of the problem.

I think improving the way the game performs in terms of loading times, memory management, FPS, etc., would help the modding community. The modding community surrounding this game is one of the reasons for its success.

Edited August 26, 2013 by Otis

[NGTOne]

I've heard that standalone PhysX cards can improve physics lag - the guy said he didn't start seeing part count-related lag until he hit about 1500 parts. I haven't had any independent verification of this, though - does anyone else have a standalone PhysX card to test this with?

[SpaceHole]

This suggestion would multiply your FPS during launch

http://forum.kerbalspaceprogram.com/showthread.php/43740-The-war-against-lag-Anti-lag-fairings

Maybe you should read more about it. It gives you better performance because it completly disables physics for stuff inside it. Which is not a good resolution its just a cheap FPS gain and probably breaks the game since you can send anything into space within this sphere.

[leax256]

I've heard that standalone PhysX cards can improve physics lag - the guy said he didn't start seeing part count-related lag until he hit about 1500 parts. I haven't had any independent verification of this, though - does anyone else have a standalone PhysX card to test this with?

to my knowledge the PhysX within the game are cpu based and won't be affected by any kind of physX card so he could just be lieing or have a crazy 5.8 ghz cpu, however I'm not an expert, just knowledgable.

[Psycix]

Maybe you should read more about it. It gives you better performance because it completly disables physics for stuff inside it. Which is not a good resolution its just a cheap FPS gain and probably breaks the game since you can send anything into space within this sphere.

I made that thread. I wrote everything about it.

Please note that the fairing itself is breakable and has extra weight to make up for the struts you would otherwise have.

The FPS gain should be massive though.

to my knowledge the PhysX within the game are cpu based and won't be affected by any kind of physX card so he could just be lieing or have a crazy 5.8 ghz cpu, however I'm not an expert, just knowledgable.

Unity is indeed runnig on CPU physics. GPU acceleration would already solve most of the problems. Modern graphics cards ARE physX cards.

[SpaceHole]

I made that thread. I wrote everything about it.

Please note that the fairing itself is breakable and has extra weight to make up for the struts you would otherwise have.

The FPS gain should be massive though.

Still you can send up things that would have never survived a launch or crashed your rocket so its pretty much like cheating.

So by using it the only difficulcy is the weight. Which reduces difficulcy greatly.

[Psycix]

Still you can send up things that would have never survived a launch or crashed your rocket so its pretty much like cheating.

So by using it the only difficulcy is the weight. Which reduces difficulcy greatly.

Like what? With enough struts, we already CAN send up anything, weren't it for the absurd amounts of lag.

[SpaceHole]

Like what? With enough struts, we already CAN send up anything, weren't it for the absurd amounts of lag.

Struts increase weight and drag and depending on what you want to build they maybe even hinder you from doing so.

Still i dont get how this is a solution - switching of parts of the main-game-mechanics for some parts is not a solution its a bad workaround.

[Guest]

Maybe you should read more about it. It gives you better performance because it completly disables physics for stuff inside it. Which is not a good resolution its just a cheap FPS gain and probably breaks the game since you can send anything into space within this sphere.

I read some more about it. It's not the specific application referred to in that thread that I am promoting. It's the idea that improving performance will help the modding community in terms of implementing new ideas, testing, etc. I don't want to see us get stuck in a rut.

[Beeman]

I'd be okay with fairings that disabled physics on objects inside of them.

But I'd rather just have fairings that act as fairings...though we won't see a need for them 'till aerodynamics get reworked, if they ever get around to that(it's not a particularly urgent matter, that's for sure).

I think it'd be interesting to hear what the Unity developers would have to say about the performance issues we get due to physics and what-not.

[Kerbart]

I'm confused. What are we talking about here? Optimization of code “to make it run faster?†(using scaled integers instead of doubles, those kind of things)

Or refactoring code and improving algorithms? (to reduce memory footprint, lower # of cycles needed per frame, etc).

The latter should be done continuously and there's no reason to wait with it; and I get the impression that is something Squad is already doing. Streamlining code, on the other hand, is something you usually only want to implement when you're not going to regret your decisions laterâ€â€when you're feature complete, that is.

[SpaceHole]

I read some more about it. It's not the specific application referred to in that thread that I am promoting. It's the idea that improving performance will help the modding community in terms of implementing new ideas, testing, etc. I don't want to see us get stuck in a rut.

Yeah i agree with that but from my point of view things that will give the biggest boost:

1) 64 bit

2) Multi-Core-Processing

3) a system that wont load every single part into memory that isnt even used

1 and 2 seem to be rather hard and require the Unity-Developers? I am not sure if 3 is even possible with the engine used?

4) optimized textures etc.

5) modders also trying to keep their mods optimized

[Nachtwind]

Yeah i agree with that but from my point of view things that will give the biggest boost:

1) 64 bit

2) Multi-Core-Processing

3) a system that wont load every single part into memory that isnt even used

1 and 2 seem to be rather hard and require the Unity-Developers? I am not sure if 3 is even possible with the engine used?

4) optimized textures etc.

5) modders also trying to keep their mods optimized

1 & 2: THat has been discussed like 400 times, since the breakfest that is... that is solely depending on unity. There seems to be a multi-core library for unity available.. but i cant judge if its worth to rewrite everything to make use of it. I would rather wait for unity to implement it nativly..

3: So.. basically not a bad idea.. but would you rather take a lag of a second per part in the vab that you add to your craft? at least for the first N parts? Just imagine the effect: the game loads pretty fast and once in the vab you have the game choke/stop on every part that you didnt use before.. i would expect the outcry would be much much louder than we hear right now. There might be a way for in between... giving "trends" on which parts are used most and which are "in flight"... but that would still be slow compared to the current VAB system..

4: I would say this is "polishing" and can be done pretty late in the development.. but history is different. Take a look at the changelogs and you will see how much the textures already have changed.. might be worth thinking about it.. but i dont think it would add a lot to the overall performance.

5: Well.. its up to them i guess