Nintendo Switch

[MechBFP]

On 12/8/2020 at 1:10 PM, mcwaffles2003 said:

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

  Hide contents

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

 

And that is when it is docked. It has an even lower clock when undocked.

[Kosmix1]

It would be really cool but i dont think it would work.

Maybe if they release a switch pro that is as powerful as a ps4.

[runner78]

On 12/11/2020 at 4:52 PM, Corona688 said:

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.

I also don't know exactly what KSP calculates, but I not only believe the orbits of the current time, but also in the future to calculate when, for example, one leaves / enters the sphere of influence of a planet / moon.

On 12/11/2020 at 11:44 PM, Corona688 said:

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.

Unity is currently working a lot in the memory area. ECS e.g. relies on optimized memory layout and garbage collerctor-free API. Their burst compiler does not work with reference objects. The gc allocation is also reduced or completely removed for other APIs.

Edited December 14, 2020 by runner78

[K^2]

1 hour ago, runner78 said:

I also don't know exactly what KSP calculates, but I not only believe the orbits of the current time, but also in the future to calculate when, for example, one leaves / enters the sphere of influence of a planet / moon.

Well, exiting SoI isn't really a problem. You update the position for new frame, and simply check against SoI radius. If you are out, you need to do a bit of extra work to find the exact time you've left the previous SoI, and then simulate forward from there. While that can cost a few thousand cycles, it's going to be a rare occasion in practice.

Entering SoI is more interesting, but there are a lot of simplifications here too. You don't need to consider very SoI in the game - just children of current SoI. So if you're orbiting star, only check planets, and if you're orbiting a planet, only check moons. Next, it's very easy to construct an AABB for each SoI you need to check.  Feasibility of each AABB collision can be evaluated with just two SIMD instructions, but even if you have to do it with managed C# code, it's done in a few CPU cycles. For any SoI that are still feasible, we have to start doing real work. First step is to break trajectories into segments, inflate the SoI a bit to correct for curvature, and see if there's an intersection there. That's still very cheap. If you found a potential intersect, the final step is an iterative algorithm that finds the exact time you've entered new SoI.

The great thing about all of the above is that while the verification steps get progressively more complex, they also get progressively less common. Most of the time, debris are going to be nowhere near SoI boundaries, and you'll be able to reject it really early. And doing iterative solutions for the few pieces that did encounter an SoI boundary or came close enough to have to check, is still very reasonable.

[runner78]

Don't forget, the orbits is one part of many others that run on a frame, and you only have a few milliseconds per frame, and if you simplify the orbit calculation too much,  it becomes too imprecise. With modern Unity you can using the job system and burst and calculate much faster, but only in the limits of the hardware.
I hope the part system from KSP 1  will not be adopted because it is anything but optimal.

It's best to design the game for the lowest target Hardware from the start, especially if it's just an indie game. But if you develop a game for low / medicore hardware you have to make cuts. For other games you can simply reduce the range of vision, fewer effects, fewer details. With KSP, however, one would have to make deep cuts in the core simulation. In the end, despite optimization, it would only have the same feature-set as KSP 1.

[K^2]

11 hours ago, runner78 said:

Don't forget, the orbits is one part of many others that run on a frame, and you only have a few milliseconds per frame, and if you simplify the orbit calculation too much,  it becomes too imprecise.

Lets break it down. Here are major CPU tasks.

• Rendering - lives on its own thread, takes up a logical core, and we don't need to consider it further.
• Physics - solver needs to happen on a single thread, collisions and BVH updates could be spread out, but PhysX sucks, and bottles up main thread.
• Animation - can be safely distributed, but Unity might not. Lets say it happens in line. Fortunately, not a lot to do.
• Component updates - The calls happen on main thread, so this is definitely something you want to unload to jobs, as this includes aerodynamics, resource use, etc.
• World State - For KSP2 all colony stuff should happen here. Jobs, definitely jobs.
• UI - This is basically part of component update in Unity, and it's light enough. Can stay on main.
• Orbits - As we don't need to consider interactions, this can safely be don in jobs.

Because physics, animation, and UI all live on the main thread, we want to move everything we can off. We also have two logical cores effectively spoken for with rendering and main threads. I'm not sure how well Unity uses the co-processor on Switch, so I'm going to assume the worst and plan for everything to run on just the four main cores with no hyperthreading. So we have two cores to use for jobs. We're also going to target 30FPS. So that's 33ms/core or about 67ms of total compute per frame for all the jobs.

• Component updates - lets dump most of our compute here. 40ms/frame budget seems very reasonable. Yeah, a lot of that might be eaten by aerodynamics and such, but then we can stagger some of the work between frames. You don't need fuel to update at 30Hz, for example, it'll do just fine at 10Hz, so you can do only 1/3 of computations per frame. Life support, etc can be even less frequent. 40ms is actually a ton of time even if you have to write your code in C#.
• World Update - Honestly, 10ms tops. Again, most of the exciting stuff that has to do with any new KSP2 features, like colony state, can easily be split between frames.
• Orbits - With above in mind, can easily dedicate 15ms per frame leaving a good safety margin.

Now we're looking at how much overhead we're looking at. Orbital computations are going to be in very predictable, easily JITed loops. There is no memory churn at all - everything we need is already allocated. C# can give you 30% of native easy. So call it 5ms of native time. That's 5M cycles of the main CPU I can dedicate to orbital computations. Given that majority of debris will not be doing any SoI changes on any given frame, and that early rejections are all cheap with optimizations mentioned in previous posts, 5k cycles on average is plenty. So we're looking at 1k pieces of debris easily simulated at solid 30FPS. And that's conservatively. There are still places where corners can be cut. Even, potentially, starting to stagger debris update as well, splitting work between frames. There is still a lot of breathing room. And this is for the most conservative estimate for just the main 4 cores of Switch.

12 hours ago, runner78 said:

But if you develop a game for low / medicore hardware you have to make cuts. For other games you can simply reduce the range of vision, fewer effects, fewer details. With KSP, however, one would have to make deep cuts in the core simulation. In the end, despite optimization, it would only have the same feature-set as KSP 1.

There's not that much simulation going on, that's the whole point. Most modern games do more physics simulation for their FX than KSP did for the entire game. And while KSP2 is adding a lot of features, very few of them have anything to do with additional simulation load. The biggest one is world state updates related to colonies and transport routes, and that's all accounted in above generously.

The most expensive additions of KSP2 all have to do with rendering, both in terms of CPU and GPU usage, and as you note above, that can safely be scaled down.

KSP is not a big game at all. KSP2 is really not that much bigger. It's all relative, of course, but I'm used to planning and budgeting much larger titles. And there is nothing difficult about optimizing the known scope of KSP2 to fit within parameters of Switch hardware. It's just time. I also understand that it's time that Intercept simply doesn't have. When you're looking at a AAA game with hundreds of engineers, and you know it's going to take a month for somebody to take a particular task and make it stable when running multi-threaded to make it fit in CPU budgets, that's fine. When you barely have enough engineers to land your core gameplay features, that suddenly doesn't sound viable anymore. But at the end of the day, we're still talking about Switch version almost certainly not happening because it'd be a very expensive port that's probably not going to pay for itself, and not because Switch hardware just can't run a game of KSP2 scope. The later just isn't true.

[Probro]

you've got to realise that nintendo switch isnt as powerful as the px5 or the xbox whatever its called these days, the switch can run doom but only if the settings are cranked at its lowest settings and at 720p 60fps or 1080p 30 considering when your skils get better your gonna need a more powerful system to run your rockets, i dont think its a good idea

[runner78]

10 hours ago, K^2 said:

Lets break it down. Here are major CPU tasks.

• Rendering - lives on its own thread, takes up a logical core, and we don't need to consider it further.
• Physics - solver needs to happen on a single thread, collisions and BVH updates could be spread out, but PhysX sucks, and bottles up main thread.
• Animation - can be safely distributed, but Unity might not. Lets say it happens in line. Fortunately, not a lot to do.
• Component updates - The calls happen on main thread, so this is definitely something you want to unload to jobs, as this includes aerodynamics, resource use, etc.
• World State - For KSP2 all colony stuff should happen here. Jobs, definitely jobs.
• UI - This is basically part of component update in Unity, and it's light enough. Can stay on main.
• Orbits - As we don't need to consider interactions, this can safely be don in jobs.

Switch has 3 usable CPU cores (so far i know) 

Mainthread: 1
Rendering: 1
Physics: some task are multithreaded

Job system uses all cores except for the core where the mainthread is running.  If the job system is occupied and there is free capacity, jobs can also be carried out on the mainthread-core.
With 3 cores on Switch, there are only 2 job workerthreads. And one of the worker thread share the core with the rendering thread. 
Even with jobsystem, there is simply a limit for parallelization. And don't forget: only 1 GHz ARM cores.

At the moment we just don't know what has to be calculated, but I think that KSP has to be crippled if you have to run it on the switch.
And every such small calculation accumulates and what you don't notice on a desktop PC can suddenly become a problem on the switch.

[K^2]

2 minutes ago, runner78 said:

Switch has 3 usable CPU cores

Ah, one's probably taken up by OS and not available to devs. That's not uncommon for game consoles. Just didn't think they'd do that to a system with only 4 cores to begin with. That would definitely require to stagger more tasks and shrinks time available to orbital computations to something like ~5ms. Lets run with that.

Just now, runner78 said:

Job system uses all cores except for the core where the mainthread is running.

You don't have to use Unity's job system. You can thread things in C# without relying on any frameworks. While it is extra effort, it does result in less overhead and more control over how things are scheduled. So it'd be easy enough to run a compute thread on the core not busy with anything else.

8 minutes ago, runner78 said:

And don't forget: only 1 GHz ARM cores.

Yeah, that's why 5ms is 5M cycles. That's a more useful measure of real computation you have, anyways.

With just one core available, C# overhead becomes too costly. Change of plan. Convert orbital computations code to native. There isn't really any serious problem with running native code in Unity other than it becomes a bit less portable. But since we're specifically putting in effort into a Switch version, and we're agreed that money is no barrier, then re-writing the orbital computations code in C/C++ and compiling it specifically for Switch isn't really that big of a deal. The binaries then get loaded and executed directly from C#. So we still get the 5M cycles of CPU time to do computations, and we still don't need more than 5k cycles per piece of debris on average, so we can still have 1k pieces of debris with smooth 30FPS.

13 minutes ago, runner78 said:

At the moment we just don't know what has to be calculated, but I think that KSP has to be crippled if you have to run it on the switch.

Are they planning an AI system that does complex strategy or control large complex ships? No, because there wasn't a rec for that. Are they planning to introduce creatures with complex animations? No, because they'd have more recs for animation. Everything they can be making, based on jobs that have been posted and what we know Intercept got from Space Theory, is accounted for. KSP2 simply cannot have surprises that will break the CPU budgets above.

The only thing we aren't considering is whether physics can actually run on main thread as is. It's entirely possible that switching over to Havok physics, which means huge restructuring, is necessary. But with Havok physics and good optimization of all other code, possibly using native code for a few critical pieces, everything that needs to run on CPU fits EASILY with way better performance than we currently see of KSP on consoles. There isn't a "we don't know" there. Like I said, KSP is a small game and KSP2, while significantly larger, is still not a big game. It's not hard to plan these out if you have experience doing just that, both in terms of time it takes to write the code and in terms of CPU budgets.

Your claim that KSP can't run on Switch is based on nothing but observation that it runs poorly on consoles, and the game is horribly optimized. It shouldn't run on PC as bad as it does. Other games run way more physics than KSP does PLUS all the stuff that KSP doesn't do and manage solid framerates that don't turn into slideshow whenever something explodes. Some of it is Unity, and you can't fix that without re-writing the game from scratch, but a lot of it is just poorly optimized code and, given time and resources, you can do a lot better.

[runner78]

35 minutes ago, K^2 said:

You don't have to use Unity's job system. You can thread things in C# without relying on any frameworks. While it is extra effort, it does result in less overhead and more control over how things are scheduled. So it'd be easy enough to run a compute thread on the core not busy with anything else.

I think the job system has less overhead as other solutions (its designed for game), is't GC free and the core of the jobsystem is native, not C#. C# Task has GC and Context switches. Is ok for business applications, but have an impact on games. The job system uses workerthreads and can schedulte jobs that can run without delay between jobs. And manage also dependencies between jobs.

48 minutes ago, K^2 said:

With just one core available, C# overhead becomes too costly. Change of plan. Convert orbital computations code to native.

This is where the burst compiler comes into play, burst compile the C# jobs to native code for the taget Platform (AOT). Uses clang/llvm to optimize the code and uses SIMD. In some cases ist even faster as "default" C++ code. but definitely faster than mono.

Unity has also IL2CPP to compile the game to native, without Mono. Brings some performance advantages, but modding becomes more difficult.

57 minutes ago, K^2 said:

Your claim that KSP can't run on Switch is based on nothing but observation that it runs poorly on consoles, and the game is horribly optimized

I not claim it can't run at all. I claim it can't run with the current/future featureset. You would have to "optimize" and simplify too much, so that the feel of the game will change or the game will be a completely different one.

[K^2]

49 minutes ago, runner78 said:

Task has GC and Context switches.

Anything will have context switches if it's not kernel level code, as it's up to OS to schedule tasks. And again, if custom jobs code needs to be native it can be. My only real concern with Unity's job system is collisions with render thread. If it's clever enough to avoid these and lets you schedule an idle core, great. If not, there are ways to get around that.

52 minutes ago, runner78 said:

Uses clang/llvm to optimize the code and uses SIMD.

Yeah... SIMD is sort of the main problem. I'm not going to out-perform an optimizer on general tasks, because I know that in best cases I can match it, and often, a good optimizer will just generate better code than I can. SIMD is one notable exception. Even highly specialized SIMD compilers, like Intel's ISPC, can't come up with clever ways of re-ordering operations to get maximum performance. Cross product is a good example where you can get a 3:1 performance advantage with clever use of SIMD.

The other thing is that I can profile and tune native code compiled from C/C++ source. With a burst compiler, you just have to cross your fingers and hope. If there's a bottleneck due to some specific way it decided to chew on cache, you aren't fixing it.

If you're trying to squeeze absolutely every last bit of performance out of a system, going native is the only way.

45 minutes ago, runner78 said:

You would have to "optimize" and simplify too much, so that the feel of the game will change or the game will be a completely different one.

Not a single optimization mentioned above simplifies the game in any way. We're talking purely about performance improvements. The only thing that has been suggested as an actual downgrade is visuals. So we are discussing a feature-complete game, and if you think that a particular aspect cannot run as is, I'm yet to see it pointed out.

[runner78]

5 minutes ago, K^2 said:

The other thing is that I can profile and tune native code compiled from C/C++ source. With a burst compiler, you just have to cross your fingers and hope. If there's a bottleneck due to some specific way it decided to chew on cache, you aren't fixing it.

Bust has an inspector that display the generated native code and give you also warning if not possible to vectorizing the code.
Manual SIMD optimization can be time consuming, AAA Games have entire teams for that, where only the optimization team probably has more programmers than the entire KSP programmer team.  KSP2 is still an indie Game.
Burst give you performance out of the box and if you know what you're doing, you can get even more out of it.

26 minutes ago, K^2 said:

Not a single optimization mentioned above simplifies the game in any way. We're talking purely about performance improvements

With weak hardware you can optimize as much as you want, at some point you reach the limit and you have to remove or simplify features. Optimization won't be enough, we also don't know what else has to be calculated in the background. We only consider the obvious parts of the game here. There is also the Terrain / LOD system. Fuel consumption / distribution, deltaV calculations. Each one is just a small thing, but everything accumulates together.

[runner78]

I also saw that the Switch only has 3GB of RAM available for gaming, shared for GPU and CPU.

[K^2]

10 hours ago, runner78 said:

Bust has an inspector that display the generated native code and give you also warning if not possible to vectorizing the code.

I can always look at generated code in debugger, but then what? When writing in C/C++, there is a lot more control over what gets generated. I have full control over memory layout, I can drop in streaming instructions, there are intrinsics that will prevent re-ordering, I can make sure more or fewer things are inlined, I can build jump tables to avoid unnecessary calls and returns or virtualization costs... C# gives me none of that. If I'm unhappy with code that got generated, tough luck.

10 hours ago, runner78 said:

Manual SIMD optimization can be time consuming, AAA Games have entire teams for that

I know. It's part of what my team does, along with maintenance and optimization of in-house physics and animation engines.

10 hours ago, runner78 said:

optimization team probably has more programmers than the entire KSP programmer team

Yes. We've already established that in order to squeeze KSP, let alone KSP2, onto Switch, we need a team significantly larger than the team that made the game. That's the premise of this entire discussion. Can we make KSP2 on Switch if we throw AAA resources at it. I'm arguing that the answer is yes, because I've worked on similar type of problems for larger games.

10 hours ago, runner78 said:

With weak hardware you can optimize as much as you want, at some point you reach the limit and you have to remove or simplify features.

We're not talking about running this on Atari, for crying out loud. Again, KSP is not a big game. It does NOT do anything that should be CPU intensive. It just doesn't. All of the performance problems of KSP are from bad optimization. And while squeezing it into Switch would be going above and beyond, it works without any cuts.

Again, if you think that something I've described above requires cuts, point it out. You're just repeating that something has to be cut, even after I budgeted out everything that needs to be done for the full KSP2 game, but you aren't pointing to any specifics. That's not an argument. That's the exact opposite of an argument.

10 hours ago, runner78 said:

There is also the Terrain / LOD system. Fuel consumption / distribution, deltaV calculations.

Terrain can and probably is streamed almost directly. The overhead is minimal and split between many, many frames. LOD system is part of rendering thread and isn't different from any other game, so that's taken care of. Fuel use is part of component update and we have a healthy budget for that. Also can be split between frames. And I've covered all of that. We can break it out, and I can schedule out the entire game for you. I'm just worried at this point that you'll just say that we're obviously missing something even then.

Planning out projects like this is part of my job. It's what I do.

10 hours ago, runner78 said:

I also saw that the Switch only has 3GB of RAM available for gaming, shared for GPU and CPU.

Yeah, and the CPU needs almost none of that. In fact, we'll want to reduce memory footprint as much as possible, as Switch has bad cache performance. But we simply aren't using RAM for anything in anything like GB-quantities. Physics sim is a few MB at most. All of the craft data is going to be in hundreds of kB. Maybe a few MB if we want to keep all the craft in the system loaded. We'll also need scratch space for loading textures and generating meshes for planets, but that's still in tens of MB. If you are good at unloading stuff you don't need after you're done with it, I'd be very surprised if you need more than 100MB to have everything running.

Almost the entire memory footprint of the game is going to be textures. There will probably be a considerable amount of mesh data, especially, when on the surface of a planet. All of that goes to graphics, and we've already established that we can chop the visual quality until it fits. We can get it down to XBox 360 era graphics if we have to, and that thing had 512MB of shared RAM. So RAM isn't a problem at all here. We should absolutely only be discussing CPU performance.

Edited December 16, 2020 by K^2

[runner78]

9 hours ago, K^2 said:

Can we make KSP2 on Switch if we throw AAA resources at it

KSP 2 is not an AAA Game, it's an Indiegame with limited resources. KSP doesn't have the amount of potential players like other AAA games, that wouldn't be profitable.

10 hours ago, K^2 said:

I can always look at generated code in debugger, but then what? When writing in C/C++, there is a lot more control over what gets generated. I have full control over memory layout, I can drop in streaming instructions, there are intrinsics that will prevent re-ordering, I can make sure more or fewer things are inlined, I can build jump tables to avoid unnecessary calls and returns or virtualization costs... C# gives me none of that. If I'm unhappy with code that got generated, tough luck.

What is the point if you spend 2 days at the end of a logic optimization for .05ms at the end, if you also save .04 with Burst with 2 hours? This effort is not worth it for "small" games, the budget is not enough. This also raises the question of how many potential players would there be on the switch? If you have to spend 50% more for a switch optimization for maybe 5% more players, who don't cover the 50%, then it just doesn't pay off.

9 hours ago, K^2 said:

Terrain can and probably is streamed almost directly.

I don't think it's that easy, planet terrain is generated on the fly depending on your position. You can certainly optimize a lot here and reduce the quality, but that is still the calculation time that you have to factor in.

And even if you split calculations over several frames, they take up computing time on the CPU and at some point it ends and calculations no longer keep pace. Not too bad for visual things, except that it's unsightly.
Fuel flow when flying, that's what you need when the engine uses up fuel, it can't be calculated so easily over several frames, unless you accept inaccuracies, in the worst case the engine fails for no reason. Whereby with smaller calculations that doesn't bring anything except overhead. Anyway, that was just an example of small things that have to be calculated.

10 hours ago, K^2 said:

Again, KSP is not a big game. It does NOT do anything that should be CPU intensive

Are you sure? KSP is a physics based game, and physics are CPU intensive. To avoid large rockets / planes, a modern PC can be pushed to its limits, and KSP2 wants to make even larger vehicles possible, so good optimization is needed for PCs. There is hardly any room left for a console whose performance even lags behind modern smartphones.

[K^2]

52 minutes ago, runner78 said:

KSP 2 is not an AAA Game, it's an Indiegame with limited resources. KSP doesn't have the amount of potential players like other AAA games, that wouldn't be profitable.

Yes. My very first post in this thread states that it wouldn't make sense to spend resources necessary to port to Switch, but it shouldn't be treated as "KSP2 can't run on Switch." These aren't the same statements.

This entire discussion hangs on a fiat that for whatever reason, resources to do this properly are available. So we aren't discussing financial limitations, but only the technical one.

Yes, it's an academic discussion. Yes, the port isn't going to happen. I'm 100% with you on that. I just don't like the statement that the problem is hardware. And I'm not saying this to put any sort of blame on development team. It just so happens that given the choice of engine and frameworks used, porting KSP2 to Switch would require greater resources than available to Intercept, all of which is a sensible financial decision.

56 minutes ago, runner78 said:

What is the point if you spend 2 days at the end of a logic optimization for .05ms at the end, if you also save .04 with Burst with 2 hours?

For component update loop, sure. But there are a few tasks, like the orbital sim, which require a lot of math. And these things can be hand-optimized to give you something like a 2:1 margin over optimizing compiler. As an anecdote, I was helping port an MMO to an XBox One. Optimizing vector and quaternion math for SIMD gave me a 20% reduction of the entire animation pass. Then I got another 10% by changing memory layout and improving cache coherence. This is over code that was already native and fairly well written. An orbital sim is even cleaner, as it doesn't have to jump around as it traverses skeleton and do logic for LoD and special bones with custom logic.

Yes, cases where it's worth to do hand optimized code are exceptional, but this is a very good candidate. And sure, this wouldn't be something I jump to immediately. I'd start by optimizing the algorithm and seeing how well it performs as is. Then I'd try running it with built in jobs queue on another core. Then I'd see if burst gets me what I need. And if I'm still unhappy with the amount of debris the sim can support before starting to lose frames, then I would go to hand-crafted code.

But the point is, we do have that headroom here. If there are resources and time to do the port proper, this is the absolute limit to which we can push things, and 1,000 pieces of debris at 5ms per frame is what I'm comfortable promising before actually starting work on it.

And hey, maybe it's possible to spread component update over frames enough that you're happy taking up 15ms per frame. Or maybe a few hundred pieces of debris is adequate. And then you don't need to go to all that trouble. Still good to know how far it can be pushed.

1 hour ago, runner78 said:

I don't think it's that easy, planet terrain is generated on the fly depending on your position. You can certainly optimize a lot here and reduce the quality, but that is still the calculation time that you have to factor in.

And even if you split calculations over several frames, they take up computing time on the CPU and at some point it ends and calculations no longer keep pace.

Technically, that last bit is already a problem in KSP. I'm not sure on all of the implementation details, but the way collision is handled is that several terrain tiles are generated around the player and are updated "every once in a while". It is possible to move fast enough along terrain to where you outrun the physics update and fall through terrain.

That said, we have a bit more flexibility with render mesh. You don't technically have to even do the mesh update on the CPU. It can all be delegated to GPU. The way you do that is by having a fixed terrain mesh always centered on player. The vertex shader for that mesh will do a lookup into the texture and adjust verts. You do need to make sure that the textures are streamed in, but there's hardware to handle that.

The other way is to actually build out the mesh, but even that's not nearly all that expensive. You do need to march over every vertex and adjust its height, but you're still dealing with tiles that only have high resolution near the player. And this is one of the cases where having unified memory plays in your favor, as locking and unlocking a vertex buffer shouldn't be nearly as expensive as it is on PC.

Either way, this isn't even on the radar as difficult task, and fidelity can be sacrificed here if necessary with no detriment to gameplay.

1 hour ago, runner78 said:

Are you sure? KSP is a physics based game, and physics are CPU intensive. To avoid large rockets / planes, a modern PC can be pushed to its limits, and KSP2 wants to make even larger vehicles possible, so good optimization is needed for PCs. There is hardly any room left for a console whose performance even lags behind modern smartphones.

Yes, I'm sure. The sort of games I'm working on have thousands of objects colliding with each other just for the FX. These are convex hull collisions with contact point constraints. A rocket composed of a few hundred parts with a few hundred welds shouldn't even register as CPU load. Unity + PhysX is just a horrible combination for a rocket-building game.

With DOTS/ECS and Havok you can get the sort of physics performance you get with modern games. Since I don't expect KSP2 to be making use of it, if you were to get an eccentric philanthropist to give you tens of millions of dollars needed to port of KSP2 to Switch, this is how you get all of the KSP2 physics onto the system and still get better performance than PS4 Pro and XB1X do. And there's headroom left even there. A custom physics engine can do even better, and one that can handle KSP2 doesn't need to be nearly as complex as Havok is. Especially if you ride on top of Havok's collision detection, which is completely fine, and just write a custom solver.

[runner78]

2 hours ago, K^2 said:

With DOTS/ECS and Havok you can get the sort of physics performance you get with modern games. Since I don't expect KSP2 to be making use of it,

I have a little hope after the delays, ECS has time to grow and KSP2 can use it for some parts. There are already games in development that use ECS, so it's not entirely out of the question.

We don't know at the moment which gameplay elements KSP 2 will have, but as I said, I think all of this together is too much for the Switch, without having to change or remove gameplay elements.

[Guest]

6 hours ago, runner78 said:

KSP 2 is not an AAA Game, it's an Indiegame with limited resources.

It's not an indie game either.

It's a medium sized game from an established studio with a slightly higher than usual budget.

I know it's nitpicky, but the game is definitely not an indie game.

 

[Mikenike]

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.  

Not a chance in the world. You will have fried CPU for breakfast.

7 hours ago, runner78 said:

KSP 2 is not an AAA Game, it's an Indiegame with limited resources. KSP doesn't have the amount of potential players like other AAA games, that wouldn't be profitable.

Your wrong, its a AA game. It IS DEFINITELY NOT AN INDIE game. And it never will be. It doesn't your right, but it does have an amazing following. But it doesn't have a loyal group that plays switch. It was hard enough to get them to port the game to the consoles.

[Mikenike]

On 12/16/2020 at 5:07 AM, runner78 said:

AAA Games have entire teams for that, where only the optimization team probably has more programmers than the entire KSP programmer team.  KSP2 is still an indie Game.

You cannot compare games like Asobo's MSFS2020, or 343I's Halo, or Activision's COD, or EA's Battlefields, to the likes of KSP2 and 1. That's an unrealistic difference. It is a much smaller game. And it is not an Indie, an indie is made by a small dev team. KSP's dev team actually has a decent size office and it is a large enough company not to be considered indie. And the reason why AAA games have so many more programmers is because they have the sales and the game brand to justify those numbers.

[runner78]

4 hours ago, Master39 said:

It's not an indie game either.

It's a medium sized game from an established studio with a slightly higher than usual budget.

I don't know the exact number but according to LinkedIn, Intercept Games has 10-50 employees and 18 profiles exist. It's still indie for me.

[Guest]

18 minutes ago, runner78 said:

I don't know the exact number but according to LinkedIn, Intercept Games has 10-50 employees and 18 profiles exist. It's still indie for me.

Indie means indipendent, not small, there's a big difference in the resources available to the development team.

It's a small studio, like every studio Private Division works with, but not an indipendent one.

[runner78]

4 minutes ago, Master39 said:

Indie means indipendent, not small, there's a big difference in the resources available to the development team.

According to this definition, games like CyberPunk 2077 should also be considered indie games. Developer and publisher is the same, i.e. independent.

[Guest]

2 minutes ago, runner78 said:

According to this definition, games like CyberPunk 2077 should also be considered indie games. Developer and publisher is the same, i.e. independent.

While technically CDPR is an indipendent company, they self publish their games after all, it's not truly an "indie" studio because of the size of their last 2 projects.

CDPR booming from a small developer to a big one and investors wanting a return on that is one of the many problems that Cyberpunk's development process had.

Intercept is not an indie studio in the same way BGS Austin or one of 9 "Rockstar Studios" aren't, they're part of a bigger whole (usually a publishing label) that give the developers access to resources they couldn't have access to as an indipendent studio.

Being able to stay afloat while not selling preorders 2 years earlier that release is one example of one difference between CDPR and Intercept. 

[shdwlrd]

12 minutes ago, runner78 said:

According to this definition, games like CyberPunk 2077 should also be considered indie games. Developer and publisher is the same, i.e. independent.

Yes, CDP is an independent as they develop, publish, and distribute their own games. A very large one, but an independent none the less. But what does that have to do with making KSP2 run on the Switch?