Mobile Version of KSP

[Mikenike]

On 11/29/2017 at 10:05 AM, Helmetman said:

I can see it draining my battery faster then it takes me to let the dog out since KSP makes fried cpu and ram for breakfast. Maybe I can bake a egg on my glass Galaxy S6 cover while it's running hot.

 

I want scrambled eggs, side order of hashbrowns and some sausage please. But yes, KSP make fried RAM and CPU for breakfast. It makes fried graphics cards for lunch, and fried motherboards and fans at night

[kspnerd122]

Ok, so actually, here is the thing, the main problem is controls you fix that and add hard limits to what can be built(up to 200 parts, you could always dock in orbit, and you would need to dump more than half that to get there, because Infinite fuel would not exist.) this could fix the problems with lag and CPU usage, also, drop load range to 250 meters, big enough to build a decent ship, but small enough that during docking, lag would happen less. also if you want other planets, just add duna, eve, and jool, nobody visits dres and eeloo and moho also, no asteroids the more of them you track the more RAM you use.

[catloaf]

On 10/2/2020 at 5:05 AM, kspnerd122 said:

Ok, so actually, here is the thing, the main problem is controls you fix that and add hard limits to what can be built(up to 200 parts, you could always dock in orbit, and you would need to dump more than half that to get there, because Infinite fuel would not exist.) this could fix the problems with lag and CPU usage, also, drop load range to 250 meters, big enough to build a decent ship, but small enough that during docking, lag would happen less. also if you want other planets, just add duna, eve, and jool, nobody visits dres and eeloo and moho also, no asteroids the more of them you track the more RAM you use.

No, the main issue with ksp is just bad programming. I think a total rewrite would be the best approach, due to performance and the fact that smartphones and tablets run on arm processors. Although even a port/x86 emulation would still be fine on the most modern phones, considering that ksp can be run on x86 potatoes, the most recent arm processors would be more than capable. A great way to eliminate lag though, would be to make the joints between parts invincible, which would eliminate part count lag, and is far better than watering down the physics in other areas.  Another fix they could add is to not load every single asset at the beginning of the game, instead load a low res version, and load the full res version when its actually needed, to decrease load times upon startup.

 

[Deddly]

1 hour ago, catloaf said:

No, the main issue with ksp is just bad programming. 

I see people say this from time to time, but how do we know this? Have we seen the code? This claim seems to conflict with:

Quote

ksp can be run on x86 potatoes

 

[catloaf]

14 minutes ago, Deddly said:

I see people say this from time to time, but how do we know this? Have we seen the code? This claim seems to conflict with:

 

Just because it can run doesn't mean it runs well. What's really coded poorly, at least from the users prospective, is the way ships with large part counts are handled. The game runs well on anything with low part counts but as the part count exceeds a certain threshold, the requirements for 60 fps increase exponentially. The other reason why I think the game was badly coded is the fact that simple rockets, which does most of what ksp does in terms of physics, performs stupidly well. The third reason is the games development process, where the game lasted way longer and was devolped way longer than anyone expected, meaning code not optimized for a game this big is being used in the physics engine.

Edited October 3, 2020 by catloaf

[linuxgurugamer]

50 minutes ago, catloaf said:

Just because it can run doesn't mean it runs well. What's really coded poorly, at least from the users prospective, is the way ships with large part counts are handled. The game runs well on anything with low part counts but as the part count exceeds a certain threshold, the requirements for 60 fps increase exponentially. The other reason why I think the game was badly coded is the fact that simple rockets, which does most of what ksp does in terms of physics, performs stupidly well. The third reason is the games development process, where the game lasted way longer and was devolped way longer than anyone expected, meaning code not optimized for a game this big is being used in the physics engine.

Your third point directly contridicts your first point.  In fact, the fact that the development process is still going on can be considered a strong po8nt in its favor.

Simple Rockets 2 doesn’t do the same kind of physics simulation/calculations that KSP does, so it is able to run faster.

Finally, KSP 2 is being written with the full knowledge of what did and what did not work well in KSP..  We should (and are being told) to expect huge improvements when it comes out.

Making a statement without direct knowledge is nothing more than pure speculation.  While not having direct access to the code, writing and maintaining mods _does_ give me more knowledge to make educated speculation.  I can say that it appears from what I am allowed to see that it is an old codebase, with a number of non-optimal decisions made throughout its development.  I have also seen a large number of those non-optimal decisions have been fixed over the years, which has led to large improvements in performance and reliability over time.

[Souptime]

There simplerockets2 and Spaceflight Simulator, available on IOS and android

There's also an upcoming project by astrelix space on youtube: 

The game is called ellipse and combines SFS and KSP

[catloaf]

3 hours ago, linuxgurugamer said:

 

Simple Rockets 2 doesn’t do the same kind of physics simulation/calculations that KSP does, so it is able to run faster.

 

Can you elaborate on how they are different, because I have not noticed very much difference. I imagine some corners have been cut  to increase performance, but I have not noticed any major differences.

[AlamoVampire]

Firstly that video reminds me a ton of early early ksp (pre 0.21). Ok that said, I may be wrong but, I think a lot of design limitations were based on the fact the game is on the unity engine (engine??) and it is/was suboptimal for a game like this. I admit a fair chance I am misremembering this so (sets a bowl of salt out) take it with a grain of salt. 
 

234710032020

[Incarnation of Chaos]

16 minutes ago, AlamoVampire said:

Firstly that video reminds me a ton of early early ksp (pre 0.21). Ok that said, I may be wrong but, I think a lot of design limitations were based on the fact the game is on the unity engine (engine??) and it is/was suboptimal for a game like this. I admit a fair chance I am misremembering this so (sets a bowl of salt out) take it with a grain of salt. 
 

234710032020

KSP2 is going to be on Unity, and it doesn't seem like they're too worried. But the real answer is no game engine is really optimal for a game like KSP, if you wanted the best possible performance you'd need to make your own bespoke engine talior-made for it.

7 hours ago, catloaf said:

Can you elaborate on how they are different, because I have not noticed very much difference. I imagine some corners have been cut  to increase performance, but I have not noticed any major differences.

SR2 doesn't have Rigid-Body Physics for one, so flexible joints aren't a thing (So failures due to aerodynamic stress also arent a thing, and i don't even know if it has aero modeling). The Solar System is both smaller in scale, and the individual planets are also much smaller than KSP's (Which KSPs are 1/10th the size of IRL). Also i'm pretty sure the Physics isn't even Patched Conics, but an even rougher approximation. But that i could be very wrong on, so don't hold me to it.

Basically SR2 is what happens when you try to port KSP to mobile; you realize Rigid-Body physics between parts will absolutely crush the pitiful ARM CPU's on phones and cut it. You also realize you don't have much RAM or GPU power, and thus decrease the need for both by making the system as small as possible. You also implement all parts as Procedural, because loading 30+ parts would be pure agony on the garbage NAND flash in most phones.

It does some things well for sure, but there's absolutely nothing to say a mobile port of KSP would look any different. I'd say SR2 has carved out a deserved niche by that property alone.

[AlamoVampire]

@Incarnation of Chaos oh? Well thats new to me. Would have thought theyd use a different engine. Admittedly I know next to nothing on programming, but Id imagine that perhaps which ever version of unity they are using is (bad pun) light years ahead of where it was when ksp1 first began?

014510042030

[Incarnation of Chaos]

2 hours ago, AlamoVampire said:

@Incarnation of Chaos oh? Well thats new to me. Would have thought theyd use a different engine. Admittedly I know next to nothing on programming, but Id imagine that perhaps which ever version of unity they are using is (bad pun) light years ahead of where it was when ksp1 first began?

014510042030

Nah it's been confirmed to be on Unity since the beginning, but yes it's a much, much newer version than the one KSP was developed on. And mind you that also means DX11 at a minimum will be standard; which is likely a big part of the graphical improvements we've seen. Add getting rid of the dependencies on those ancient Unity versions KSP started on, on top of the clean code they're writing is going to improve performance by itself. Then you get into the culling system for ship parts they're developing, and rewriting the module code along with much of how the physics is handled (Just from a structural standpoint; not anything fancy like multi-core or GPU acceleration. Rigid-body basically prevents that for vessel parts).

All of that will likely be the bulk of the performance improvements, and it's mostly just going from naive/brute-force methods to more complex but efficient ways of doing the same thing (Paradoxical; i know. Welcome to Computer Science :P).

As a result; KSP2 might have a very, very slight chance of getting a mobile port. I still don't think getting it to run acceptably well on mobile would be possible even with all of the work Intercept/Star.Theory has done, but i could at least see it being barely possible. OG KSP doesn't even have a chance.

[AlamoVampire]

@Incarnation of Chaos ah, well, in fairness, ive not really followed the development of KSP2 all that closely, so, its likely that things such as KSP2 being on unity have slipped my notice. One thing I hope, and I mentioned this in the hopes and wishes thread is that KSP2 has reentry plasma trails. The code has always existed in KSP but for performance reasons way back when <as far as I can recall at least> was never turned on. Even now 7 years since I came to KSP its never been turned on, but as they say, there is a mod for that lol. But, yea, I hope for great things for KSP2. Will it have a mobile app version? I honestly do not know and cant even begin to speculate. 

 

051610042020

[Deddly]

2 hours ago, Incarnation of Chaos said:

OG KSP doesn't even have a chance.

I will just say that I had KSP running on a very old HP Windows tablet. Turned the graphics down low, especially anti-aliasing, and performance was better than expected. It was actually playable.

Playing on a touchscreen, though, was ridiculously bad, as expected. 

[Lewie]

Has anybody realized that even if ksp were to be ported to mobile, it would just be enhanced edition all over again! No mods, lots or bugs, crappy performance and something that everyone will move on from within months.

[linuxgurugamer]

18 hours ago, catloaf said:

Can you elaborate on how they are different, because I have not noticed very much difference. I imagine some corners have been cut  to increase performance, but I have not noticed any major differences.

Not really, as  don't know anything about SimpleRockets.  I would guess that it doesn't do individual calculations for each part, among other things

[kerbiloid]

Someone should just leave this here...
 

Spoiler

***

System requirements:
RAM 48k
VideoRAM 6k
Screen: 16 colors 256x192

***

 

What are the system requirements for First Encounters?

• 386DX/33.
• 4 MB of RAM.
• Hard disk with about 5MB free space.
• 500KB free base memory (patch says 560KB !)
• DOS 5.0 or higher.
• Standard VGA graphics.
• CD-ROM drive (if you have the CD version)

***

 

System Requirements

• OS: Windows XP/Vista/7/8.
• Processor: 1.8 GHz.
• Memory: 1 GB RAM.
• Graphics: 3D graphics card compatible with DirectX 7 (DirectX 9 recommended)
• Storage: 406 MB available space.
• Additional Notes: The Windows version of STAR WARS: TIE Fighter (1998) requires a controller or joystick.

***

10. NOKIA 1.3

SPECIFICATIONS

Weight: 155g

Dimensions: 147.3 x 71.2 x 9.4 mm

OS: Android 10

Screen size: 5.71-inch

Resolution: 720 x 1,560 pixels

CPU: Qualcomm QM215

RAM: 1GB

Storage: 16GB

Battery: 3,000mAh

Rear camera: 8MP

Front camera: 5MP

 

[Bej Kerman]

3 minutes ago, kerbiloid said:

Someone should just leave this here...
 

  Reveal hidden contents

We're not talking about rendering a couple polygons. We're talking about several thousands of parts reacting to one another. But whatever tickles your nostalgia ig.

[kerbiloid]

Just now, Bej Kerman said:

We're talking about several thousands of parts reacting to one another.

"Thousands" is a bit optimistic. 300 sounds more realistically.

[Bej Kerman]

Just now, kerbiloid said:

1 minute ago, Bej Kerman said:

We're talking about several thousands of parts reacting to one another.

"Thousands" is a bit optimistic. 300 sounds more realistically.

You don't have KSP if you can't simulate thousands of parts.

[razark]

On 10/3/2020 at 11:44 AM, Deddly said:

I see people say this from time to time, but how do we know this? Have we seen the code?

I think the best indicator of how badly KSP is implemented is the high number of clones/KSP-alikes/direct competitors it has spawned that handled everything so much better than KSP itself.

[kerbiloid]

4 hours ago, razark said:

I think the best indicator of how badly KSP is implemented is the high number of clones/KSP-alikes/direct competitors it has spawned that handled everything so much better than KSP itself.

Unlikely an indicator due to very specific and limited target audience, already having KSP.

[Incarnation of Chaos]

20 hours ago, Deddly said:

I will just say that I had KSP running on a very old HP Windows tablet. Turned the graphics down low, especially anti-aliasing, and performance was better than expected. It was actually playable.

Playing on a touchscreen, though, was ridiculously bad, as expected. 

Which was still x86.....Mobile Phones use ARM, which is the main point of contention here.

[Deddly]

4 hours ago, Incarnation of Chaos said:

Which was still x86.....Mobile Phones use ARM, which is the main point of contention here.

Modern ARM processors are much more powerful than that x86 tablet was.

Edited October 5, 2020 by Deddly
spelling

[Incarnation of Chaos]

3 minutes ago, Deddly said:

Modern ARM processors are much more powerful than that 8x6 tablet was.

Ha! 

Only if you believe the marketing hype and intentionally manipulated benchmarks. As general computing devices they're only really useful when they can be used in parallel workloads or whatever work is using fixed function hardware (like MPEG decoding). 

KSP is neither.

But their low wattage, thermal limits imposed by passive cooling in phones and the lack of some of the more important instructions for running games means that even if they were you'd have to have a device that had a 45 W power limit for the CPU and decent cooling.... and that's when you should just grab a x86 lappy and have fun instead.

Have you ever noticed that all the mobile games ported over from console/desktop are basically esports titles? That they're all graphically bound? Not CPU?

ARM SOC have great graphics hardware, and their intergration of wireless modems and other features that normally would require a separate chip is nothing to scoff at.

But their raw CPU grunt is still leagues behind x86, and always will be. Because ARM isn't built for the transistor density needed, but instead to explicitly reduce it. It isn't built for higher frequencies, but instead leveraging designs like BIG.little and multithreading for speed instead. 

It's a tool fit for a very specific purpose, and the drive recently to hammer it everywhere but where it shouldn't is going to likely end badly for companies that decide to go ahead despite it