64 bit

[CyclonicTuna]

Before I get slammend for asking this question or creating this topic, this is more of a question than a suggestion.

I can't really find a clear explanation on why Unity hasn't gone 64 bit yet. Could anyone here elaborate? I mean, whats the main hold up. Because I think that a game like KSP could profit endlessly from going 64 bit.

[Monger]

There are serious obstacles before 64 bit application actually run faster than their 32 Bit counterpart. For example, Unity is based on .NET, which is a managed runtime. And .NET limits the amount of memory it can handle, because memory fragmentation becomes really an issue with thousands of objects. So even if Unity would switch to 64bit, this doesn't mean that KSP automatically can acquire more memory, and that this would help performance more than hurt it. Second, 64Bit processes require 64Bit pointers, which require more memory. So just by switching you would increase your memory footprint. Also, Unity depends on 3rd party products, which would need to convert to 64bit as well.

Of course there are multiple advantages as well, but it's not like you just flip a switch, and your software runs significantly faster. You have to design your whole application around it to get the most of it.

[kiwiak]

I heard thant 64 bit unity for windows is just too unstable yet.

[jwenting]

there we go again...

[GarrettKajmowicz]

I'm running the 64-bit version under Linux and things mostly work fine. (There are a couple of odd quirks involving planets using the wrong-scale texture, though I don't know if that's specific to this version or not).

OTOH, I'm still only running vanilla for now, so I'm not certain if the system is even able to use more than 4GB memory at the moment.

To second what Monger mentioned, simply converting from 32-bit to 64-bit binaries typically increases the size of the executible by about 10%. Put another way, it adds about 10% more overhead. If you have more than 4GB of RAM in your system, the cost might be trivial if it allows you to address more overall. (Eg. if you have 8GB of memory, having your current KSP memory usage go from 4GB to 4.5GB is okay if you still manage to get another 2GB of free memory you can add on). That 10% number is an industry-standard average from a decade ago or so. Because KSP is very multimedia-extensive, it could be ~1%. I don't know.

[sal_vager]

Squad know that players want and would benefit from a 64bit version of KSP, unfortunately until Unity 64bit support is stable enough there's nothing Squad can do.

Currently only the Linux 64bit version is available and even that is classed as experimental, though it does seem to work pretty well, maybe it'll be good enough in the next Unity update, we just don't know yet.

Check out the Unity forums for a ton of threads on 64bit Windows and OSX stability problems, it's not just KSP that could use a 64bit version, but many other Unity games as well.

[crazyewok]

It would help such a ton. Theres so many great mods.

[Rakaydos]

Are you saying that the 64 bit version of KSP would be a Steambox Exclusive? (being linux based)

...assuming it was done, of course...

[sal_vager]

What on earth gave you that idea? Linux 64bit binaries are in the Linux downloads from the store and Steam right now.

As soon as Unity pumps out stable Win and OSX 64bit binaries Squad will bundle them in the downloads too.

[S4qFBxkFFg]

[joke]This could be easily solved by including a Linux distro installer in the Windows and OSX KSP downloads.[/joke]

[coolitic]

I wonder how long it will take for mods to close this topic?

(RADIO) Calling in topic lockdown, waiting on mods.

[Dunbaratu]

What's weird to me is that I don't understand what the technical reason is that it would be easier to make a 64 bit version stable on Linux than on Windows. Unity says "it isn't stable on Windows" but that's just a restatement of the problem rather than an explanation of what causes it.

Could it just be the large number of Linux distros out there that don't turn on 32 bit support libraries by default (making you have to go download and install them separately), and try to run the entire system cleanly fully in 64-bit? In other words it's because of a difference in how necessary 64-bit is for smooth installation - that it came to Linux first because of how many Linux admins (including owners of personal home systems) there are in the customer base that are trying to run a purely 64-bit system from top to bottom. For them, having Unity work on 64-bit would be a requirement rather than just a nicety. So getting Unity to be 64-bit on Linux may be a goal with a higher incentive than getting it to be 64-bit on Windows, and that higher incentive is the reason it's further along on Linux than Windows.

Edited February 5, 2014 by Steven Mading

[Motokid600]

Room for addons is getting smaller and smaller with each update. So at some point Squad/Unity will be forced to take action.

[Deadweasel]

For those who aren't yet aware of them, there are some mods that help memory usage by compressing any textures to formats that are easier for video cards to work with, and reduce the actively-used memory footprint as well.

For those who would like to use their own custom textures to replace the planets, skybox and kerbals:

• Universe replacer
  
• Texture Replacer
  

For those who use the stock textures (including those delivered with parts pack mods)

• Active texture management
  

The first two will help to reduce memory usage, while opening up the capability to replace the stock imagery in the game. Of the two, I've found Texture Replacer is a bit better at reducing RAM usage, while requiring a bit more effort to get the new textures in place. The last, Active Texture Management, is a bit more purpose-built, and is a "one shot" mod, in that it handles the compression on a more permanent basis, rather than doing it on the fly during loading. The results may be worth the "destructive" nature of the beast for some players.

That said, let's not forget that there are two major classes of issues that people see in this game

• Crash-to-desktop (or CTD): Occurs most often when the current 32-bit Unity engine is trying to use more than ~3.2-3.4GB of RAM, due to overhead introduced by mods. Having a 64-bit Unity engine running underneath it all would likely help drastically reduce (if not eliminate) the frequency of this issue, but would not necessarily be a straight cure-all, due to the reasons stated previously. 64-bit Unity itself would require more RAM just to get up and running. If a player is experiencing CTD and has "only" 4 or 6 gigs of RAM installed, going 64-bit would not likely help the issue very much at the end of the day.
  
• Frame rate lag: Unity's physics calculations are primarily done on the graphics card's processor. Going 64-bit would not really have an impact on performance with 600 part ships in the scene, and this especially true for video cards that weren't meant for major graphics applications. Most of the integrated graphics adapters found in laptops, low-profile desktops or "value" desktops like Compaq or eMachines fall into this category.
  

By and large, the main benefits of 64-bit in this case would be access to more RAM (so we can install even more of those oh-so-tasty mods!), and potentially slightly faster load times. That's about it.

Folks running the experimental Linux distro can offer some perspective, but Windows and OSX users should be cautious about accepting those cases as universally applicable facts, due to the fact that Linux is so much more intricately configurable and adjustable, compared to OSX or Windows, where drivers and memory management processes are concerned.

Linux folks can compensate and tweak core-level settings to get around glitches and leaks, but anybody not running Linux will simply have to wait for Unity to get things working from their end. We simply don't get that kind of configurability with our drivers, unless somebody is enough of a code wizard to write their own driver patch.

[CyclonicTuna]

I wonder how long it will take for mods to close this topic?

(RADIO) Calling in topic lockdown, waiting on mods.

I didn't start this thread to ask for a 64 bit version of KSP. I know the dev's have told us time and time again that it will be here when Unity goes 64 bit. I just wanted to know a littlebit more about the technical details because I find that stuff interesting. Is there something wrong with that?

[Red Iron Crown]

Frame rate lag: Unity's physics calculations are primarily done on the graphics card's processor. Going 64-bit would not really have an impact on performance with 600 part ships in the scene, and this especially true for video cards that weren't meant for major graphics applications. Most of the integrated graphics adapters found in laptops, low-profile desktops or "value" desktops like Compaq or eMachines fall into this category.

I don't think this is correct. As I understand it, all of Unity's physics calculations are done in a single CPU thread by an old version of PhysX that doesn't take advantage of the GPU for that. The GPU is used for rendering only.

[sal_vager]

I don't think this is correct. As I understand it, all of Unity's physics calculations are done in a single CPU thread by an old version of PhysX that doesn't take advantage of the GPU for that. The GPU is used for rendering only.

Yep, this is currently correct, other stuff can be handed off to other cores but the physics is on one core only at present.

[Serratus]

Yep, this is currently correct, other stuff can be handed off to other cores but the physics is on one core only at present.

Ah! Now those readings from my resources monitor start to make sense! So the real question here is does SQUAD intend to upgrade their physics engine to a version that supports multi-threads any time soon? Because I recently doubled my RAM and it didn't give me even one extra frame :/

[sal_vager]

Squad will update to the latest version of Unity if it's available (and if it doesn't break too many things) but there's no plans to change engines.

Unity will get better, Squad pester them quite a bit to get this stuff sorted out

[Serratus]

[...]Squad pester them quite a bit to get this stuff sorted out

Lol, I just imagined Harvester calling Unity Devs everyday with a question "-Are we there yet?", "-*distant voice*BOSS! It's that creep again!"

[vexx32]

Lol, I just imagined Harvester calling Unity Devs everyday with a question "-Are we there yet?", "-*distant voice*BOSS! It's that creep again!"

That sounds rather accurate, although it's probably a very long-running exchange of emails: "So, how's it going?" "It's getting there." "Are we there yet?" "We'll get there when we get there." "Can we get a timeframe?" "This is programming, not railroad construction."

Repeat ad infinitum.

[Red Iron Crown]

Somehow I don't imagine they pester the Unity people for release dates, given their own policy about such things.

[Nuke]

if you want to solve the problems of memory related crashes now, instead of when unity fully supports 64 bit, then the game is in dire need of better bitmap management code. bitmaps are the bulk of the data that the game needs to load. they are big and there are a lot of them.

we have all seen the effects of compressing all the textures and simply reducing them. there are mods for that. they are good mods. but frankly, its not the job of modders to fix the holes in the game's critical subsystems despite how good they may be at it. also the closer the systems are to the core of the game the higher their performance. id rather them make cool mods than workarounds to make other mods more usable.

this brings us to: pre-optimised texture assets. why load a texture that is 6 times bigger and waste time compressing it when you can just load a pre-compressed texture? if the textures have pre-generated mipmaps then no time is wasted in generating them either. you can ship really high resolution compressed textures, and have the game only load the mip levels that are needed/can fit (64-bit linux users with high end hardware would be able to go nuts).

still running out of ram: use streaming. you have a texture memory target that the game actively tries to maintain, and you keep track of how frequently textures are used. if the textures use more memory than the target then the game streams out high mip levels of infrequently used textures, and if you are under budget load some more. all textures are loaded at some minimum mip level so that there is always a lower resolution texture to fall back on. this and the memory target can be tweaked in real time based on system capabilities and memory needs. you also arent required to load the whole texture, just the mips levels you need. pre-compressed assets make this more robust by reducing and eliminating load times and compression times, respectively.

tldr: precompressed assets+streaming now > 64 bit later

[Serratus]

[...]its not the job of modders to fix the holes in the game's critical subsystems despite how good they may be at it.

Or SQUAD can do their usual thing of hiring talented modders for the dev team. They did it with C7 and NovaSilisko, who are content creators. It would make sense to get someone talented in optimizing next. Besides - modders want to make game better. Those optimizing mods do just that. But I agree with overall point, even if I don't really understood the whole "streaming" thing you wrote about.

[Nuke]

im all for talented modders getting jobs at game studios.