0.23 should focus on performance

[EvilotionCR2]

Guys,its alpha. Alpha is for adding major features,beta is for bugfixing and performance improvements,sometimes SMALL changes.

[John FX]

learn how things work in a game engine. instancing is where you load a model and texture data into the state machine, draw 50 of them in one pass just by feeding in transform data. its one of those ways you lower the command rate to the graphics apis to increase performance. with procedurals you cant do this. you load your generated model and texture, draw one, and then you need to reset the state machine for the next thing, so the commands/object is higher. maybe you can do something with a geometry shader to speed things up, but those are fairly new and probibly not supported on a wide array of video hardware at this time.

i get it, you want procedurals to be stock, its a cool feature. but its not a way to fix the problem. it might net you some performance gain using certain rocket builds (especially megaboosters). but its a bandaid at best and wont give you the wide sweeping performance increase you want.

So you have to do the low CPU intensity part a lot more (a call to the graphic API, very much not a bottleneck) but you have to do the high CPU intensity part (physics, a definite bottleneck, the major one in the game) a lot less? Sounds like a great idea to me the way you described it!

I get it, you just don`t want procedurals to be stock but your argument does not make sense in this instance and is not a reason to NOT have procedurals, it just may mitigate their benefit slightly. It would still have *plenty* of benefits by shifting work from a bottleneck to a place where there is not a bottleneck. Saying it would not be a benefit to ALL ships is also not a case to not have them. It would be a great benefit to some and no deficit to anyone else...

As you say it is a bandaid until there is either 64bit, a new engine or another radical change which is the ACTUAL change needed but I would rather have a bandaid than nothing...

Also it lets you make ships that are more cool.

Guys,its alpha. Alpha is for adding major features,beta is for bugfixing and performance improvements,sometimes SMALL changes.

Exactly. Myself I saw as much performance increase with the last patch as anyone should expect at this stage. If we want all the focus to be on performance we are saying to the devs "The game is now finished, make it run quick" when what we should be saying is "We would like these features (resources and more career)" and "this part of the game mechanic does not work" instead.

Edited October 30, 2013 by John FX

[Guest]

I`d be happy for a single thread to work across all my cores. If Unity would make that change it would go a long way.

Myself I have seen huge improvements in performance between 0.21.1 and 0.22 but then my machine is very capable and has the legs to allow the improvements full reign. A lot of the game seems restricted by hard drive speed. I have a lower spec machine that has a faster hard drive and KSP runs better on that one as far as loading times and general playability/flow etc goes.

Best KSP i play is on the SSD RAID machine that gets 900MB/sec

I disagree that it's getting better. Have you listened to the game? Music glitches, audio hiccups, and sound anomalies in map scene. Music glitches and audio anomalies were not present in .19 or .20. Have you been to Gilly or landed on Eve or Moho? LAGFEST! It's getting worse with each update. You can try to ignore these things all you want. They still exist.

[jfx]

Playing the alpha card on KSP really doesn't acomplish much anymore. We ar are three years into development and each build gets internal and external closed test phases (which is one of the main reasons for the slow releases).

Also "premature optimization" does not apply if the system you are looking at is dysfunctional in the first place. And when looking at how many ressources are hogged by the loaded parts that clearly is the case. In this scenario it's best to tackle the problem as early as possible - otherwise you'll fnid yourself wasting a lot of time trying to improve the crutch that you are relying upon without accomplishing the wanted results.

[boomerdog2000]

I disagree that it's getting better. Have you listened to the game? Music glitches, audio hiccups, and sound anomalies in map scene. Music glitches and audio anomalies were not present in .19 or .20. Have you been to Gilly or landed on Eve or Moho? LAGFEST! It's getting worse with each update. You can try to ignore these things all you want. They still exist.

I'll agree something is up with the music, but besides that I have been seeing less lag. My Eve and Gilly landings were fine as well.

[AngelLestat]

Angel you are avoiding the main argument how procedural parts is only a band-aid that at best can only improve performance on specific ships

Those specific ships are the ones that need more optimization. A rocket with 20 parts does not need optimization, but one craft with 500 parts it does..

, mainly when trying to stack up fuel tanks or wings. And for both of this 2 problems there are existing mods that help you with that (procedural wings, stretchy tanks, modular fuels, and KW rocketry for bigger parts) not to mention you can have smarter lifter designs. However no procedural parts will help you with reducing parts count for space stations or planetary bases, because on such structures you usually need many docking ports, lights, rcs solar panels, landing struts and other small parts that you cannot simply replace with one procedural part.

Even if some kinds of design does not get much optimization, your loading time would decrease.

There are mods that try to cover this by making multifunctional parts but this takes away the creativity.

And I am against that. Is not the thing that I am suggesting, so lets remove it from the discussion.

And if you are building a station or a base you usually want to visit it with other crafts, like SSTOs for refueling, or similar, and those crafts needs their own set of parts which just adds to the part count when being close enough. So no procedural parts won't solve the main issue, that KSP as it is for now is only good for making a ship, sending it somewhere, and come back (or having fun horribly killing kerbals....). As soon as you try to go into station building or planetary bases, you will hit the wall of bad physics performance.

I dont follow you here. Why it would not help? You can have 5 or 10 different crafts close enoght in orbit, all these craft would have common parts. Tanks for example, you can have rcs tanks, liquid fuel tanks, LFOX tanks and with different sizes. All that with just 1 or 3 procedural part. These one would be cilindrical, half egg shape and spheric (rcs model). The half egg shape can remplace also each nose cone in the game, remember that you can choice fill it with fuel or not.

And I am not against other ways to improve the game performance. If SQUAD in the future can exploit the differents hardware architectures it will be welcome. But I guess Procedural is the only thing that SQUAD can do right now to improve the performance and gameplay.

EDIT: Angel just now i saw your signature, you've build a nice station, now tell me how many parts could procedural parts reduce.... Not to mention that your station is kindof minimalistic, but you still get yellow counter

Well you got me there. I guess that kind of craft can only be reduced by 10 or 15 parts. But that is becouse is full of mod pods.

But a curious fact, I made that in the .18 version, 1 weak after I finish, the .19 version come and almost ALL mod parts that I used stopped working. This happens almost with each KSP update.

I guess that answer you the question of why not just play with mods.

Now focus in the space station that is posted below mine here.

If we count only the panels it has 150 parts. 120 of them are flat and can be remplaced by 12 parts. The rest can be remplaced by 10 more in the case that the procedural part has these size limits.

Lets look at the real world. I have made the same craft in stock and using procedural tanks and fairings only.

Fairing mod is amazing, and it can be reduced even more, from the 10 parts that it use, it can be reduced to 3.

One extra advantage is that extra tank sizes like 3,75 or 5 gives you the chance to launch heavy payloads with less parts and better looking.

If some day Squad makes a system to model drag, this will be essential.

No one asked himself why SQUAD did not fix the drag model yet? For that reason.. they need extra sizes and parts.

But they know that right now each part that they add to the game it harms by a lot the performance.

[pa1983]

Multicore can only happen if Unity do it

Actually Unity and KSP do support multiple cores, but cannot (yet) run a thread across two or more cores, so the physics hammers one core and the other(s) have little to do...

I`d be happy for a single thread to work across all my cores. If Unity would make that change it would go a long way.

Myself I have seen huge improvements in performance between 0.21.1 and 0.22 but then my machine is very capable and has the legs to allow the improvements full reign. A lot of the game seems restricted by hard drive speed. I have a lower spec machine that has a faster hard drive and KSP runs better on that one as far as loading times and general playability/flow etc goes.

Best KSP i play is on the SSD RAID machine that gets 900MB/sec

I think people are mixing up Processes and Threads here.

A Process is a program so when you start KSP it is ONE process, has its own memory space isolated from other programs by the OS.

Now a typical program will be one process and that process will run one thread. Thats how computer programs on PC have worked for decades.

Then we got modern dual and quad core processors. People just talks about cores this days and still refers to the howl thing as one processor. The correct term is Chip-level multiprocessing or CMP and thats what all modern processors are. It basically means more then one processor on a signal silicone die.

There have also been MCM implementations, Multi Chip Module and that means more then one peace of silicone in on package.

Core 2 Quade was actually both CMP and MCM because it used two Core 2 Duo dies in one package.

Modern processors have many processor cores, they are fully working processors by them self (most of the time with some exceptions) on the same peace of Silicone.

A processor or core, same thing can only run on thread at a time. Its not possible for two or more Cores to run the same thread on a normal PC.

To do so would require hardware support to fuse the resources of more then one core and share them troug the same set of registers. Alpha was going to do that with there processors but they where cancelled before that ever happened.

So its not possible to share threads over cores. A thread can be rescheduled for another core but that only means your moving the work flow from one core to another.

To effectively use say a 4 core processor you need at least 4 threads that have equal demanding work flow. If one Thread demands more then the other threads you will end up waiting for the slower thread.

This is the problem with KSP. It can thread widely but not very well balanced. When I run it under linux it spawns like 4-6 threads If I recall. Problem is that on Thread requires 100% CPU utilization of one core while the other 3-4 threads only uses about 5% etch so it wont realy mater if I have 2 cores or 6 cores because 4 threads at 5% etch for a total of 20% can easily be run on a single core and share time on it (OS will manage this) while they are waiting for the other thread that is taxing one core to 100%.

So its apparent that the main thread needs to be divided up in more threads to spread the load better.

Biggest problem here is physx that runs on the main thread. It would not only need its own thread but it needs to run on preferable 4 equally divided threads with more or less equal work flows to effectively use a 4 core processor.

So no KSP will never run one thread over more then one core because thats not how most computers work. There have been processors and systems suggested that can merge cores in to one at demand but thats pretty irrelevant until some one makes a x86 processor like that but its unlikely to happen considering that cores to day have a hard time extracting more parallelism as it is.

Running more threads per core is the way things are going this days because its cheap and efficient assuming software is extensively multi threaded.

Pretty much all modern PC's can run at least 4 threads simultaneously either trough native number of cores or trough SMT ("Simultaneous Multi Threading", Intels Hyper Threading technology is an example of SMT implementation where one core can let two threads share all the resources) or CMT (Clustred MultiThreading, Used in AMD Bulldozer and Piledriver where some resources are shared and others are not) to increase efficiency.

So for a game like KSP to use a modern PC better it needs at least 4 threads that are balanced well enough that all of them can utilize all the cores to 100%. Now 100% is unrealistic except for them most cutting edge software, I have seen reports that Battle Field 4 can use 6 cores more ore less flat out and 4 cores with 2 way SMT for 8 threads total can be used close to 80% utilization.

One also have to remember that even if a game could use 4 cores to 100% that wont mean 4x performance boost. If implemented badly using more cores can be slower even.

But theres no denying that being able to split physics over many cores properly would speed up a game like KSP a lot.

Im no developer so Im not saying its easy or that I know a ton but from a consumer point of view, if unity dont solve this problem with multi threading I dont see how they can be a candidate for games on the next gen consoles that will feature 8 core processors and proper GPGPU functionality. Previous gen consoles introduced multi threading extensively, 3 cores and 6 threads on the 360 even by to days standard was a challange to get the most out of it and the PS3, well being an odd ball using two ISA, PPC for the main processor running two threads and 7 or so SPE cell processors with there own ISA and performance over easy development aprotch realy forced developers to stop being lazy if they wanted to make something run fast on those platforms.

Cell really took it a bit to fare and thats what basically killed it. Traditional Multicore General Purpose Processors and GPGPU replaced that more or less, fast and easier to develop for.

Next gen consoles will be a modern PC under the hood but to day not even a PC can run software at its fastest with out multi threading. Just is not enough parallelism to extract any more with conventional processor design to make the cores that much faster with etch generation.

So if unity wants to be attractive for developers, because the consumers will demand that the software works on a modern PC then Unity must adapted to modern hardware or developers wont use it if the software runs badly.

People tend to hate consoles and say they kill PC gaming, well I see them as the hardware forcing developers to use new technology. Last generation they had to learn to multithread properly now they will take that to the next level, not only on the CPU but the GPU to.

Edited October 30, 2013 by pa1983

[Tsuki]

John FX and AngelLestat it seems our point of disagreement seems to be in where the primary focus of increased performance should be. My main argument is based on the fact that launch vehicles as it is now do not need major performance boost, because you can get stuff into orbit fairly easy. Lifters are usually quite simple in part count (no need for any the small gizmos like rcs, lader, lights etc not counting struts as this is another KSP silliness and there's no a great mod to decrease them) , and even if it lags a bit, you lose the biggest part of the lifter in less than a minute never to be seen again. Also if you are not planing to construct stations/bases with the payloads you are lifting, but just fly anywhere around kerbol system, you can in fact design very compact and streamlined vehicles with small part count. Unless you are trying to design a craft based on how it looks and not usability... but than people will always find designs that bring the game to a crawl no matter how good the performance it is. And you can still go for mods if you are on for the looks. Now... what I think it should be fixed is the ability for us to build stations and bases, as we got docking ports, and were promised planetary resources, so the incentive to build such structures is getting bigger and bigger. And unless you go into a silly amount of streamlining the station/bases (ex: fueling station is a free floating uncontrollable bunch of docked orange tanks with one spare dock ormsth) you will be stuck with yellow or red time counters every time. And the only correct way I see to improve our ability to build stations or bases is to improve performance based on how many parts can run smoothly (preferably scaled with computer performances). And the only "band aid" solution would be part welding or multifunctional parts, which i think we all agree is not something we want. Oh and accidentally, if they increase the part count performance, they also increase our ability to build lifters with more parts, so everything is better.

EDIT: Also repeating myself: major part count performance increase will not be achieved by simple code optimization tweaks, but they need to make some quite fundamental changes, that is why they should be done as soon as possible, because the more features they add on top of the faulty physics engine, the harder will be to replace it.

Edited October 30, 2013 by Tsuki

[sheldor]

i disagree. its not a traditional alpha. its a game in developement that is good already to be sold and which relies on community contribution. if performance is on demand, it should be focussed on.

[Superfluous J]

Playing the alpha card on KSP really doesn't acomplish much anymore. We ar are three years into development and each build gets internal and external closed test phases (which is one of the main reasons for the slow releases).

Also "premature optimization" does not apply if the system you are looking at is dysfunctional in the first place. And when looking at how many ressources are hogged by the loaded parts that clearly is the case. In this scenario it's best to tackle the problem as early as possible - otherwise you'll fnid yourself wasting a lot of time trying to improve the crutch that you are relying upon without accomplishing the wanted results.

Playing the "playing the card" card won't cut it with me. It's not a card. It's a simple fact that has been discovered over dozens of years of professional programmers coding more and more complex systems.

I want this game to be complete as quickly as possible. You want the game to play better in its current state of completion and whether or not you realize it you are willing to sacrifice - perhaps greatly - the time frame of the game being complete. Or even of things being added to it.

The game is not dysfunctional in the first place. It's not optimized. Optimizing it now would be building the exact crutch you are afraid they are relying on. As things change and grow that crutch will not just be inadequate but will get in the way, and they'll either have to rip it out or work around it, wasting even more time than they wasted putting it in in the first place.

Maybe it's bad that they sold the game while it's still in an alpha state, and maybe its bad that the game is SO playable in spite of where they are in the development cycle. If the game was less playable, maybe people wouldn't complain so much that they are having trouble playing it.

[Nuke]

So you have to do the low CPU intensity part a lot more (a call to the graphic API, very much not a bottleneck) but you have to do the high CPU intensity part (physics, a definite bottleneck, the major one in the game) a lot less? Sounds like a great idea to me the way you described it!

i honestly do not care if its stock or not. im not one of those wankers who think that using mechjeb or any other mod is a mortal sin, i am also not one of those other wankers who want all the mods to be stock so they can use mods without being called wankers. play stock, plant flags everywhere, complete the research tree, when you get bored, use mods to extend the life of the game. thats what mods have always been. the product of people who like a game so much they dont want it to end. its not rocket science.

i just dont see how implementing a feature like procedural graphics will fix the problems currently in the game. at most it will ease the speed issues on a very few spacecraft designs. you might gain some rendering performance with instancing that you cannot get with procedural parts (which cannot be instanced if generated with a different set of parameters). geometry shaders were meant to deal with this kind of problem, but im not sure if they are used in current implementations. you could use a primitive as a seed and generate an entire part mesh entirely in the shader so you dont even need to store a procedural graphic model in memory (you still need a collision mesh for physics though).

i will however admit that rendering performance is at most a stawman argument, because its a small slice of the pie. im actually supprised i wasnt called out on this earlier. since the problem is in physics, and since procedural stuffs do nothing to help or harm physics, other than slightly reducing complexity on some ship designs. physics merging would probibly do this better than procedural stuffs, as it would have sweeping effects in reducing physics object counts, and i have a feeling from some technical posts by members of squad in the modding section seem to indicate that squad is already working on this.

if memory is the problem, then the obvious solution is to use less. the best way to use less, is to support dxt1/dxt5 compressed texture formats, which give you 1:6/1:4 compression ratio. there are other benefits here as well. these textures require no decompression by the engine on load (unlike png), they can just be forwarded to the video hardware and decompressed on the fly in shaders. if artifacts are your concern, then take solace in the fact that you can use textures the next power of 2 and still use less ram than current. also since the textures are smaller in filesize, you spend less time loading them so faster loading times. you can use the low res texture packs, but thats ignoring the fact that the current texture formats are insane. no game uses uncompressed textures for everything. we have no idea when unity will have better x64 support on windows/mac, and this could buy some headroom while we wait for that to give us more memory. all while being a feature that should ship with the final game.

object merging/dxt* compression are not bandaids, would give you performance gain across the board. making everything procedural is. every part of the game that gets sped up, is another part that doesnt drag it through the mud. procedural parts is what it is, a feature request, and doesnt belong in this thread.

[Guest]

I'll agree something is up with the music, but besides that I have been seeing less lag. My Eve and Gilly landings were fine as well.

I'll be the first to admit that many of the problems I have playing KSP are because of my crappy old laptop. I'm fine with that and I can work around it. The issue with Gilly is happening when I first enter its SOI and I still have an escape trajectory and only in the flight scene. Once I get circularized, it goes away. Eve has gotten worse. I have to have the camera pointed at the sky, else a landing would take hours. It's always been laggy, but it got worse with this update. I just did my first Eve landing yesterday and wanted to start pulling my hair out. Moho is something I heard about in another thread, and it sounded like a similar deal to Gilly. I've yet to test that out. These things I can handle, but the audio issues are like nails on a chalkboard, and are not caused by my crappy laptop, as earlier versions were just fine.

All that aside, my take on the optimization thing is this : would you add shiny new wheels to a vehicle that is blowing smoke out the tailpipe and sounds like someone dropped a bunch of gravel down one of the spark plug holes? I feel like we could use some repair work before adding new features. I want career mode too, but not if it means corrupting a game that was working pretty good. KISS. Keep it simple stupid.

[boomerdog2000]

I'll be the first to admit that many of the problems I have playing KSP are because of my crappy old laptop. I'm fine with that and I can work around it. The issue with Gilly is happening when I first enter its SOI and I still have an escape trajectory and only in the flight scene. Once I get circularized, it goes away. Eve has gotten worse. I have to have the camera pointed at the sky, else a landing would take hours. It's always been laggy, but it got worse with this update. I just did my first Eve landing yesterday and wanted to start pulling my hair out. Moho is something I heard about in another thread, and it sounded like a similar deal to Gilly. I've yet to test that out. These things I can handle, but the audio issues are like nails on a chalkboard, and are not caused by my crappy laptop, as earlier versions were just fine.

All that aside, my take on the optimization thing is this : would you add shiny new wheels to a vehicle that is blowing smoke out the tailpipe and sounds like someone dropped a bunch of gravel down one of the spark plug holes? I feel like we could use some repair work before adding new features. I want career mode too, but not if it means corrupting a game that was working pretty good. KISS. Keep it simple stupid.

For fixing the lag on Eve, have you tried the fix for the terrible ocean lag?

[Guest]

For fixing the lag on Eve, have you tried the fix for the terrible ocean lag?

Yeah, I don't want to get off topic here, but I've had to try every trick in the book just to keep the game running. I am on the lower end of recommended specs. Maybe it's time to up the low specs needed for the game if we are going to keep giving my computer more stuff to keep up with, I don't know. I like the idea of fixing some of the small issues before moving on. (some of which are not small IMO). Just my 2 cents for what it's worth.

I would really like to go back to an earlier version, but there have been some exciting improvements to kethane and KAS. Majiir is doing some great work. Not just great, but awesome. I want my cake, and I want to eat it too.

[AngelLestat]

John FX and AngelLestat it seems our point of disagreement seems to be in where the primary focus of increased performance should be. My main argument is based on the fact that launch vehicles as it is now do not need major performance boost, because you can get stuff into orbit fairly easy.

Ok, lets said that "we can" launch most of the rockets without a big problem in performance.

But that is becouse ksp has no graphic quality or extra terrain models!

Try to install universe remplacer with a 8x texture for kerbin, then launch the same rocket and tell me what happen...

What about someone who has an old computer?

If we can get a performance boost, lower the loading time and increase the part count all at the same time, the question is.. "Why not do it???"

Really, I dont understand why someone can be against this.

Is like be against multi core support...

Also if you are not planing to construct stations/bases with the payloads you are lifting, but just fly anywhere around kerbol system, you can in fact design very compact and streamlined vehicles with small part count. Unless you are trying to design a craft based on how it looks and not usability... but than people will always find designs that bring the game to a crawl no matter how good the performance it is.

But that is our choice! Is the liberty that the game gives us. Some people likes to make big things.

EDIT: Also repeating myself: major part count performance increase will not be achieved by simple code optimization tweaks, but they need to make some quite fundamental changes, that is why they should be done as soon as possible, because the more features they add on top of the faulty physics engine, the harder will be to replace it.

This post yours just dodge all the things that me JohnFX already answer you in our previus post and you ignore.

What about the space station example that I show you just below mine, that you can reduce the part count in a 1000%.

i just dont see how implementing a feature like procedural graphics will fix the problems currently in the game. at most it will ease the speed issues on a very few spacecraft designs.

You are forgeting that you reduce your game loading time, you had more free memory at disposal and even if you can not cut many parts with some design, some parts you will cut anyway. This traslate into better CPU and GPU performance.

And your crafts looks nicely at the same time.

you might gain some rendering performance with instancing that you cannot get with procedural parts (which cannot be instanced if generated with a different set of parameters). geometry shaders were meant to deal with this kind of problem, but im not sure if they are used in current implementations.

How is that? I give you an example so you can explain step by step why it would be different and you didn´t.

I will copy paste again:

if you had a craft with 4 small tanks (pair stack), 1 middle tank and 2 big tanks stack. (3 cfg files, 3 models and 3 textures) 7 parts

Now lets said that you can make the same craft using procedural (1 part menu) with only: 2 small tanks, 1 middle and 1 big. (1 cfg file, 1 model, 1 texture) 4 parts.

Why instance would help in one case and no in the other?

and since procedural stuffs do nothing to help or harm physics, other than slightly reducing complexity on some ship designs.

Reduce to half the part count in a common big rocket is something minor to you?

physics merging would probibly do this better than procedural stuffs, as it would have sweeping effects in reducing physics object counts, and i have a feeling from some technical posts by members of squad in the modding section seem to indicate that squad is already working on this.

Can you post the source?

Physics merging? what does it mean? That if you have a fuel tank over an rocket engine would have the same physics than other tank in any other place of the craft?

is another part that doesnt drag it through the mud. procedural parts is what it is, a feature request, and doesnt belong in this thread.

Until now is the idea that can be done and the one that brings more benefic to performance you like it or not.

If you are against try to prove it with LOGIC. No ignoring all the comments that you can not answer.

We can talk all day about other methods to improve performance.. the final question is: Squad can do it? we can do it? If the answer is not.. Why spend more time in that?

Edited October 31, 2013 by AngelLestat

[Bacterius]

All that aside, my take on the optimization thing is this : would you add shiny new wheels to a vehicle that is blowing smoke out the tailpipe and sounds like someone dropped a bunch of gravel down one of the spark plug holes? I feel like we could use some repair work before adding new features. I want career mode too, but not if it means corrupting a game that was working pretty good. KISS. Keep it simple stupid.

I agree with this. It's great to follow sensible software engineering practices, and new features are great, but ultimately there comes a point where the game runs so slowly or has so many annoying bugs that it becomes unenjoyable (sp?) playing it. People in this thread are not asking for an epic overnight rewrite leading to the most optimized game ever written by mankind, but there are definitely some issues that need to be resolved and which cannot be ignored at this point.

I don't really know why I typed this up, though, I am probably just going to get flamed once more like I did last time in some other thread, but just my two cents.

[John FX]

So to go back on topic : 0.23 should focus on performance - Discuss

My response is, no it should not. performance is good enough for a game which is being heavily developed. It plays fine on my laptop and hardly any games run on that anymore.

To address the performance complaints. If there are specific areas that need performance work then they should maybe be specifically named but `the whole game needs attention and runs really bad` sounds more like it is your machine than the game.

To those saying certain suggestions are band aids, a band aid is the maximum treatment that should be applied at this stage. You don`t do one sweep of a brush then one wipe of a mop, you sweep the whole floor then mop the whole floor. What this thread seems to be doing is pointing out the floor has not been mopped while the guy is still sweeping it (to make a bad analogy)

[Zutha]

I completely disagree. An alpha is about adding content, a beta is about optimization.

[Guest]

I completely disagree. An alpha is about adding content, a beta is about optimization.

The "alpha" excuse just doesn't work for me anymore. This from wikipedia:

The origin of the "alpha/beta" test terminology is IBM. As long ago as the 1950s (and probably earlier), IBM used similar terminology for their hardware development. "A" test was the verification of a new product before public announcement.

I think describing KSP as an alpha at this point is a stretch. This is a new category. I understand that the game is changing. It is being developed by a small group of people who can only do so much. Resources are limited. But it is time, IMO, to drop the alpha excuses. Acknowledge your limits. Take some time to fix some problems. That's all.

[Superfluous J]

New category or not, optimizing code that could change drastically is at best a complete and utter waste of time, and at worst will bog down your efforts in the future.

"Alpha" is not an excuse. It's a state of being and an insurmountable fact. You sound like someone falling through the sky saying that the "gravity" excuse just isn't cutting it anymore.

[boomerdog2000]

With reasonable sized craft, the game runs fine. The devs cannot start catering to the massively over-complicated ships that some people can build (sorry Whackjob) until the game is done. Once the features are in place and they know where and how they can optimize, then they should optimize. The only exception to this would be if a completely game-breaking bug where revealed during one of the releases, but given their current job of testing the releases and ensuring everyone has a playable version I doubt this will happen.

[vexx32]

I don't really see why there's always this argument. Yes, you can bring a computer to its knees if you build ridiculously large ships. Yes, some people actually like to build these immense and often incredible creations. Some people prefer to keep it simple. That's fine too. The devs are doing their best to cater to everyone, which is no mean feat. In addition, they are working on performance; it crops up every few weeks in the KSP Weekly (or the KSP Daily, as it will be from here on in, as it seems).

Optimisation is a double edged sword -- if they attempt to focus on optimisation alone, they may find that they have to go back and undo those optimisations to be able to add in new features. In the end, they've only wasted time. They're likely already working on optimisations as much as they ought to be, really, all things considered. You can discuss it till the end of days, but for now I think it's probably better to leave off worrying about it until we see what the next release brings.

[DMagic]

They talked about performance improvements before 0.22 was released, and based on yesterday's Daily, it looks like they are trying to get them into 0.23. How much, and it what ways it improves performance are yet to be seen, but it seems they are doing something.

http://kerbaldevteam.tumblr.com/post/65574326046/the-daily-kerbal-first-edition

[LtHeckard]

I don't know why, but when I am in LKO, or Kerbin atmosphere entry, , my frames drop supremely. I can maintain about 40 FPS in space, but when my space craft gets too close or enters the atmosphere, my frames drop to about 15 FPS. I would like that to be fixed.

[DMagic]

I don't know why, but when I am in LKO, or Kerbin atmosphere entry, , my frames drop supremely. I can maintain about 40 FPS in space, but when my space craft gets too close or enters the atmosphere, my frames drop to about 15 FPS. I would like that to be fixed.

This is the terrain performance issue that gets brought up a lot. In most cases it's the ocean terrain settings that cause this problem. The slow-down can be reduced by lowering the ocean terrain details in your settings.cfg. Though I agree that something should be done about this. I suggested a while ago that they could add a dedicated terrain detail option in the settings menu, which would at least help for people who don't want to mess around in the settings.cfg file.

http://forum.kerbalspaceprogram.com/threads/43253-Default-Terrain-Quality-Without-most-of-The-Lag%21