Jump to content

Incarnation of Chaos

  • Posts

  • Joined

  • Last visited

Everything posted by Incarnation of Chaos

  1. Have actually coded quite a bit myself, it's one of the reasons I'm not confident they'll improve performance significantly. The performance we're seeing almost looks like a debugger is hooked up (can't be the case because it's a retail exe, but that's the example that comes to mind) We were promised no early access and a full game on release, and we got early access and only sandbox mode that's a 20 FPS slideshow that needs more hardware than games that look 10x better to do it. I do understand that milliseconds and cycles matter, even a loop that's running a few ms slow can add up to massive performance issues depending on how often it's being called. The fact that the physics is still causing lag is also a pretty grave concern for me, because either they don't have their physics LOD enabled or weren't able to get it working. That's a low-level, tightly integrated system that likely cannot just be "patched in" due to the dependencies of parts/colliders/meshes etc. So if that's not working, one of the biggest things that KSP2 was going to do to optimize just went straight out the window. And if they have all this performance still on the table like everyone seems to be thinking, why ship? Game was already delayed three years, I seriously can't fathom 2K coming down and being like "yeah bruh you gotta send it now" after 3 years of delays lol None of it makes sense, and none of it bodes well for the future of the game. But all I see is people who want to believe it'll all work out without any hard evidence, praise and ignoring the fact that this is another broken promise on top of the pile. That's the crux of the issue, the hardware requirements are a symptom of a much larger issue than just "muh fps". Could they prove me wrong in time? Maybe, but they're certainly on a losing streak as of late.
  2. My post said explicitly I wasn't planning on buying it, so not sure why you mentioned that. Second you're absolutely right that in most cases you can't reliably extrapolate past experiences from different companies to each other. Game performance though, that's a different one. In the best case it remains the same from launch to final version, in most cases it regresses as more features are added on in each following version. Is it possible that they completely botched their multithreading implementation and the performance would improve once resolved? Sure! Could they have completely flubbed the setup of their render pipeline? 100% But all of these are issues that don't need a slew of paid beta testers for them to see or resolve, they'd know already.
  3. How many times have I heard that same thing? Performance will improve with time. You know how many times I've seen that actually occur? Maybe once, twice in my entire gaming experience. You know what else they said? We'd get a complete game and not this early access hackjob. I've been willing to give intercept immense slack, but this is just downright shameful. Forgive me for not caring about what they say about their plans at this point, because they have proven time and time again they won't hold themselves to it
  4. So after three years they decided to go EA, and somehow managed to make this game suck down a RX 6800 for medium at 1080p. Full disclosure, I meet the specs. Ryzen 9 3950X and a 6800 with 32GB of RAM. That doesn't make me any less surprised at the sheer amount of compute power that Intercept has managed to make KSP2 use for graphics that honestly hardly look better than a 10 year old game. I know I don't have to buy it in EA (wasn't planning on it), but I seriously doubt they're going to improve performance significantly over the years. KSP 1 improvement was from moving to DX11 from DX9 in the later versions, KSP2 really has nowhere similar to go from here. If nothing else, I hope we get a good postmortem of KSP2s development. Until then, discuss below. *Activates flame shield*
  5. Go write a basic compute shader for physics and say all of this again. GPU is a different beast programming wise, and it's a very different model and syntax than conventional programming. That's not to say it's impossible, but that you need to use a different set of math and a different syntax for programming instructions for a GPU That isn't to mention the big elephant in the room, which is getting this all to work cross platform. CUDA won't work on AMD, so you really only have openGL / vulkan as an option. And then you have to compile your compute shaders at runtime for every individual machine deal with some nasty parallization stuff so you don't run into deadlock or infinite loops. So if you have two options, one being to optimize the crap out of what you know and get great performance or to attempt writing a entire physics system from scratch just to make use of the GPU that you're entirely unfamiliar with... the first makes much more sense. Can it be done? Yes Was it financially practical for the ksp2 devs? Apparently not vs just optimizing what they had.
  6. Where wheels can't go, tracks will laugh at the terrain. The main reasons you might want legs are completely demolished once you realize tanks routinely scale 70 degree inclines (albeit slowly). Also at this hypothetical crossover point, consider the flexion you are having to impart on the legs to obtain the same speeds. How that affects the joints, and what reinforcement is going to be necessary to prevent the entire thing from shaking/ossilating itself apart. This adds weight, and now your top speed is lower. Also any failure of a Walker's legs is catastrophic, and easily lethal for the crew. A tank throwing a track still isn't a good day, but you're alive and stationary at least. Just some food for thought If ksp2 has robotics, I think walkers will be easy to create. I just want tracks in stock, since using wheels never made too much sense for me personally
  7. I wouldn't be surprised if they were all in a folder somewhere in the ksp2 install itself, and you could just copy them wherever you wanted. Only potential hurdle would be if they're not in a easily used format, but I'm sure the community would roll a tool to convert them to MP4 in time.
  8. None really beyond the normal pain of keeping track of two separate computers across the world and synchronizing things between them. But all of this would've already been solved for the PC multiplayer, so there's nothing unique about console cross play besides getting Sony and Microsoft's blessing to allow them on their networks.
  9. darthgently got it 100% correct The degree of mod support KSP2 gets on consoles is entirely up to the console makers themselves, not Intercept/Take 2 If they haven't been in negotiations from day one for mods on console, it's not happening.
  10. This is a fantastic way to create null pointer errors, overlapping colliders that cause unexpected behavior and just generally cause instability. Voxel would absolutely destroy a game the size of KSP, since for each point you have to be constantly updating the other three. Basically there's a reason SE is much smaller than KSP. They could have premade, premeshed cave models that they clip into the terrain, but that's about it.
  11. They already had playable builds by then, even if they weren't stable or entirely representative of the current game physics is something that you implement from the beginning. I seriously doubt they have any additional physics optimizations beyond their physics lod, otherwise we'd have a dev blog or three about them. But that's still huge, since their implementation scales poorly with the number of elements. Being able to treat 300 fuel tanks as one for most of the crafts life is still huge. Note my explanation isn't perfect and I'm sure I got some elements wrong, but I'm glad I could help.
  12. KSPs implementation of it requires that the next calculation have a value available from the previous one. So essentially you can think of it like trying to solve a system of equations with two parallel threads. If the first equation is "2x-4=256" (idk if this even is solvable, just making something for an example) And the second one is "X-3y= 64" then you cannot solve the second without first having the first to use as input. So if you spawn two threads, you end up with either deadlock (second thread somehow executed first, cannot solve and just stops the entire system until you hard shutdown) Or absolute gibberish like that somehow equaling negative 3 or 0. You can use locks, semaphores and so on to force the computer to wait until the first one is solved, but in this specific case it would actually be slower than just using one thread. So all of this to say basically I mispoke, there are ways to do multithreded rigid body simulations. But the way KSP and KSP2 have implemented their specific rigid body solver is not able to be threaded. And it never will be, since changing this literally means the entire game, all the objects,parts and potentially even the planets have to change with that. So they're over 2-3 years in development, and changing this now would likely double that at least. And quite likely much more, because debugging multithreded software is one of the most f u n experiences a programmer can have. Insidious, seemingly random bugs just because your code executed a function just a tiny bit early that's also incredibly hard to replicate reliably. It honestly is an art lol But anyway That's what I get for talking in general statements I suppose.
  13. Yeah KSPs craft physics is way simpler than that lol In theory you could use a particle system to represent the joints, and that's parallizable. But that's not happening at this point in development, so they have to make sure physics lod works well.
  14. Maybe how it's traditionally depicted is far fetched, but making a dome of plasma wouldn't be too far from possible. It would require massive amounts of power to maintain it, but you could vary the diameter and thickness of the field by just adjusting power and the quantity of gasses used. Hard part would be not cooking everyone inside or blinding them.
  15. Read their development blogs in full, they're still using rigid-body physics for craft. That means no multithreading, full stop. They will work around this with their "physics lod" which will treat large collections of parts as a single entity if certain conditions are met. That alone will do wonders for performance. The original Xbox and PS4, and even the " enhanced" versions will never close the gap, they're using kavari APU with absolutely abysmal single thread performance. Even compared to the first i7 CPU you're looking at a 50% IPC deficit, and compared to Ryzen 3000 and modern Intel CPU it's over 100% PS5 and Series X have a Ryzen 3000 CPU, so they will run KSP 2 just fine. Everything else is going to be painful even with their physics lod
  16. I wouldn't pay a single cent for that, Jesus people there's literally thousands of other games you can play in the period while you're waiting for ksp2. Hell you can even take up a new hobby, I rather enjoy lifting weights nowadays and I started over a year ago. The entire reason KSP 2 exists is that there's so many things you just can't patch in after the fact. Asking them to repeat the same mistakes just because you're impatient is absurdity of the highest order.
  17. Because methalox won't be practical for even the "shortest" interstellar transfer. And I'm going to clarify what I mean by practical here. Yes, in theory you could loft enough methalox into orbit to complete a transfer to another star. Especially when you have a minmus/mun colony, but the sheer quantity of tankage would make the craft fragile under acceleration, and frame rates would likely be measured in minutes per frame... And by the end you still have the biggest issue, which is turning the whole thing around and cancelling enough velocity to capture at the other star. Now most of these issues can be solved by clever staging, and the final craft that reaches the destination very well could be over 1/32 the size of the original. But that's a significant amount of time, money and resources you used both IRL and in game to achieve the same result using a much smaller and more manageable Orion or more advanced craft would've accomplished in a shorter time. As for the rest? Energy density is king when you want to optimize the amount of mass per volume of fuel you have to carry. If I want to make a small, compact lander. There's very little that beats RP-1 and LOX, but as mentioned above I might not be able to find them at my destination (let's say jool). I know I'll find plenty of hydrogen and oxygen at laythe in the form of water, so hydrolox for my lander might be preferred despite the bulky nature. Duna I know I'll find plenty of CO2 to make methane though, so methalox is actually viable the whole way.
  18. Didn't these spew the highly radioactive fragments of the core alongside their exhaust, require a reactor pile closer to submarine levels of enrichment (20-40% U235) and a massive lead bulkhead to separate the crew from the active reactor? Don't get me wrong, I've always loved the idea of nuclear thermal turbojets/fans/ramjets. And Kerbals don't know fear nor radiation, but I've never seen any really good proposals for alternative designs.
  19. Because mobile sucks Play a game at 24 fps, then 60. And no, I don't just see it because I want to. I literally have gone back to 30 and 60 fps, and the difference is incredible. Everything is slower, animations chug, input lag is oppressive. Again, you can read about this all day but until you actually play with higher refresh rates you won't understand what I'm saying in the slightest. Also the refresh rates of TV have far more to do with the amount of data you can push over a given frequency than anything else. 50 hz is less information, so less wattage at the station for the same transmission.
  20. [Moderator note: This discussion was originally split from another topic here, which was about KSP 2 and resources consumption on the PC. This resulted in a lengthy and interesting discussion that didn't really pertain to the original topic, so we've split it off into a thread of its own, here.] Have you ever played at 144fps? 95 fps? It's literally night and day difference between 60 fps. Our senses are a limit, but it's not at 60fps or even 240 lel
  21. What even is this point lel It's not about the difference between 60 and 50, it's about the difference between 60 and 95, 60 and 144 etc. Their games are going to be around for years, and hardware becomes easily able to run them well above 60 fps even on the low-end. The consoles even support it now, and high refresh TVs are increasingly entering the budget space.
  22. Let's not turn this into an OT bethesda bad thread, but suffice to say that if they switched engines the only reason it wouldn't be moddable is they didn't put in the work beforehand. Also it's had three nearly complete rewrites at this point, one from Morrowind to oblivion, another from oblivion to FO3, and then another from tesV to TesV special edition (yes this was significant, not just moar graphics) None addressed the fps limits, nor the way havok physics would bug out. None reduced the nearly crippling overhead of scripts that blows up savegames... But yes, you're absolutely correct that I misrepresented that. Starfield and tesVI were in development before the aquisition. But they're not lacking for resources, and that's what my point should have been.
  23. Anddd guess what our majesty Todd is using for starfield and TESVI after selling his company to Microsoft for 7 billion dollars? It's gamebyro, so enjoy the next decade of 60 fps locks and muddy textures.
  24. I remember GNR from fallout 3, and how after certain events in game the DJ would report on the way you handled it. The tone, content and everything else depending on how you resolved the situation. That's a full-fleged rpg, but something similar for KSP 2 wouldn't be bad.
  • Create New...