Nintendo Switch

[Robert Domico]

Any chance we would get a Nintendo Switch version of the game? I will buy the PC, but it might be nice to have it on a Switch when I am not home. If the Switch can handle games like Doom Eternal and Civ VI, I would think it has a chance to be able to handle KSP2.  

[shdwlrd]

That would be cool, KSP on the go. But I thinking between different hardware used for the Switch compared to the Xbox and PS and going through the hoops with Nintendo, it probably won't happen. At least not right away anyways.

[mcwaffles2003]

With a processor running at 1.02GHz I don't see that panning out for some reason....

Spoiler

System-on-chip	Name	Nvidia Tegra X1
	Process	20 nm, 16 nm[j]
CPU	Type	Quad-core ARM Cortex-A57
		Quad-core ARM Cortex-A53
	ISA	ARMv8-A
	Clock speed	1.02 GHz
	L1 cache	48 kB + 32 kB per core
		32 kB + 32 kB per core
	L2 cache	2 MB
		512 kB
GPU	Type	Nvidia GM20B Maxwell-based
	Clock speed	307.2-768 MHz
	Stream processors	256 (157-393 GFLOP/s)
	TMUs	16 (4.9-12.3 GTexel/s)
	ROPs	16 (4.9-12.3 GPixel/s)
	Compute units	2
Memory	Total	4 GB LPDDR4 SDRAM @ 1600 MHz
	Bandwidth	25.6 GB/s
Storage	Main	32 GB eMMC NAND flash memory
	Removable	microSD/HC/XC (up to 2 TB)
Media	Name	Nintendo Switch game card
	Capacity	1-64 GB
Display	Main	6.2-inch, 720p LCD screen @ 237 ppi
	External	1080p, 720p and 480p via HDMI 1.4b

 

[Delta Space]

3 hours ago, Robert Domico said:

Any chance we would get a Nintendo Switch version of the game? I will buy the PC, but it might be nice to have it on a Switch when I am not home. If the Switch can handle games like Doom Eternal and Civ VI, I would think it has a chance to be able to handle KSP2.  

I doubt it, the Nintendo Switch uses an ARM processor architecture that is nearly a decade old now, efficiency and multicore performance are great, single core performance is astronomically bad... Also KSP 1 can easily eat 4GB of RAM, and the 1600MT/s speed is going even further hurt the single core speed of the processor. KSP 2 will hopefully have some clever way of expanding the maximum practical size of a craft, but it will still probably by limited by single core speed above all else.

[Dr. Kerbal]

Even my PS4 has a hard time sometimes when I play KSP with gravity assist.

[SpaceFace545]

Nope

[K^2]

Honestly? Like, honestly, honestly? It can be done by a competent port team. There's more than enough processing power to handle KSP2 with downgraded graphics.

Problem is, they've never done that sort of optimization even for original KSP, and KSP2 is a much more ambitious project with insufficient resources to spend on optimization.

So people who say it can't be done because Switch isn't powerful enough are wrong. But yeah, unlikely to happen because the necessary resources just won't get invested.

[runner78]

52 minutes ago, K^2 said:

Honestly? Like, honestly, honestly? It can be done by a competent port team. There's more than enough processing power to handle KSP2 with downgraded graphics.

Problem is, they've never done that sort of optimization even for original KSP, and KSP2 is a much more ambitious project with insufficient resources to spend on optimization.

So people who say it can't be done because Switch isn't powerful enough are wrong. But yeah, unlikely to happen because the necessary resources just won't get invested.

The graphic is not the (only) problem, KSP is CPU hungry. I have heard from other sources how many developers have problems porting their games to the switch due to poor performance. And indie developers in particular don't have the time and money for an extensive porting process. Presumably, KSP had to be limited so much, e.g. in terms of max number of parts, that the game is practically not the same anymore.

[K^2]

3 hours ago, runner78 said:

The graphic is not the (only) problem, KSP is CPU hungry. I have heard from other sources how many developers have problems porting their games to the switch due to poor performance.

Sure, sure. But KSP doesn't need to deal with a dozen characters with close to a hundred animated bones each, running complex animation graphs and mixing several animated fragments, while updating thousands of FX particles from dozens of emitters, and managing path finding and behavior trees for several enemies. This is what most of the CPU time is spent outside of feeding GPU with things to draw in most games.

KSP has very little or none of the above, while running physics comparable to what you run for debris collision on a typical PC game. The reason KSP manages to still tax CPU is crap optimization, I'm afraid. Unity's physics is not the best. It is heavily based on PhysX which isn't a great starting point, but I don't know if it accounts for all of it. I've been able to do decent enough vehicle simulations with PhysX cheaply enough to run on an MMO server. Of course, that didn't involve using PhysX constraints solver, and that's first thing Squad should have thrown on the trash pile rather than trying to fix it. Even with that in mind, I'm not sure why performance is quite as bad as it is. Maybe I'm underestimating how bad PhysX solver is, after all.

That said, new versions of Unity do provide for a way to use Havok instead. Now Havok has actually been paying attention to improvements in constraints systems and solvers, so they've gotten to the point where their engine is decent. It provides better stability while running a lot lighter. That means if you want to go with KSP-style craft construction, you can do so with way fewer welds and still have less Kraken. For a similar craft, you can probably cut CPU load by an order of magnitude at least. That alone should be enough to run KSP on switch as is, unless there's another sink somewhere.

Of course, the correct solution is to have a custom solver for the craft, one which makes use of the fact that pretty much every constraint is a weld, so you're really building a rigid body. Even if you want to keep the flex, so you want to continue having floppy joints, solving the craft as rigid and populating the constraint cache with result will mean you can probably get a good solution in a single iteration without any sacrifices to stability. That will give you nice, stable physics for all but the largest craft with absolutely minimal CPU impact.

There are still a lot of unknowns in terms of what Intercpet wants to do with KSP2 that's different from KSP. Colonies and shipyards, depending on how they're built, could be pretty major resource hogs. Multiplayer always throws wrench into systems. So there are places where KSP2 might end up far more CPU intensive. And maybe these are features that'd have to get scaled down for a Switch port. But the core of the game can most certainly run on that console.

Now, grain of salt is that I've never worked with a Switch hardware. But it will outperform a 360 in any fair benchmark, and I'm fairly familiar with the later. I also have some experience optimizing games to run on console hardware they weren't built for with focus on physics, animation, and FX performance. So I'm pretty confident with the above statements.

4 hours ago, runner78 said:

And indie developers in particular don't have the time and money for an extensive porting process.

No argument there. But that's part of why Unity's such a sand trap. You stand up a game on Unity because you don't have resources to do it with a more sophisticated engine, and then you don't have resources to optimize your performance on it. Not to hate on Unity, or anything. There's certainly a niche for it, but it's not the best engine for every game made on a budget.

[runner78]

Havoc on Unity works only with ECS, it is not clear whether KSP 2 even uses this, probably not.

KSP has also some background processes like calculate all orbits every frame/physic-steps (also in the future).

If you wield all parts together as one rigid body, the CPU impact would be minimal, but also vessel behavior and  gameplay would massifly change.

 

[DerkyJerkyWreaksHavoc]

On 12/8/2020 at 11:18 AM, Robert Domico said:

Any chance we would get a Nintendo Switch version of the game? I will buy the PC, but it might be nice to have it on a Switch when I am not home. If the Switch can handle games like Doom Eternal and Civ VI, I would think it has a chance to be able to handle KSP2.  

why is this even in KSP2 Section? @Vanamonde @Geonovast Someone plz put this in Forum lounge.

[Vanamonde]

4 hours ago, DAFATRONALDO2007 IN SPACE said:

why is this even in KSP2 Section? @Vanamonde @Geonovast Someone plz put this in Forum lounge.

The OP mentions KSP2. This is the right sub. 

[Guest]

I wish this could be on the Switch. But again I don't think it would run the best. There is a huge difference in performance on my computer of let's say minecraft than that on the switch.

We still aren't even getting this on Mac yet, so Switch is out of the ballpark for now at least  .

[K^2]

5 hours ago, runner78 said:

Havoc on Unity works only with ECS, it is not clear whether KSP 2 even uses this, probably not.

Agreed. That's why a Switch port would have to convert all of that, which would make it unreasonably expensive to do that. But again, not a hardware limitation so much as choice of framework for the main game.

Keep in mind, I'm saying that KSP2 can be made to run on Switch with minimum sacrifices to game quality. Not that it would make financial sense to do so.

5 hours ago, runner78 said:

KSP has also some background processes like calculate all orbits every frame/physic-steps (also in the future).

During time-warp everything's on rails. Outside of time warp, only loaded craft (within 2km?) are simulated and everything else is on rails. And for the loaded craft gravity is just folded into other forces, so it's just part of simulation.

KSP2 will have to figure out how to do this for torch ships. I'm not sure what they have in mind here, but technically only a ship within SOI needs to be numerically integrated. For a ship in interstellar space, outside of any SOI, there is an analytic solution for constant thrust. So these can still be on rails, leaving just a few in-system torch ships that are in flight at any given time. That's reasonable even under 1M time warp we'll probably need for interstellar.

6 hours ago, runner78 said:

If you wield all parts together as one rigid body, the CPU impact would be minimal, but also vessel behavior and  gameplay would massifly change.

A weld is a type of constraint that the KSP already uses to hold modules together. It doesn't make a ship completely rigid, because there is Baumgarte relaxation applied (or equivalent - I don't recall exactly how PhysX handles this). That effectively turns every weld into a very stiff spring, allowing some flex.

Now, I would argue that having had completely rigid rockets would have been fine from the start, but we're kind of stuck with what we have now. Here's the thing, though. The methods used to solve constraints are all iterative. If you can guess the approximate solution and start with it, you can simulate physics in way fewer iterations. So what if we guess that the ship approximates a rigid body? Well, we can pre-compute the pseudo-inverse for the constraints equations assuming a rigid body, use the sum of forces and torques to substitute accelerations for every module, and get approximate constraint forces as an output. We can then feed these approximations as a starting point into a single iteration of a general constraints solver to get a very nice, very stable simulation with way, way less computational effort.

If that's still not enough, the next step is starting to turn some short stacks into rigid bodies. Do you really need the flex between these in-line reactions wheel, battery, and monoprop tank you threw on top of your fuel stack? Probably not. Turn them into a single rigid body, and you now have a lot less to worry about during simulation.

Is all of this easy to do? No. It requires custom solver, somebody who knows how to do physics simulation, and significant amount of time developing and testing. So I don't expect many of these optimizations to happen in KSP2. But it is something that can be done if somebody just gave you a large budget for a Switch port for some unknown reason.

[runner78]

Newer Unity has a newer PhysX with a new solver type for better joins behavior, but i don't now about performance.

If you join parts as on rigid body you have the problem  how to decides with part are join together, is it decide by the game oder the player wile building?
And also add complexity to building the vessel at runtime: remove the the original components and joints, create new parent with the new rigid body, calculate new mass an center of mass, rejoin the other parts. that is a potential for bugs and problems, and can have a negativ impact in vessel loadingtime. Especially for large structures.

Even oribts are on "rail" they still have to be calculated. Even with my AMD ryzen i start from c. 60-70 vessels/debris to notice some performance drops. That would be a good approach for ECS and burst for faster calculations.

[Corona688]

On 12/8/2020 at 10:18 AM, Robert Domico said:

Any chance we would get a Nintendo Switch version of the game? I will buy the PC, but it might be nice to have it on a Switch when I am not home. If the Switch can handle games like Doom Eternal and Civ VI, I would think it has a chance to be able to handle KSP2.  

You're comparing graphics-focused games to CPU-focused games.  It takes an actual computer to handle KSP.1  Even a full-sized console struggles.  It all depends how much more efficient KSP2 is.

7 hours ago, runner78 said:

Even orbits are on "rail" they still have to be calculated. Even with my AMD ryzen i start from c. 60-70 vessels/debris to notice some performance drops. That would be a good approach for ECS and burst for faster calculations.

How many seconds does it take a modern PC to sort one million items?

...Trick question.  A ten-year-old garbage PC can do that thousands of times per second - on one core.  Sixty ellipses, calculated 100 times a second, should be no problem at all.  Some other cruft is accumulating and slowing KSP down, either as a design flaw, or a Unity flaw.  I'm really hoping that'll go away when they rebuild it from the ground up for ksp2.

Phones, tablets, switches, and other tiny machines aren't quite as good due to cache size and memory bandwidth limits.

Edited December 11, 2020 by Corona688

[K^2]

13 hours ago, runner78 said:

If you join parts as on rigid body you have the problem  how to decides with part are join together, is it decide by the game oder the player wile building?
And also add complexity to building the vessel at runtime: remove the the original components and joints, create new parent with the new rigid body, calculate new mass an center of mass, rejoin the other parts. that is a potential for bugs and problems, and can have a negativ impact in vessel loadingtime. Especially for large structures.

All of these things are pretty cheap computationally, so I don't expect impact on loading times. But you are correct about it adding to code complexity, so it would take time to develop and debug, which adds to development costs.

13 hours ago, runner78 said:

Even oribts are on "rail" they still have to be calculated. Even with my AMD ryzen i start from c. 60-70 vessels/debris to notice some performance drops.

That's... honestly a surprise. It shouldn't. I don't know what KSP is doing there, but I can walk you through computations that need to be done for update and even run benchmarks if you'd like. With correct implementation, you should be in high hundreds of thousands or low millions before it has frame-rate impact. I tend to run my KSP games very clean, with small amount of debris, so I've never noticed this, but if it's really that bad, it's either a bug or a really bad error in code. I hope they're not trying to still run time steps during warp, that'd be a pretty obvious mistake.

(Edit: Actually, I wonder if the problem is the game trying to draw trajectories... Still shouldn't be that bad, but that can at least explain some of it.)

6 hours ago, Corona688 said:

Phones, tablets, switches, and other tiny machines aren't quite as good due to cache size and memory bandwidth limits.

Yeah, looking at cited cache on Switch, it looks limiting. But it's not all about the amount. The original PS4 and XB1 (the non-Pro version) had abysmal cache performance in certain situations. The biggest problem was with interlocked atomics, and these are used basically everywhere if you're doing any sort of multi-threading. Given the architecture, I suspect it's not as much problem on Switch.

Also, animation is where cache performance hurts you the most, especially, low size and/or associativity of cache. Even KSP2 doesn't look like it will have a lot of that. Kerbals are pretty simple, so I don't expect them to have 200+ bones over which you need to interpolate ten different animation fragments. That's the sort of task on which your cache starts to cry, usually. Blending a few tracks over a few dozen bones hasn't been a problem for anything remotely recent for over a decade.

Edited December 11, 2020 by K^2

[Corona688]

19 minutes ago, K^2 said:

Also, animation is where cache performance hurts you the most, especially, low size and/or associativity of cache.

KSP's bad memory-related habits (load and continually iterate everything) built on Unity's bad memory-related habits (seething, relentless deletion and allocation of tiny memory spaces), built on .NET's bad memory-related habits (all of the above, clamped stable with periodic garbage collection) is a system that does not lend itself to cache associativity.

[shdwlrd]

17 hours ago, runner78 said:

Even oribts are on "rail" they still have to be calculated. Even with my AMD ryzen i start from c. 60-70 vessels/debris to notice some performance drops. That would be a good approach for ECS and burst for faster calculations.

 

3 hours ago, K^2 said:

That's... honestly a surprise. It shouldn't. I don't know what KSP is doing there, but I can walk you through computations that need to be done for update and even run benchmarks if you'd like. With correct implementation, you should be in high hundreds of thousands or low millions before it has frame-rate impact. I tend to run my KSP games very clean, with small amount of debris, so I've never noticed this, but if it's really that bad, it's either a bug or a really bad error in code. I hope they're not trying to still run time steps during warp, that'd be a pretty obvious mistake.

I can attest to that behavior with the Ryzen. My 2700x will start physics hiccups around that point. All the AMD processors I've used the physics hiccups would start at about 50 craft/debris in orbit. (A6, A8, A10, Ryzen 2700x processors.) All the laptop I7's I've used would start the physics hiccups at about 110+ range of crafts/debris with the number going up with each new generation. (3rd, 6th, 7th gen I7's laptop processors.)

Personally I think the game was coded or optimized in a way that favors Intel processors and chip sets.

Edited December 12, 2020 by shdwlrd

[Corona688]

Someone mentioned collision and that was a very good point.  10 craft in orbit, it has to check 100 times if any craft are coming into physics range of each other.  100 craft in orbit, it has to check10,000 times.  That still shouldn't be a problem for a modern processor, but remember - only things built into Unity and .NET are going to be blazing fast, and the whole "physics range" thing is a workaround for Unity not natively supporting the things they wanted.

There's probably a way around that, at least a way to use some vector math builtins, provided they structured their data in the exact right picky way for that to work.  It's doubtful they ever had time to optimize that, and now being buried under almost a decade of extensions, it'd be pretty hard to change now.

TL/DR, maybe ksp2.

Edited December 12, 2020 by Corona688

[K^2]

1 hour ago, Corona688 said:

Someone mentioned collision and that was a very good point.  10 craft in orbit, it has to check 100 times if any craft are coming into physics range of each other.  100 craft in orbit, it has to check10,000 times.

No, it doesn't. Game only checks for collisions if it's within range of player. So it's O(n) check, not O(n²).

1 hour ago, Corona688 said:

That still shouldn't be a problem for a modern processor, but remember - only things built into Unity and .NET are going to be blazing fast, and the whole "physics range" thing is a workaround for Unity not natively supporting the things they wanted.

Not how that works either. While there is plenty of inefficient garbage in .NET, if all you're trying to do is iterate through a list and do a simple distance check, the loop will get JITed and you'll have very close to native performance so long as you don't do anything silly, like start allocating memory. Which I can't guarantee Squad didn't do, but there's definitely a way to do all of this without taxing CPU at all.

[Corona688]

3 hours ago, K^2 said:

No, it doesn't. Game only checks for collisions if it's within range of player. So it's O(n) check, not O(n²).

Are you positive?  I remember strange lags that I later managed to attribute to a lot of debris suddenly getting close to each other.

[K^2]

2 hours ago, Corona688 said:

Are you positive?  I remember strange lags that I later managed to attribute to a lot of debris suddenly getting close to each other.

Yeah. Could it be something related to CommNet? There are definitely bad ways to code connection checks that will cause lag spikes when things enter/leave proximity of each other.

[Corona688]

Nope.  They were all inert debris.

[K^2]

Yeah, but I can actually see why someone would think that doing proximity checks first, and only afterwards drilling into the craft to see if it has an antenna, would be a good idea, because proximity check is a cheap computation.

In contrast, we know that satellites will happily pass through the mountains if player isn't nearby, and collision scene progressively loading around player is a known cause of some bugs related to moving near surface at high speeds. Finally, even you were to bother to load collisions for distant craft, you'd have to relocate origin to have anything like required precision, and even then, under time warp, you just aren't going to get any collisions, as the game is doing intersection tests rather than sweeps.

Basically, it'd be really, really stupid to do proximity checks on debris vs debris for sake of physics, as you'd be just discarding the result. I'm not going to say it's impossible, but I find poorly optimized CommNet to be way more likely.