Jump to content

KSP2, same old same old


Jimbodiah

Recommended Posts

After seeing this video and the same problems with sloppy joints as KSP1, there is no way in h€ll I am buying this game. I've seen two videos now of KSP2 pre-alpha gameplay and the fps were absolutely horrible with the same stutter and low fps as we already have.

If they are not going to learn a single thing from everything wrong with the current KSP, then what is the point of making a new version?

 

Spoiler

 

 

Edited by Jimbodiah
Link to comment
Share on other sites

I have to say, that pre alpha footage plays better or the same as my old AMD APU system did. I was lucky to be able to keep above 30fps when I was doing anything when a planet was in view. 

Even with my newer system, I still get stuttering when explosions are in view or when transitioning from the atmosphere to orbit and vice versa. (Damned AMD single thread performance.) 

My point is this, if that is pre alpha footage and it plays as well as KSP1, I would love to see how they get it tuned when they get past the alpha stage and get to beta releases.

Link to comment
Share on other sites

FPS in pre-alpha is likely to be fixable.  If nothing else, removing the 'debug' flag from their compile will probably help.  ;)  But seriously - while you do want to make sure your code design isn't totally bad, optimizing is really one of the last steps in coding.  You work on it once you know what the code looks like, where the chokepoints are, and what's going to be an actual issue when running the game.  If they're going for an early 2020 release, I could see them *starting* optimizing now.

Link to comment
Share on other sites

It's way too early to be judging the game based on pre-alpha footage.  Even within the trailer, there are substantial changes in performance that could possibly indicate that they were taken at different stages of development.  Off the top of my head, if you were to ask me what would be the more visually and physically demanding scene between the initial launch gameplay and the Jool station, I'd say Jool, an yet it's significantly more stable and relatively smooth.

As for how they are handling parts physics, I've said before that I'm fine with there still being some joint flexibility, to a degree.  Mostly I think it's something you should be able to configure and build around to eliminate.  I think it's a bit strange that they've shown a lot of that initial explosion footage, but I think they see that kind of spectacle as appealing to new players (and I would probably agree with that.)  But there's no way I can see that level of physics rendering working with interstellar levels of acceleration and parts count, so there has to be some kind of system in place that at least differentiates between the two circumstances.  At the very least, I'm sure there will be struts, but I have a feeling there's more to come.

At the end of the day, it's your money, so you can do whatever you want, but no one's forcing you to pay for it right now either.  Why bother getting up in arms about it when there's still so much we don't know?

Link to comment
Share on other sites

This is a build specifically for Gamescom. We have no idea how far the development has reached so far.
It could be that rockets are more stable now, but the demo build was already done. We don't know, but given the developers themselves are experienced in how KSP 1 feels I'm sure they're doing their best to make sure rockets feel a lot better in KSP 2.

They probably lost a lot of kerbals payloads because of joint flexing as well.

Link to comment
Share on other sites

This game should not be CPU dependent and have the GPU just sit idle. The wobbly joints mean the game will have the same detrimental effects like ships/stations shaking apart for no reason (especially when loading in), and the stuttering plus low fps means we will again need the likes of MemGraph to alleviate bad programming. I still don't see the point of making a new game when you make the same mistakes as Squad has done for years now. No doubt they will still use endless text files to store all game+craft data in...

This game should be running 60fps+ with ease, 100fps+ unless you have huge part counts (which is also a sign you're doing it wrong IMO) , so I don't see why people are actually happy they are only getting 10-30fps, like it's something to be proud of and defend. We already have KSP 1 for potato gameplay.

Link to comment
Share on other sites

9 minutes ago, Jimbodiah said:

This game should not be CPU dependent and have the GPU just sit idle. The wobbly joints mean the game will have the same detrimental effects like ships/stations shaking apart for no reason (especially when loading in), and the stuttering plus low fps means we will again need the likes of MemGraph to alleviate bad programming. I still don't see the point of making a new game when you make the same mistakes as Squad has done for years now. No doubt they will still use endless text files to store all game+craft data in...

This game should be running 60fps+ with ease, 100fps+ unless you have huge part counts (which is also a sign you're doing it wrong IMO) , so I don't see why people are actually happy they are only getting 10-30fps, like it's something to be proud of and defend. We already have KSP 1 for potato gameplay.

why, whywhywhywhywhywhy,.... why

please elaborate.

Link to comment
Share on other sites

8 minutes ago, Jimbodiah said:

This game should be running 60fps+ with ease, 100fps+ unless you have huge part counts (which is also a sign you're doing it wrong IMO) , so I don't see why people are actually happy they are only getting 10-30fps, like it's something to be proud of and defend. We already have KSP 1 for potato gameplay.

I should be a millionaire, but I'm happy just being able to afford my mortgage payments.

"Should" and reality often greatly differ.

Link to comment
Share on other sites

13 minutes ago, Jimbodiah said:

This game should not be CPU dependent and have the GPU just sit idle. The wobbly joints mean the game will have the same detrimental effects like ships/stations shaking apart for no reason (especially when loading in), and the stuttering plus low fps means we will again need the likes of MemGraph to alleviate bad programming. I still don't see the point of making a new game when you make the same mistakes as Squad has done for years now. No doubt they will still use endless text files to store all game+craft data in...

This game should be running 60fps+ with ease, 100fps+ unless you have huge part counts (which is also a sign you're doing it wrong IMO) , so I don't see why people are actually happy they are only getting 10-30fps, like it's something to be proud of and defend. We already have KSP 1 for potato gameplay.

What is the point of posting to the forums if you are just going to ignore everyone?

To Reiterate: What we have seen is pre-alpha footage, and it's unlikely that any optimizations have taken place yet. The frame rate we see now is not representative of what they can achieve for the final release. 

Link to comment
Share on other sites

I tell you what, I was playing ksp since 0.9 or something. (okay playing is relative term, my pc was a piece of junk then) It used to stutter when there were 20 parts on the screen (and things were even worse when they changed the water shader and added the Mun). Did they fix it? Yes. Long time before official release.

So why are you making assumptions on something that is, as many said before, nowhere near being finished? Wait till it goes live, if it works like you're saying it does, well, spend your money on something else.

Link to comment
Share on other sites

I'm pretty sure the first noodle rocket had joint rigidity cranked allll the way down. 

From a programmer PoV I understand why they showed it -- to demonstrate that rigid-body physics are still in and work the same way as in KSP1.

From a marketing PoV it was really dumb to show it, bless their hearts.

Link to comment
Share on other sites

Well, if we had current version of KSP, or heck, even 1.31 version of KSP... without any lag... I would splurge 60$ so fast for it.
My average build sizes go from 350-550 parts for grand-tour ships or Jool-5 ships.  So say 1000 parts without losing any framerates from ships and I would be very happy

Optimization is the number one reason why I always drop my campaigns.  #2 being annoying and unexplainable kraken/sudden dissasemblies.
In one of the interviews, they said KSP2 would be so far better than current KSP for Optimization.

We shall see, but so far looking forward to it.

Link to comment
Share on other sites

12 hours ago, ModZero said:

...every time I see a post like this I am amazed anyone bothers with ever showing a game to the public.

Go look at the announcement thread.  Don't let one negative comment erase all the positive reaction you do receive.

Link to comment
Share on other sites

14 hours ago, Jimbodiah said:

This game should not be CPU dependent and have the GPU just sit idle. The wobbly joints mean the game will have the same detrimental effects like ships/stations shaking apart for no reason (especially when loading in), and the stuttering plus low fps means we will again need the likes of MemGraph to alleviate bad programming. I still don't see the point of making a new game when you make the same mistakes as Squad has done for years now. No doubt they will still use endless text files to store all game+craft data in...

This game should be running 60fps+ with ease, 100fps+ unless you have huge part counts (which is also a sign you're doing it wrong IMO) , so I don't see why people are actually happy they are only getting 10-30fps, like it's something to be proud of and defend. We already have KSP 1 for potato gameplay.

Excuse me what the heck. i swear every place needs a thonk emoji/emote...

AND YALL MISSING ONE THING in this entire video. Same-vessel interactions. The collision between the parts will help STOP massive wobbles since rather than phasing through unhindered and wobbling to dangerous levels, the reaction force will help stop and minimise wobbling.

 

 

Link to comment
Share on other sites

38 minutes ago, Xurkitree said:

AND YALL MISSING ONE THING in this entire video. Same-vessel interactions. The collision between the parts will help STOP massive wobbles since rather than phasing through unhindered and wobbling to dangerous levels, the reaction force will help stop and minimise wobbling.

 

 

And smash parts together and blow the hell out of the sky.

Link to comment
Share on other sites

24 minutes ago, Curveball Anders said:

Possibly do it proper XML, otherwise  I agree.

Honestly, the current JSON-alike (not quite real JSON, I know) is far easier to read and work with than XML.  I'd be nice if they used an actual standard (JSON, YAML, etc.), but XML would just add clutter.

Link to comment
Share on other sites

16 hours ago, Jimbodiah said:

This game should not be CPU dependent and have the GPU just sit idle.

In the recent German interview, Star Theory seemed to hint that some physics may be offloaded to the GPU (assuming compatibility).  Could have been a translation blip, not sure, but it looked promising.

It's way, way to early to start judging this game based on some in-development footage.  Be skeptical and wait for reviews of the release?  Sure - that's being cautious.  Stamping your feet over a title that's at least 6 months from release?  That's being childish.

Link to comment
Share on other sites

3 hours ago, DStaal said:

Honestly, the current JSON-alike (not quite real JSON, I know) is far easier to read and work with than XML.  I'd be nice if they used an actual standard (JSON, YAML, etc.), but XML would just add clutter.

 

2 hours ago, Brikoleur said:

Oh ye gods, let XML die already.

"Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable"

JSON (and HTML, and others) are subsets of XML.

They are XML with predefined schemes.

To say that XML is useless is to say that j.random alphabet is useless because it lacks context awareness and can be used to construct incomprehensible data.

But I agree, data saved by KSP2 should be in XML with a published scheme.

 

Link to comment
Share on other sites

Okay this is going off on a pretty big tangent, but... I've worked with XML-related stuff since 2001, full time. I would probably qualify as an XML expert in fact.

XML is a verbose, difficult-to-read, incoherent mess of a way of representing data, and XML Schema is so bad it's not even funny. It gets worse when combining different schemas or trying to do anything at all complex. It's also extremely unwieldy to deal with in code: the DOM interface is really complex and verbose and you need a huge mess of accessors to access it, and if you use SAX parsing you're limited to dealing with a stream. Simply put, as a way of representing structured data, XML sucks.

There are really good reasons why modern software has shifted away from it to JSON, YAML and other more lightweight formats. They're just plain better for all but niche applications. XML is only used nowadays with legacy stuff, lots of systems that have SOAP interfaces for example and aren't going anywhere any time soon. But anyone designing a new system from scratch and choosing to represent the data as XML needs a firm kick in the pants.

See also: http://harmful.cat-v.org/software/xml/soap/simple -- it's about SOAP but the same applies to just about any XML technology you might care to name.

Also, JSON has nothing to do with XML, it's a completely different way of representing data -- it's not even possible to unambiguously convert between JSON and XML representations of the same data without making extraneous assumptions. HTML is not "a subset of" XML, whatever that would even mean. HTML and XML are both SGML markup languages, XHTML was an XML markup language though but that's largely fallen out of use because it's pointless.

Edited by Guest
Link to comment
Share on other sites

×
×
  • Create New...