KSP - Why no 64-bit?

[walkgeo]

This is clearly a violation of the "What not to suggest thread" which is a sticky that more people need to read around here.............

[vexx32]

This is clearly a violation of the "What not to suggest thread" which is a sticky that more people need to read around here.............

It is intended as point for discussion, not game suggestion... which is precisely the reason we have the [Discussion] tag here.

OK LETS GET THESE STUPID REPEAT THREADS OVER WITH :

a youtuber interviewing c7 who is a KSP dev.

http://www.twitch.tv/hocgaming/b/443077849?t=1h0m15s

WILL PEOPLE STOP ASKING NOW !!!!

Can we just start banning the OP's of these threads?

I cannot take another "idea" THATS ON THE DO NOT SUGGEST LIST.

Both of you, calm down. If you don't want to discuss it, stay out of the thread. If you don't want it discussed, it's more constructive to just not bump the thread instead of getting all antsy.

I considered this too but it's not a real solution as you don't have access to the same number of mods in the unix env. So although you now have the memory you don't have anything to consume it.

There is exactly zero difference in the number of mods you can install on a Unix-based system compared to Windows. Mods are not platform-specific, last I heard. They're just a bunch of files that KSP reads into memory and executes code from.

Everyone here needs to calm down. If you cannot discuss this calmly, do not post in the thread. If you are against it, you are free to say so, but do not demean or belittle other users. Any further off-topic posts will be removed and the users responsible will be warned and/or infracted accordingly. Keep it all strictly on-topic, people.

[landeTLS]

My suggestion is.. continue optimizing the games asset handling with the 32bit limit and as soon as possible when unity 64bit windows version is released then impliment that. But continue optimizing asset handling. Ksp is such an asset intensive game that it should really be a 64bit application.

A nice start for optimizations would be to not duplicate model textures in the memory(just what the texture compressor plugin does to save a lot of memory, in addition to compressing stuff ofcourse)

Edit: there is a lot of raging here. Not a very constructive thing to do guys. Just calm down and have a cookie

Edited March 4, 2014 by landeTLS

[S4qFBxkFFg]

My favoured solution to this problem would be for the Windows/OSX KSP installers to set up Linux as a dual boot then just install the Linux version...

(I think the licences allow this?)

[MR4Y]

My suggestion is.. continue optimizing the games asset handling with the 32bit limit and as soon as possible when unity 64bit windows version is released then impliment that. But continue optimizing asset handling. Ksp is such an asset intensive game that it should really be a 64bit application.

A nice start for optimizations would be to not duplicate model textures in the memory(just what the texture compressor plugin does to save a lot of memory, in addition to compressing stuff ofcourse)

Edit: there is a lot of raging here. Not a very constructive thing to do guys. Just calm down and have a cookie

Well, considering all the "planned" features for 0.24, I suggest that the barrier will be reached in that version. KSP is not Large Address Aware as well, limiting it's usage to 2GB of RAM maximum.

[technicalfool]

Stupid suggestion:

Compile a 64 bit version anyway, alongside the 32 bit executable. Just like in Linux where there's two executables. Cover it in warnings so people aren't going to run it without knowing about the bugs.

It doesn't matter if the 64 bit version is filled with more computer-melting capability than a pound of thermite. It's there, and when people complain about "BUT WHY NO 64 BIT", you tell them to try running it and go "there. That's why."

Maybe hide the 64 bit executable in a "KSP_Win/unstable" directory just to get the message across.

[vexx32]

Well, considering all the "planned" features for 0.24, I suggest that the barrier will be reached in that version. KSP is not Large Address Aware as well, limiting it's usage to 2GB of RAM maximum.

Dunno where or why you got that impression. KSP is LAA and frequently uses in excess of 3GB right up to its present limit of ~3.2-3.5GB of RAM for many people. Depending on your system configuration, though, it can still be limited to 2GB.

Stupid suggestion:

Compile a 64 bit version anyway, alongside the 32 bit executable. Just like in Linux where there's two executables. Cover it in warnings so people aren't going to run it without knowing about the bugs.

It doesn't matter if the 64 bit version is filled with more computer-melting capability than a pound of thermite. It's there, and when people complain about "BUT WHY NO 64 BIT", you tell them to try running it and go "there. That's why."

Maybe hide the 64 bit executable in a "KSP_Win/unstable" directory just to get the message across.

It's not called "unstable" for no reason, you know. The last I heard of it, the 64-bit Windows/OSX executables wouldn't start at all; they'd just crash halfway through the loading sequence with some extremely ambiguous error. If they were usable at all, there's a fair chance they'd be released as well, marked unstable as you said... but they're not even usable as far as I know, so that's a mite pointless.

[Olius]

Unity 5 just came out 2 days ago, and it's 64-bit! YAAAAY!

I expect 0.24 or at least 0.25 will be 64-bit, and thus will be capable of multi-threading (right?), so that will be a life saver for me and my almost 4 year old MacBook Pro.

[Frostiken]

Unity 5 just came out 2 days ago, and it's 64-bit! YAAAAY!

I expect 0.24 or at least 0.25 will be 64-bit, and thus will be capable of multi-threading (right?), so that will be a life saver for me and my almost 4 year old MacBook Pro.

Converting a program to multithread is about ten orders of a hundred orders of magnitude more work than converting it to use 64-bit addresses.

[Nuke]

^ this is correct. multithreading needs to be planned for from the getgo. you dont know how many times ive heard a developer say "we would have to rewrite the whole damn thing" when asked to make their application multithreaded. i dont want to even touch it in my own code.

[6.forty]

The engine is providing methods to take advantage of multithreading. They aren't saying "Our APIs are thread safe now, but figure it out yourself!" because they know half their user base have never even heard the word "mutex".

[Papa_Joe]

Unity 5 just came out 2 days ago, and it's 64-bit! YAAAAY!

I expect 0.24 or at least 0.25 will be 64-bit, and thus will be capable of multi-threading (right?), so that will be a life saver for me and my almost 4 year old MacBook Pro.

Just so we are clear, Unity 5 was announced, not released. They are now accepting pre-orders.

I am indeed looking forward to the date when Squad releases KSP in Unity 5. When ever that date is...

[Computer.Pers]

What about Unity 4.2 (currently 4.3.4) that supports 64 bit on OSX?

[Daisai]

as Captain Sierra and sal_vager have said the real issue is with Unity.

But even if the 64 bit unity was stable and would provide a quick solution to memory issues it is not the elegant answer. There are issues with how KSP uses memory, so you could just add more memory, but that only pushes the problem away until you hit the level of memory an average gamer has. Mod users will be happy for a bit, but then they will just add more and more mods and find they've hit the same wall again.

It is better that Squad continues with 32bit limitations and optimizes the game for that as a) there are still some 32 bit users, they maybe only a few but they shouldn't be excluded, and when they come to adding 64bit support they will have a cleaner solution that will make better use of the available memory and we won't all be running out to by more RAM.

The limiting factor now is the 32bit of an application which gives it a max of about 4gb ( in theory ), the limit of a 64bit application is so high modern computers can't even reach that, unless of course you have about 200gb of memory installed ( which is not the limit btw ), the limit for a 64bit application in memory is around 16 exabytes ( alot of mods ).

At some point you are done optimizing a game and just can't get as much profit out of it and you just need to change to a 64bit application, so spending time optimizing an outdated part of your program ( 32 bit ) is just wasting time when you can spend the same time and resources to optimizing for 64 bit.

[Red Iron Crown]

Squad doesn't control the bitness of the game engine, that's in the Unity developers' hands. Telling them to switch to 64-bit is like telling a taxi driver to fix the potholes in the road.

[Bilfr3d]

Squad doesn't control the bitness of the game engine, that's in the Unity developers' hands. Telling them to switch to 64-bit is like telling a taxi driver to fix the potholes in the road.

That is completely true. What people don't know about 32 and 64-bit is that they ARE completely different architectures. Although that's pretty obvious, what I mean is that 64-bit does require some extra coding to make the game send through those extra 32 bits. In another sense though, that should be catered by the unity engine automatically making it switch to 64-bit, and providing some background coding into a extension that makes the game execute in 64-bit

[R0cketC0der]

That is completely true. What people don't know about 32 and 64-bit is that they ARE completely different architectures. Although that's pretty obvious, what I mean is that 64-bit does require some extra coding to make the game send through those extra 32 bits. In another sense though, that should be catered by the unity engine automatically making it switch to 64-bit, and providing some background coding into a extension that makes the game execute in 64-bit

No it isn't. It's just an extended version of the same architecture. Also C#, the language ksp is written in, is a high-level language, meaning that it's optimized to deliver a good performance while still keeping the code clean and not too complicated. The actual difference for squad would be barely more than a recompile. There is lots of more work to be done on unity's side, however. Game engines are typically written in low-level languages, particularly C++ and C are the most used ones. They have the advantage that you can do a lot more low-level optimization, but have the nasty side that code gets a lot more complex and there are huge differences between 32-bit and 64-bit, or even different operating systems.

[pxi]

Game engines are typically written in low-level languages, particularly C++ and C are the most used ones.

Apologies for nitpicking, but C would traditionally be considered as a high-level language, although it is quite close to the metal. What you would consider a low-level language would be machine code, or assembly.

See: http://en.wikipedia.org/wiki/Low-level_programming_language

Not that this necessarily invalidates your main point however.

[Rowsdower]

Sorry, everyone. I'm shutting this one down. Things have been thoroughly explained at various points in the thread.