Ending 32-Bit Support with Update 1.5

[BNSF1995]

32-bit should've never even been an option in the first place. For people who love modding the game such as myself, getting the dreaded File Access Error hung over our heads, to the point I had to divide my mods into two installs: one for a Kerbin playthrough, and one for a pseudo-Earth playthrough.

When 64-bit came out, the nightmare was over.

[Lisias]

35 minutes ago, BNSF1995 said:

32-bit should've never even been an option in the first place. For people who love modding the game such as myself, getting the dreaded File Access Error hung over our heads, to the point I had to divide my mods into two installs: one for a Kerbin playthrough, and one for a pseudo-Earth playthrough.

When 64-bit came out, the nightmare was over.

It's more a game design decision than a inherent 32 bits problem - they decided to keep all textures in memory, even when not needed on the scene, to prevent loading times on flying.

Our main problem were chipsets, not CPU. The x86 had 32 bits for data bus but had 36 pins for memory addressing - what renders 64G of theoretically addressable memory. However, all the chipsets of the era only implemented 32 bits addressing and, worse, usually split the addressing space in two, lower half for memory, upper half for use by expansion cards. (it's where the GPU memory is mapped to be accessed by the CPU).

Would be using MIPS, SPARC or even ARM as mainstream home computing, we would not be suffering from this.

That said, in 2011 (when the first KSP versions came to public) 32 bits was still a thing. We are talking Windows XP era here, and the 64 bits XP never got mainstream - you publish a 64 bits game, you shut yourself out of 50% of the market share!

However, given the design decisions, I agree that 32 bits support should be ended with 1.3.1, and the 1.4 era should be 64 bits only. 

[steve_v]

9 minutes ago, Lisias said:

It's more a game design decision than a inherent 32 bits problem - they decided to keep all textures in memory, even when not needed on the scene, to prevent loading times on flying.

Indeed. I keep thinking of ways to improve this, but all the good ones are complicated or require a game engine change. It does mildly annoy me that my modded install uses ~10GB of memory, but I guess that's not too onerous on modern(ish) hardware.
 

7 minutes ago, Lisias said:

Would be using MIPS, SPARC or even ARM as mainstream home computing, we would not be suffering from this.

 

14 minutes ago, Lisias said:

I agree that 32 bits support should be ended with 1.3.1

Agreed, and not a moment too soon. If the Win64 Unity builds weren't such a crock at the time, I would have backed a move to 64bit only as early as 1.0.

[Lisias]

31 minutes ago, steve_v said:

Agreed, and not a moment too soon. If the Win64 Unity builds weren't such a crock at the time, I would have backed a move to 64bit only as early as 1.0.

You see, X64 Unity appears to be still a crock.

I have strong reasons to believe that the Linux problem on the input devices affects Windows too - but are masked by the kludges inside windows to cope wth x32 and x64 binaries,

Check pages 3 and 4 of this:

 

[steve_v]

1 hour ago, Lisias said:

You see, X64 Unity appears to be still a crock.

My opinions on Unity of any stripe are mostly unprintable, but at the time the Win64 build was so unstable that a number of prominent modders explicitly blocked their code from running on it to avoid the support hassle.
It's not as bad as it used to be, but it's not exactly good either as the thread you linked demonstrates nicely.

 

1 hour ago, Lisias said:

I have strong reasons to believe that the Linux problem on the input devices affects Windows too

You might have something there, but I don't know enough about the internals of Windows to comment further.

I can't investigate any crashes related to 32bit code in the input stack myself, because my devices (and a great many others) are not detected in-game to begin with. I don't see anything input-related in the rare crashes I do see either.

From the startup message "GameController: not a gamepad", trawling the Unity forum and SDL mailing list, and the fact that no further initialisation is attempted after this, I can only speculate that Unity is trying to use the new (and not finished) GameController API exclusively.  This was stated to be the case somewhere reputable but I can't recall where to cite it, so I'll stick to "speculate" for now.
Ordinarily this wouldn't be a problem, one would just fall back to the mature joystick API if the device has no gamepad mapping. Unity of course does not, because Unity.

Others have reported that even when your device has a mapping, axes cannot be assigned in-game.
Still others have said that the new "steam controller" support doesn't actually work, and attempting to use one crashes the game.

I can't corroborate those as I don't get past step one, and frankly the "the open source community needs to populate the GameController database" (paraphrased from the bug report) attitude infuriates me to the point of not wanting to help SQUAD in any way.

Edited May 10, 2019 by steve_v

[swjr-swis]

8 hours ago, BNSF1995 said:

32-bit should've never even been an option in the first place.

I disagree. I still have a perfectly well performing install of KSP on a old tiny WinXP laptop that isn't much good for anything else. It's as close to a portable/mobile version as it has ever got, and it goes with me everywhere.

Sure, I've also had a modded-to-heck 64-bit install on my full-fledged gaming laptop as well, but I wasn't lugging that thing anywhere with me unless I planned to spend more than a few nights somewhere.

32-bit version had, and still has, a good use case that is regrettably being ignored.

[Gargamel]

6 hours ago, swjr-swis said:

I disagree. I still have a perfectly well performing install of KSP on a old tiny WinXP laptop that isn't much good for anything else. It's as close to a portable/mobile version as it has ever got, and it goes with me everywhere

Same here.  When KSP was being made initially, to go straight to 64 bit would have eliminated a huge chunk of it's customer base, as a large number (majority?) of machines were still running 32 bit OS's. 

[Lisias]

On 5/10/2019 at 6:18 AM, steve_v said:

I can't corroborate those as I don't get past step one, and frankly the "the open source community needs to populate the GameController database" (paraphrased from the bug report) attitude infuriates me to the point of not wanting to help SQUAD in any way.

That's the catch. We are not helping them. We are helping ourselves.

I would really appreciate that by helping ourselves we end up helping SQUAD too - but, see, this is not a hard requirement.  

[DriftedCougar]

(Necro mode active) I do remember the 32 bit version......in the way of: one launch *crash*, and restart....atleast 64 bit is better... (yes i know this is old, but i hadent created my forum acount yet, so posting it now.)

[Gargamel]

On 6/18/2019 at 5:46 AM, DriftedCougar said:

(Necro mode active) I do remember the 32 bit version......in the way of: one launch *crash*, and restart....atleast 64 bit is better... (yes i know this is old, but i hadent created my forum acount yet, so posting it now.)

I think that was more an issue of it still being in alpha, and the memory limit, not the 32 bit issue per se.   And back in the day, 64 bit KSP was unplayable, it crashed, if it even booted up, a lot more than the 32 bit version did. 

[micha]

3 hours ago, Gargamel said:

And back in the day, 64 bit KSP was unplayable, it crashed, if it even booted up, a lot more than the 32 bit version did. 

That was mostly a Windows (Unity) issue; on Linux, 64-bit KSP was perfectly playable and ran _much_ better than the Windows equivalent.

[Lisias]

7 hours ago, micha said:

That was mostly a Windows (Unity) issue; on Linux, 64-bit KSP was perfectly playable and ran _much_ better than the Windows equivalent.

Until they screwed up HMI devices support. Yeah. Joysticks.   

[Flibble]

On 5/6/2019 at 2:57 PM, Lisias said:

Keep in mind that x86-64 uses only 40 bits for the adreess bus (ie, can adress up to 2^40 memory address).

Not really true on recent hardware. Since they moved the memory controller on-chip some years ago, the number of address lines is actually more like 20.

Edited June 28, 2019 by Flibble

[Lisias]

4 minutes ago, Flibble said:

Not really true on recent hardware. Since they moved the memory controller on-chip some years ago, the number of address lines is actually more like 20.

Adress bus is not the same as Memory Controller. You usually build the Memory Controller around the address bus.

That said, X64 only uses 48 bits internally, the remaining 8 bits of the address registers are plain floating. So even by have a 40 bit address bus on the "outside", internally the CPU still supports up to 48 in the core.

48 bits allows you to address 256 PETABYTES of memory. Unfeasible to get any computer with that much RAM in the foreseeable future.

40 bits allows you to address "only" one PETABYTE of RAM. I'm pretty sure this is enough for nowadays uses.  

[linuxgurugamer]

2 minutes ago, Lisias said:

40 bits allows you to address "only" one PETABYTE of RAM. I'm pretty sure this is enough for nowadays uses

Remember Bill Gayes's famous quote?

"640K should be enough for anybody"

[Flibble]

2 hours ago, Lisias said:

Adress bus is not the same as Memory Controller. You usually build the Memory Controller around the address bus.

That said, X64 only uses 48 bits internally, the remaining 8 bits of the address registers are plain floating. So even by have a 40 bit address bus on the "outside", internally the CPU still supports up to 48 in the core.

48 bits allows you to address 256 PETABYTES of memory. Unfeasible to get any computer with that much RAM in the foreseeable future.

40 bits allows you to address "only" one PETABYTE of RAM. I'm pretty sure this is enough for nowadays uses.  

But there aren't actual address lines so...

Also, most desktop processors only support 64GB anyway, so it doesn't really matter.

[Vanamonde]

The point being, KSP no longer uses 32-bit, no matter how these things may have worked.