Jump to content

Ksp need to fix the performance


Luc1fer

Recommended Posts

I think the OP's question has been answered, going off topic :P

15 minutes ago, Fearless Son said:

Air resistance is almost never modeled ... Usually they just substitute the damage dropping off as a function of range, with the longer the projectile travels the less damage it does.  Often this is actually dialed down to drop off far faster than it would in real-life as a function of enforcing close-range shootouts as a gameplay feature (getting sniped in one shot from across the map by an enemy you were not close enough to see is rarely "fun".)  Different guns will spawn different bullets, as defined in the game's files.  Sometimes even the same gun will shoot "different" bullets, even if they are the same caliber, just by switching the weapon's parts (the game uses a different dataset reference for bullets in that case.)

I'm curious, what FPS do you like? I find the difference between Arma and other shooters to be largely a result of it not artificially restricting the range of weapons. IMO, it is fun if you can die from 1 shot across "the map". Arma doesn't have "maps" like other FPS, it has large islands in the 60 to 200 square kilometer range. Going from one end of the map (only counting the land, not the water) can mean travelling over 15km. You can get kills at 2km with the heavy duty sniper weapons, kills at 800m with marksmen weapons are also reasonable. Most FPS games aren't even 800 "meters" across. That's not even considering the bad day you can have if an enemy tank is ~3km away in an elevated position (especially if its able to get in a "hull-down" position), and starts firing 120mm HE shells at your squad's location... or an A-10 opens up with its gatling cannon at 3km away, or an attack helicopter... and kills can be scored even farther away just with a spotter for artillery or a team mate flying a jet armed with LGBs or cluster bombs. IIRC, the laser guided missiles had a lock range of 6km for laser targets...

The tension from knowing how easy you can die creates a lot of fun. I have fond memories from the original Operation flashpoint of a simple 2v2 sniper mission with no respawn. It lasted over an hour, but the whole hour I knew that at any moment I could be killed before I even heard the shot if the enemy saw me first and had good aim.

Arma3 changed the feel a bit with the addition of body armor. Players can seem a bit like "bullet sponges" for 30 caliber weapons and lower, older games had even 5.56 killing in 1-2 body shots except at extreme ranges... though the body armor doesn't help when an HMG opens up on your position, or when a sniper with a .50 or .408 gets you... I think the heaviest body armor can protect from a single .338 to the chest (a 2nd round will kill though).

Link to comment
Share on other sites

1 hour ago, Mako said:

Hold up. Let me get this straight. If we ignore the details about the physics for a second, are people actually saying they expect an indie game made by a small, relatively inexperienced team with a small budget working on a somewhat closed-source third-party engine should perform as good as a game made by a large studio of experienced industry professionals with a Triple A budget working on their own completely customizable engine?

Performance has nothing to do with team size, and very little to do with budget. At least not in the way you think. It's easier to make high-performance code in a small team. For making something really high-performance the ideal team size shouldn't be bigger than four. It has everything to do with how good the code is, and something to do with how good the engine they're using is. 

Link to comment
Share on other sites

Going back on topic.  I'm pretty sure that multithreaded physics simulations have existed for quite a few years.  eg from wikipedia 

Quote

PhysX SDK 3.0 was released in May 2011 and represented a significant rewrite of the SDK, bringing improvements such as more efficient multithreading and a unified code base for all supported platforms.

However I don't know whether any existing multithreaded physics libraries meet ksp's needs and whether any of them could be integrated into unity.

Regarding the slowdowns with large part counts, ksp could probably implement something similar to a welding mod, where when two similar objects of similar diameter are attached,  (eg 2 fuel tanks), they could be welded into one part, at least for most physics calculations.  Ideally the editor could even detect that fuel tanks are not only node attached to their parent, but also surface attached to another part in the tree, and 'weld those multiple tanks into one tank.  As long as all tanks that are welded this way are all part of the same stage, the only time you need to consider them as separate items is when one of them collides into the ground/another vessel, and when calculating heating during re-entry .  That would improve stiffness of large craft, and could also significantly reduce the number of parts you need to calculate physics for.  

I'm also not sure how much physics calculations ksp does for "physicsless parts" eg things like rcs, lights, most science instruments, most parts that only surface attach.  Conceptually they don't need to be considered for most physics calculations.  You only need to do some simple stuff, eg check for pressure damage, and transfer heat to/from their parents during re-entry.  But that is all linear in number of parts, and not O(n^2). 

Link to comment
Share on other sites

I'm pretty sure it would be possible to do sophisticated multithreaded highly parallelised physics calculations in the GPU extremely fast.

I'm also pretty sure that it would not be easy.

And I'm absolutely sure there are coders who live for solving just that kind of intricate, complicated problem.

Link to comment
Share on other sites

I can see the points of both sides of the argument; KSP's performance compared to "prettier" games is somewhat lacking, but given what KSP is actually doing it's quite impressive. But the question I have is; does KSP need to be doing all that it's doing? I think KSP sometimes forgets that it's a game first and simulation second (something IIRC @HarvesteR once said it should be). A simulation should be as accurate as possible, but a game should try and fake it and take shortcuts wherever possible.

I don't know how certain things are actually implemented but I get the feeling that some of the approaches are what I'd called the "naive approach". That's not to say that the devs are being stupid, most first implementations are a naive solution, and often that is what seems the most logical or most representative of the real world aspect it's trying to mimic, but with coding the optimal solution is often quite different and even counter intuitive to the system that you're trying to model. 

Take part heating as an example. (I've gotta caveat this with I don't actually know how it's done, this is just speculation, I may be wrong). It seems like parts are engaged in transferring heat between their neighbouring parts and this makes perfect sense as this is what would happen in RL, hot thing next to cooler thing will transfer heat to cooler thing. but this means that at every tic each part has to first calculate which it's neighbouring parts are and then calculate what the exchange should be. Just working out for each part what it's neighbouring parts are is a lot of stepping up and down the part-association tree and unless there is a state/part change to the craft (ie from staging, docking, crashing etc) the result of that calculation won't change between frames. So does each part maintain a temporary cache index of which is neighbours are (and clears that cache on any event which changes the craft's state)? I'd hope so as that would be a small optimisation to that process. 
But perhaps having each part transferring heat to its neighbouring parts isn't the right way to go about it (even though it's the best representation of RL)? I think the way I'd try to approach this would be to have a "heat layer", a sort of bounding box that represents a 3D gradient (or set of vectors) and have each part interact with this heat layer rather than with its neighbouring parts. Each part can then either impart of extract heat from it's position in the heat layer depending on whether that position in the layer is hotter or colder than the part and as parts impart/extract heat that adjusts the position of the vectors. So the heat layer is a representation of sources and sinks of heat and at each tic of the game each part only has to perform a single interaction with the heat layer, rather than as many interactions as it has neighbours (and there is no need to do any walking up/down the part-tree to find adjacent parts). The heat layer could be very simple and only represent a single source/sink (which would be a poor representation, but quick to calculate), or it could have multiple sources/sinks which essentially increases it resolution/accuracy (at the cost of more calcs, but I think that would still be much less CPU intensive than doing part-to-part transfers).
Part-to-part transfer of heat is also not something that lends itself to being multi-threaded as each thread would have to interact with parts that may be being interacted with by other threads and having a shared resource that could be updated by multiple threads is bad (aka non-threadsafe).  tbh I'm not sure the heat-layer approach could be multi-threaded either as the heat layer becomes the common resource that each thread would have to interact with and update. 

 

Another aspect (which kinda annoys me) is landed craft/bases still have all their physics calculated at every step. Sure in RL a parked car still has a bunch of physics acting on it, but in the game context there's no need for that. When a craft/base is on the ground and stopped it should become "locked" and it should stop calculating physics for each part. The only thing it should be doing is checking to see if any internal or external forces are being exerted on it as a whole and if that force goes above a certain threshold then it should switch back to calculating physics on each part. Not only would this increase the performance and enable much larger bases to be built, it would also get rid of that annoying issue of craft sliding around on the surface. 


That's the kind of "faking it" that I think KSP should be doing more of and those are just two examples. I think there are several other places which could benefit from a change in mindset towards faking it rather than simulating it.

Link to comment
Share on other sites

26 minutes ago, katateochi said:

Another aspect (which kinda annoys me) is landed craft/bases still have all their physics calculated at every step.

Funny, I was just thinking of this yesterday. 

I love my Laythe Kosmodrome. Not so much the 10 fps that comes with it, even if everything is just sitting flat on the ground. 

I'm quite sure a clever programmer would find ways of optimising things by excluding parts/craft from the physics computations if no forces are acting on them. The checklist of things to look at per craft would be pretty reasonable:

  • Are any engines burning?
  • Are any motors (reaction or rover wheels) turning?
  • Is it moving through an atmosphere or along a surface?
  • If not, does it have unlocked wheels?

If none of these conditions are true, you could treat the entire craft as a unit, just keeping it on whatever trajectory it is, or none. Additionally, you could make it so that if a craft in motion gets very close to a "simplified mode" craft, it switches both out of this "simplified mode" since a collision is imminent.

Link to comment
Share on other sites

4 hours ago, AVaughan said:

Going back on topic.  I'm pretty sure that multithreaded physics simulations have existed for quite a few years.  eg from wikipedia 

However I don't know whether any existing multithreaded physics libraries meet ksp's needs and whether any of them could be integrated into unity.

Regarding the slowdowns with large part counts, ksp could probably implement something similar to a welding mod, where when two similar objects of similar diameter are attached,  (eg 2 fuel tanks), they could be welded into one part, at least for most physics calculations.  Ideally the editor could even detect that fuel tanks are not only node attached to their parent, but also surface attached to another part in the tree, and 'weld those multiple tanks into one tank.  As long as all tanks that are welded this way are all part of the same stage, the only time you need to consider them as separate items is when one of them collides into the ground/another vessel, and when calculating heating during re-entry .  That would improve stiffness of large craft, and could also significantly reduce the number of parts you need to calculate physics for.  

I'm also not sure how much physics calculations ksp does for "physicsless parts" eg things like rcs, lights, most science instruments, most parts that only surface attach.  Conceptually they don't need to be considered for most physics calculations.  You only need to do some simple stuff, eg check for pressure damage, and transfer heat to/from their parents during re-entry.  But that is all linear in number of parts, and not O(n^2). 

Multithreaded physics libraries mostly deal with non-interacting objects. You can calculate the flight of a thousand bullets in parallel, but ensuring consistent rigid-body linkages on a single assembly of 1000 parts is a different story entirely.

Dynamic welding of might sort-of work, but then you have to come up with criteria for the welding and de-welding, and then come up with a way to tell Unity's rigid-body physics engine that they are welded, and then figure out when they need to be de-welded. Much simpler just to pass everything along to Unity's rigid-body physics engine.

Remember: stuff breaking for reasons such as high aerodynamic loads is very much an intended feature of KSP. If you're going 600 m/sec, and then decide to point your rocket 90 degrees east, your rocket should break apart.

Also, physicsless parts aren't. Their physics now just get added to the parent part.

4 hours ago, Brikoleur said:

I'm pretty sure it would be possible to do sophisticated multithreaded highly parallelised physics calculations in the GPU extremely fast.

I'm also pretty sure that it would not be easy.

And I'm absolutely sure there are coders who live for solving just that kind of intricate, complicated problem.

I think there are some experimental efforts to do highly parallelized rigid-body physics, but they sure haven't trickled down to the Unity engine.

2 hours ago, katateochi said:

I can see the points of both sides of the argument; KSP's performance compared to "prettier" games is somewhat lacking, but given what KSP is actually doing it's quite impressive. But the question I have is; does KSP need to be doing all that it's doing? I think KSP sometimes forgets that it's a game first and simulation second (something IIRC @HarvesteR once said it should be). A simulation should be as accurate as possible, but a game should try and fake it and take shortcuts wherever possible.

The limiting step is and was calculating rigid-body physics. Optimizations to things like heat transfer are fine, dandy, and worthless for the purpose of speeding the game up.

Things like stable, landed bases are, on the whole, rather edge cases. Most of the time, you have to have the rigid-body physics running. Your ship's spinning at 0.1 degrees/second? Great: now you need to keep the ship from flying apart. Again, maybe you could do dynamic welding, but that would be a complicated and tricky bit of coding that's likely to create bugs for unforeseen edge cases. For example, your stable, landed base: what happens if you crash a rover into it? Does the whole, welded base blow up, or can you be sure that you'll detect that event in time to de-weld the parts?

Leaving the rigid-body engine running is guaranteed to handle almost all situations well in terms of maintaining consistent Newtonian physics, whereas shortcuts are almost certain Kraken bait.

Link to comment
Share on other sites

10 hours ago, Brikoleur said:

I'm pretty sure it would be possible to do sophisticated multithreaded highly parallelised physics calculations in the GPU extremely fast.

I'm also pretty sure that it would not be easy.

And I'm absolutely sure there are coders who live for solving just that kind of intricate, complicated problem.

Quite true.  But KSP's problem is that its problem of an assemblage of parts flying in formation connected in a tree scheme (plus more secondary connections from struts, autostruts, and docking) is a complicated problem that has too many internal dependencies.  In HPC parlance, it's considered non-parallelizable.  When every aero force, engine or RCS thrust vector, collison force, reaction wheel torque, resutlant torque from off-axis force vectors, and heat transfer can come from or must be transmitted to neighboring parts, with varying definitions of neighbor, and with varying amounts depending on the neighbor's state, the thread-safety minefield becomes fully intractable.

8 hours ago, katateochi said:

Take part heating as an example. (I've gotta caveat this with I don't actually know how it's done, this is just speculation, I may be wrong). It seems like parts are engaged in transferring heat between their neighbouring parts and this makes perfect sense as this is what would happen in RL, hot thing next to cooler thing will transfer heat to cooler thing. but this means that at every tic each part has to first calculate which it's neighbouring parts are and then calculate what the exchange should be. Just working out for each part what it's neighbouring parts are is a lot of stepping up and down the part-association tree and unless there is a state/part change to the craft (ie from staging, docking, crashing etc) the result of that calculation won't change between frames.

[...]

Another aspect (which kinda annoys me) is landed craft/bases still have all their physics calculated at every step. Sure in RL a parked car still has a bunch of physics acting on it, but in the game context there's no need for that. When a craft/base is on the ground and stopped it should become "locked" and it should stop calculating physics for each part. The only thing it should be doing is checking to see if any internal or external forces are being exerted on it as a whole and if that force goes above a certain threshold then it should switch back to calculating physics on each part. Not only would this increase the performance and enable much larger bases to be built, it would also get rid of that annoying issue of craft sliding around on the surface. 

I don't know if they've optimized since, but based on my experiments with the thermal system around 1.1, it's worse than that.  Parts transfer heat directly between axially-attached parts (stacked fuel tanks and friends), slowly transfer heat to and from a skin layer, which also transfers heat between neighboring parts' skin layers, and dumps heat into the void (shown as negative "radiation flux" in the thermal info).  Parts can also gain heat from "core heat" sources like ISRU refineries and things like the LV-N engine (I think that includes RTGs).  What's really nasty, though, is that when I did my tests, parts could take on radiation flux not just from the sun, but from other hot parts facing them.  A radiator could shine a few hundred kW of heat flux right into a nearby fuel tank.  That makes for geometrically arranged value dependencies that are transcendently nasty for parallelism, and that I hope to heck don't use raycasts.

[...]

Oooh, I kinda like that idea.  Saves some CPU time and increases realism a  bit by bringing a semblance of the static co-efficient of friction to town.  There is a problem though.  One thing to check on if it has focus is "is the sun or a hot part shining on it?"  You'd still have to handle thermo in some cases, and if there's any kind of uneven heating (like some parts being in the shade), the calculations are every bit as interdependent as the physics.

7 hours ago, Brikoleur said:

I'm quite sure a clever programmer would find ways of optimising things by excluding parts/craft from the physics computations if no forces are acting on them. The checklist of things to look at per craft would be pretty reasonable:

  • Are any engines burning?
  • Are any motors (reaction or rover wheels) turning?
  • Is it moving through an atmosphere or along a surface?
  • If not, does it have unlocked wheels?

If none of these conditions are true, you could treat the entire craft as a unit, just keeping it on whatever trajectory it is, or none. Additionally, you could make it so that if a craft in motion gets very close to a "simplified mode" craft, it switches both out of this "simplified mode" since a collision is imminent.

Thermo makes this a mess, too, especially if the craft has focus.  If any parts are at a different temperature, there will be a flow of heat through the craft, and since some parts radiate heat better than others (Rhino nozzle is a weirdly good passive radiator), this will probably be true until the whole craft reaches a vaccuum temperature, and will resume as soon as the sun shows up.  Naturally they don't calculate all this for a craft on rails, but within the bubble, all this mess is an every-frame constant, or at least it was in 1.1.

Link to comment
Share on other sites

15 hours ago, KerikBalm said:

I'm curious, what FPS do you like? I find the difference between Arma and other shooters to be largely a result of it not artificially restricting the range of weapons. IMO, it is fun if you can die from 1 shot across "the map". Arma doesn't have "maps" like other FPS, it has large islands in the 60 to 200 square kilometer range. Going from one end of the map (only counting the land, not the water) can mean travelling over 15km. You can get kills at 2km with the heavy duty sniper weapons, kills at 800m with marksmen weapons are also reasonable. Most FPS games aren't even 800 "meters" across. That's not even considering the bad day you can have if an enemy tank is ~3km away in an elevated position (especially if its able to get in a "hull-down" position), and starts firing 120mm HE shells at your squad's location... or an A-10 opens up with its gatling cannon at 3km away, or an attack helicopter... and kills can be scored even farther away just with a spotter for artillery or a team mate flying a jet armed with LGBs or cluster bombs. IIRC, the laser guided missiles had a lock range of 6km for laser targets...

The tension from knowing how easy you can die creates a lot of fun. I have fond memories from the original Operation flashpoint of a simple 2v2 sniper mission with no respawn. It lasted over an hour, but the whole hour I knew that at any moment I could be killed before I even heard the shot if the enemy saw me first and had good aim.

Arma3 changed the feel a bit with the addition of body armor. Players can seem a bit like "bullet sponges" for 30 caliber weapons and lower, older games had even 5.56 killing in 1-2 body shots except at extreme ranges... though the body armor doesn't help when an HMG opens up on your position, or when a sniper with a .50 or .408 gets you... I think the heaviest body armor can protect from a single .338 to the chest (a 2nd round will kill though).

Arma 3 is kind of funny for me, because I like the engine, but not so much the game itself.  Like, I would in-theory really, really enjoy some of the things that the engine can do and some of the gameplay that can be setup and experienced with it.  But in practice, that is rarely the case.  So for example, you can set up really awesome multiplayer scenarios, either player-versus-player or player-versus-AI with dozens of people where using actual tactics, communication, and good practice will win the day, almost like a raid in an MMO.  That really sounds like my idea of a good time.  But to do that kind of thing you need a large clan-like group that organizes around doing those kinds of things, and I really suck at integrating myself into that social aspect, and the game really does not have a good way to do drop-in kind of things.  

So I just have to content myself getting that experience second-hand through Shack Tactical videos.  In fact, Dyslexi has a pretty good video about performance in Arma 3 where many of his points could be applied to performance in KSP as well:

 

Link to comment
Share on other sites

32 minutes ago, Fearless Son said:

So I just have to content myself getting that experience second-hand through Shack Tactical videos.  In fact, Dyslexi has a pretty good video about performance in Arma 3 where many of his points could be applied to performance in KSP as well:

I really, really liked that ARMA video. Never played the game, but some of the elements resonate for a lot of sandbox games. KSP, people will build ships bigger until the engine cracks like an egg. EVE Online, alliances will cram ships into a system until the servers groan and collapse. ARMA, apparently they build gigantic maps until the engine decides to go on strike.

16 hours ago, Mako said:

Hold up. Let me get this straight. If we ignore the details about the physics for a second, are people actually saying they expect an indie game made by a small, relatively inexperienced team with a small budget working on a somewhat closed-source third-party engine should perform as good as a game made by a large studio of experienced industry professionals with a Triple A budget working on their own completely customizable engine?

I'm not going to ever say that is impossible. I've seen small teams do amazing things on a tight budget. That being said, I would think it's highly unlikely that Squad could deliver Triple A performance levels on their indie project that was likely never expected to go as far as it did.

We don't know how many employees Squad has, but let's say it's less than 30 people. The folks who made Battlefield 1 work in a studio of over 600 people (as of 2016 according to wikipedia, grain of salt sold seperately) who have the benefit of full control over their engine. Battlefield 1 appears to have been made by a team well over 20 times the size of Squad.

The comparison being argued here seems beyond absurd before you even get into the discussion of how extremely different the games are.

I forgot to address this one earlier. I think part of why I've been arguing from the angle of "this is actually a really hard problem" instead of "an indie developer shouldn't need to address this" is that I'm familiar with the limits of high-performance computing: I'm not familiar with the limits of a small indie game developer. I don't want to run my mouth on something I'm not familiar with, so I argue things based on my experience in HPC and physics-based simulations (albeit at the molecular scale, not the macroscopic scale).

3 hours ago, Archgeek said:

Quite true.  But KSP's problem is that its problem of an assemblage of parts flying in formation connected in a tree scheme (plus more secondary connections from struts, autostruts, and docking) is a complicated problem that has too many internal dependencies.  In HPC parlance, it's considered non-parallelizable.

Nice to see another HPC guy on the forums! Unfortunately I have no idea whether rigid-body physics is 100%, full-stop non-parallelizable, or just really difficult to parallelize because of the need to access shared fields.

Link to comment
Share on other sites

Something I also want to address on the topic of parallel physics calculations is that KSP does actually do physics calculations in parallel now (it did not used to) but those parallel calculations are done on different craft when more than one craft is in the simulation at a time, rather than running the calculations on a single craft in parallel.  As others have mentioned, running all the reciprocating physics calculations on a single body composed of multiple discrete components connected in a tree data structure in parallel is really difficult, but getting different discrete objects which do not physically interact with one another to simulate in parallel is comparatively simple.  This ties into why a shooter can calculate a lot of bullets flying around at once while the same number of objects that are all connected and interacting with one another will bog a simulation down.  

Link to comment
Share on other sites

15 hours ago, Brikoleur said:

I'm pretty sure it would be possible to do sophisticated multithreaded highly parallelised physics calculations in the GPU extremely fast.

I'm also pretty sure that it would not be easy.

And I'm absolutely sure there are coders who live for solving just that kind of intricate, complicated problem.

First, anything using GPU acceleration [for consumer use, not dedicated supercomputer hardware] has to limit itself to single point precision.  If Squad wanted to re-write the entire physics engine (and replace Unity), they would likely want double precision.

Also GPUs really don't support multi-threading well.  I suspect that your "coders who live for that" would wind up making a custom way to send small snippets of code for each needed calculation in one (or two) big threads (I think the latest nvidia GPUs can handle two threads in hardware).

37 minutes ago, Starman4308 said:

Nice to see another HPC guy on the forums! Unfortunately I have no idea whether rigid-body physics is 100%, full-stop non-parallelizable, or just really difficult to parallelize because of the need to access shared fields.

Worst case will be "full-stop non-parallelizable" and it shouldn't be terribly hard to construct a craft that will come rather close to it (although doing that with the many parts needed to kill performance wouldn't be quite as easy).  I'm not sure how bad the common case would be, and how hard it would be to come up with an algorithm that would break the rocket into subassemblies that would be useful to compute separately (remember that dealing with 64 or so parts in parallel is trivial (you can access all the memory - if it fits in the local memory)).

Squad isn't going to do this.  I'd be really impressed if it was possible to mod that deep.  Unity *might* try something like this, but I wouldn't hold my breath.

Link to comment
Share on other sites

Simple: you get lower framerates on KSP because KSP relies on processing power, not GPU. If you had a threadripper but a GT1030, you would run it very very fast. If you want hi res textures and graphics mods, that's gonna require more graphical computing power. Your PC Runs BF1 So well because it's a game based mostly on gameplay and aesthetics, not physics. (Disregarding the fact that games like COD are literally the same game with gimmics and smaller maps as the series progresses). Since Battlefield is more graphics intensive then processor intensive, a high end GPU is more important.

Edited by TheMadKraken2297
Autocorrect struck again
Link to comment
Share on other sites

On 2/8/2018 at 4:44 PM, invision said:

no there is not

simply hanging out on the surface of the moon shouldnt run the game at 20 fps

going to space center and then reloading the same ship now the game runs at 100 fps

there is nothing to calculate except bad coding.

 

sorry for saying this, but your drivers are crap. i run this game better on an i5 from 4 years ago better than that

Link to comment
Share on other sites

16 minutes ago, 322997am said:

sorry for saying this, but your drivers are crap. i run this game better on an i5 from 4 years ago better than that

right yet i can run and play any other game with zero issues.

i know its hard for people to accept KSP runs like crap

Link to comment
Share on other sites

Just now, invision said:

right yet i can run and play any other game with zero issues.

i know its hard for people to accept KSP runs like crap

It doesnt run like crap, its just that it runs like crap on YOUR pc. I dont really know the source of the issue, but i get better performance on a gt 730 and a 4 year old i5.

Link to comment
Share on other sites

45 minutes ago, 322997am said:

sorry for saying this, but your drivers are crap. i run this game better on an i5 from 4 years ago better than that

It's very hard to compare performance based on anecdotes. One person may be running < 100-part vessels, another person might be trying to make 1000+ part monstrosities. I peg the probability that he has driver issues as very low, and the probability that he's trying to either run a heavily-modded game, or large part-count vessels, as much higher.

27 minutes ago, invision said:

right yet i can run and play any other game with zero issues.

i know its hard for people to accept KSP runs like crap

Other games have significantly less resemblance to high-performance computing. Have you listened to a single thing said in this thread by people with actual computer science backgrounds and degrees?

Your sense of entitlement does not outweigh the fact that KSP is trying to do something far more ambitious physics-wise than other video games: full-on, rigid-body physics simulations of hundreds of linked parts.

Link to comment
Share on other sites

22 minutes ago, Starman4308 said:

It's very hard to compare performance based on anecdotes. One person may be running < 100-part vessels, another person might be trying to make 1000+ part monstrosities. I peg the probability that he has driver issues as very low, and the probability that he's trying to either run a heavily-modded game, or large part-count vessels, as much higher.

Other games have significantly less resemblance to high-performance computing. Have you listened to a single thing said in this thread by people with actual computer science backgrounds and degrees?

Your sense of entitlement does not outweigh the fact that KSP is trying to do something far more ambitious physics-wise than other video games: full-on, rigid-body physics simulations of hundreds of linked parts.

i know how it works ive been building pc's for over 10 years, and there is no entitlement. i simply pointed out KSP does not run very well especially if the mission goes on for hours. the frame rate will start in the hundreds and slowing work it way down to unplayable. this happens on both of my pc's with completely different specs.

if you go to the space center mid mission then back to that same craft the game runs fine

Edited by invision
Link to comment
Share on other sites

2 minutes ago, invision said:

i know how it works ive been building pc's for over 10 years, and there is no entitlement. i simply pointed out KSP does not run very well especially if the mission goes on for hours. the frame rate will start in the hundreds and slowing work it way down to unplayable. this happens on both of my pc's with completely different specs.

No. You quite clearly don't know how it works.

By saying "I've built PCs for 10 years!", that means you can pick some parts off a shelf and slot them into place.

You haven't worried about cache latency. You haven't worried about thread interference. You haven't uncovered decade-old bugs in code your PI wrote when he was a grad student. You haven't had a very thorough and practical grounding in the difference between O(n*ln(n)) vs. O(n^2) as your less important simulations run O(n*ln(n)), but your thesis work requires an O(n^2) algorithm. You haven't cursed as you used dozens of server-grade supercomputer nodes and wished you had more. You haven't made slides to show the newer students what parallelism and GPU acceleration are. You haven't wondered why a certain, ordinarily super-quick, part of the code was running like molasses until you figured out your PI added an O(n^3) debugging check that worked fine for him but slowed the whole program to a crawl on the still-modestly-sized system you were working on. You haven't idly changed divisions to multiplies-by-reciprocal as a micro-optimization.

No, you're not even remotely as qualified as other people on this thread are to comment on KSP's performance.

Link to comment
Share on other sites

14 minutes ago, Starman4308 said:

No. You quite clearly don't know how it works.

By saying "I've built PCs for 10 years!", that means you can pick some parts off a shelf and slot them into place.

You haven't worried about cache latency. You haven't worried about thread interference. You haven't uncovered decade-old bugs in code your PI wrote when he was a grad student. You haven't had a very thorough and practical grounding in the difference between O(n*ln(n)) vs. O(n^2) as your less important simulations run O(n*ln(n)), but your thesis work requires an O(n^2) algorithm. You haven't cursed as you used dozens of server-grade supercomputer nodes and wished you had more. You haven't made slides to show the newer students what parallelism and GPU acceleration are. You haven't wondered why a certain, ordinarily super-quick, part of the code was running like molasses until you figured out your PI added an O(n^3) debugging check that worked fine for him but slowed the whole program to a crawl on the still-modestly-sized system you were working on. You haven't idly changed divisions to multiplies-by-reciprocal as a micro-optimization.

No, you're not even remotely as qualified as other people on this thread are to comment on KSP's performance.

cool man more power to you now explain this and pay attention to the FPS

8BA52C82891B48AA34FBED572EB36E4242034D4F

179D96808F5DEFA8B3C09FE9FF76243758A15A49

BE21F1322D1C140815E3ECBCFAD42D0CA59D0CA0

 

so far we have maintained 60+ fps from launch until now

412F9D6C11D0DA6FB1CA0F6113138140EFD56271

now we start to drop FPS even tho nothing has changed, we even got rid of some of the craft and send it to blow up so its not in orbit

4BB1B4BB00DE2642F5392C6DA60B355F544C5A0E

 

we land and lose 20 more frames

okay now we go to tracking station and load the craft back up

00A979B178FA588370C576B8E8F2CDBB51AC98B6

Link to comment
Share on other sites

13 minutes ago, invision said:

cool man more power to you now explain this and pay attention to the FPS

If you cannot reproduce this behavior in a clean-room environment with no mods and minimal background processes, you have no reason to blame Squad.

If you cannot reproduce it with minimal background processes, you don't even have reason to blame the modders.

Link to comment
Share on other sites

Just now, Starman4308 said:

If you cannot reproduce this behavior in a clean-room environment with no mods and minimal background processes, you have no reason to blame Squad.

If you cannot reproduce it with minimal background processes, you don't even have reason to blame the modders.

happens stock game too tho. in fact stock game stutters and lags bad if you place just a few objects into orbit. the only reason you dont see low FPS during kerblin orbit is because there is nothing in orbit except a space station.

the fact is the game while fun and probably one of the better games ives played has issues, its far from perfect and im just pointing out that it could run better. theres no need for anyone to feel offended or need to defend squad. 

you want to see something else odd?

go load any craft and keep selecting "revert to launch" and watch your FPS tank to single numbers and you havent even left the ground yet

Link to comment
Share on other sites

36 minutes ago, 0something0 said:

I think we are dealing with memory leaks here. It happens to my understanding when code fails to properly clean up unneeded data on RAM. But I het other people here can explain way better then me.

Improbable. KSP runs on Mono/C#, which has its own memory management. It's not impossible to have a memory leak, I've seen them before in Java which has similarly managed memory, but you have to be doing something unusual in a managed-memory language to get a leak.

Usually, memory leaks occur when somebody allocates a block of memory and forgets to later de-allocate it. Managed memory programs generally don't have that issue because Mono, or the JVM, or whatever, actively looks for unused pieces of memory to reclaim them. The only way to get a leak in a managed-memory language is if some 3rd party API holds outdated references in some ridiculous chain, or they are something like an infinite-loop thread, which is a GC root and thus not subject to garbage collection, or some other bad behavior.

Most of it is either the rigid-body physics, which is just a really difficult computational problem, or people running KSP into the ground by modding or huge part counts.

Edited by Starman4308
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...