Ending 32-Bit Support with Update 1.5

[Gordon Fecyk]

1 hour ago, Boris-Barboris said:

OS-provided temp (pita on windows), 

There's an actual reason for this. %temp% is different per-user because each user needs their own read/write space for temporary files. This way they don't interfere with each others' work on the same PC. "But it's my PC and no one else uses it..." at least until you have a visitor that wants to borrow it. Or you have kids / nieces / nephews. I thought this was the case on MacOS and Linux as well, though.

[General Apocalypse]

The leaner the code the better. God only knows KSP could use all the performance it could get.

Maybe this is the end for having to make builds with as little parts as possible or face the lag kraken ?

[katateochi]

8 hours ago, stupid_chris said:

Having asked about this a long time ago, I've been told they were very very deeply anchored into how the game loader works. Something along the lines of them being harmless and that removing them could be more of a headache than anything. A bit like how a lot of old management systems are in COBOL but replacing them would be insanely expansive. Yknow, don't fix something that works. I guess.

I really hope that isn't true. If it is, that says some concerning things about the design architecture and/or programming practices. Yeah, some big companies have dependencies on utterly obsolete software (and more concerningly, hardware) but you can kind of understand that given the age when they were first developed.  There is no excuse for that sort of meshugas in modern software development.

[Lisias]

6 hours ago, katateochi said:

I really hope that isn't true. If it is, that says some concerning things about the design architecture and/or programming practices. [cut by me]  There is no excuse for that sort of meshugas in modern software development.

Leaking abstractions happens. And once your artifacts became dependent of that abstraction, solving the leak can incur on colateral effects that would demand a full recertification of every single component of your product to prevent a blow on yours users' machines.

If the cost of fixing such leak is way higher than the cost of leaving things as they are, it's nonsense (and even dull incompetence) fixing such a leak.

One could think it would be a good idea to mask the problem - an initialization code that would run after the leak to undo the undesired behaviour, so nobody would notice and so, nobody would bother. That, my friend, would be a "meshuga".

Currently, this is just an annoyance. It would be better (mainly to save face) that this would not had happen, but if a proper fix is not feasible with a proper cost/benefit ratio and without causing undesirable collateral damages, I say left it alone. At least, for now.

There're way more serious problems to be fixed or at least properly workarounded.

Edited October 15, 2018 by Lisias
hit "Save" too soon.

[Greenfire32]

I remember when 32-bit was all we had and then 64-bit was introduced, but it was unstable and not recommended.

How times change.

[Chel]

RIP 32-bit KSP

You will always be in my heart, whether that be through framerate or crash logs

[NoMrBond]

In a sort of related vein, will KSP's graphics API support roll upwards as well at some point?

DX11 has been out for ~10 years at this point and DX11-HLSL is incredibly similar the PSSL on the PS4 (XB1 uses DX) meaning shader work could be shared between the PC-PS4-XB1 platforms with ease

[Ruedii]

Does this mean that the Linux version will FINALLY launch in 64bit by default?

 

1 hour ago, NoMrBond said:

In a sort of related vein, will KSP's graphics API support roll upwards as well at some point?

DX11 has been out for ~10 years at this point and DX11-HLSL is incredibly similar the PSSL on the PS4 (XB1 uses DX) meaning shader work could be shared between the PC-PS4-XB1 platforms with ease

Unity3D already has built in converters.  There is no need.

Direct3D 11 also doesn't add that much in all honestly.   HLSL is used in Direct3D 9 as well. 

SLang is now the preferred high level shader language.

Edited October 15, 2018 by Ruedii

[Jim DiGriz]

"Press 'F' to pay respects"

[stupid_chris]

13 hours ago, katateochi said:

I really hope that isn't true. If it is, that says some concerning things about the design architecture and/or programming practices. Yeah, some big companies have dependencies on utterly obsolete software (and more concerningly, hardware) but you can kind of understand that given the age when they were first developed.  There is no excuse for that sort of meshugas in modern software development.

I was told this sometime in 2014, so if it's still there... yeah. It probably ain't going.

[Shadowmage]

11 hours ago, NoMrBond said:

In a sort of related vein, will KSP's graphics API support roll upwards as well at some point?

Indeed -- when can I expect DX9 to be deprecated entirely?  (Okay, its been 'deprecated' for years now... when will people stop mandating its use?)

[rmaine]

22 hours ago, katateochi said:

I really hope that isn't true. If it is, that says some concerning things about the design architecture and/or programming practices. Yeah, some big companies have dependencies on utterly obsolete software (and more concerningly, hardware) but you can kind of understand that given the age when they were first developed.  There is no excuse for that sort of meshugas in modern software development.

I'd say you were an incredible optimist. I retired from NASA about 12 years ago. In chatting with people about new developments since I've been gone in areas I worked in, I'm regularly amazed at things being done today that we long ago learned better than. Details inappropriate here and would take a book anyway. I will just note that some of them very specifically involve building in dependencies on proprietary hardware and software that I'm sure will cause headaches down the line when that stuff is no longer current and the company that did it might not even still be around. We've been bit so badly by that in the past that I thought the lesson would have been learned. Maybe I'm extra sensitive to it because portability and vendor independence was something I paid a lot of attention to (after having spent a lot of time dealing with the consequences of prior failings in those areas, both by myself and others). Alas. :-(

[Jimbodiah]

On 10/12/2018 at 8:54 PM, The Dunatian said:

64-bit will work with Windows 8, right?

There was a 64bit version of XP.

It's silly that there are still 32bit versions for the operating systems for the past 10 years as all the hardware has been 64bit for ages.

[Lisias]

3 hours ago, Jimbodiah said:

It's silly that there are still 32bit versions for the operating systems for the past 10 years as all the hardware has been 64bit for ages.

There're a lot of appliances (commercial, industrial and even agricultural) that still relies on 32 bits CPUs. These things just don't die. :-)

What it's a good thing for Microsoft, as their replacement will hardly run Windows 10.  

[Wyzard]

21 hours ago, Ruedii said:

Does this mean that the Linux version will FINALLY launch in 64bit by default?

I just checked, and yes, it does.

[Ruedii]

5 hours ago, Lisias said:

There're a lot of appliances (commercial, industrial and even agricultural) that still relies on 32 bits CPUs. These things just don't die. :-)

What it's a good thing for Microsoft, as their replacement will hardly run Windows 10.  

Most such appliances will be moving to RISC V or ARM according to the developers who make them.

The RISC V is a very small instruction set computer recently developed with a completely open architecture down to and including the entire silicon layout (to transistor) of the benchmark template CPU core provided in the design manuals.   It has an incredibly small instruction set with reserved space for special use instructions for modified versions.  It was made by a group who's backers are the who's who of the computing world for everything from desktop to mobile to IoT.

ARM is of course the platform from which most phones use, and is the current go-to processor for a high processing speed lightweight low power SoC.

Some still run on 16 bit and 8bit pre-intel CPUs.  (Often 16/8bit hybrid architectures similar to the 8086, including the 80186)  

There is a high reliability version of the TI TMS9989 CPU that is incredibly popular in military airplane design.  It is a high-reliability 8bit variant of the TMS99000 CPU with differential voltage lines for prevention of glitching and other errors. Considering that the TMS99000 line is the highest performance CPU of it's (it's era being the late 70s, and exceeding the arithmetic performance of an early 80386SX or late 80286)   It is particularly adept at handling lightweight bytecode interpreters which make it extremely high performance.

16bit/32bit hybrid MIPS specialty chips are also widely used.  Some even use the even smaller 4bit LPC external bus to reduce pin count and simplify board design.  Your router probably has an MIPS processor in it, and if you have a RealTek network chip or sound chip on your motherboard (which you probably have both) you no doubt have a MIPS specialty processor with a 4bit LPC bus connection to your chipset.

[Ruedii]

16 hours ago, Shadowmage said:

Indeed -- when can I expect DX9 to be deprecated entirely?  (Okay, its been 'deprecated' for years now... when will people stop mandating its use?)

It's already not mandated, but everyone supports it in any gaming class drivers.  Many drivers only support the Direct3D 9.5 subset which removes some of the bloat from older versions of D3D.

Technically if I was Squad I would use SLang/SPIR for in-house shaders (this is an intermediary code level that can be converted to HLSL, GLSL and Vulkan SPIR-V), and limit myself to relying on extensions supported directly by Direct3D 10, 9, GLSL 3.1 Core and Vulkan on the fallback shaders.

This means not relying on any of the bloat in Dx9.

For optional shaders, I would, of course support more advanced extensions.

I would auto-detect the use of Dx10/11 or Dx9 context handling.  This would allow continued support for the few people using Windows XP and related Windows Enterprise versions.  I would also support OpenGL on Windows and add Vulkan support as soon as it's available in Unity.

As a note, SLang/SPIR is the absolutely highest compatibility intermediary language now.  It is a simplified HLSL language made to compile more directly into GLSL Source  and GLSL/ARB Bytecode (for OpenGL) as well as compile nicely into other modern shader bytecodes,  It removes all the bloat of HLSL (same bloat removed in SM4/SM5 for Dx Level 10/11) and can be directly compiled into most modern Intermediary languages such as those used on the PS4, Vulkan and in D3D 12.   SPIR-V is an extension of this that has been Reoptimized for vulkan.  It doesn't translate as well into GLSL/ARB

Since D3D 12 context support is still very limited (and buggy) in Unity3D as is Windows Vulkan and Linux Vulkan using extensions specifically for them, and using their better context and texture management will have to wait.  (As a note Unity is exploring using a Vulkan to Metal stack on mac, which would make Vulkan a very good intermediary for all Desktop platforms.  Vulkan is already close enough to Metal that Vulkan shaders can be transcompiled ahead of time to Metal so long as they don't use a handful of unsupported extensions.)

Edited October 16, 2018 by Ruedii
Give more about OpenGL and Vulkan.

[Harry Rhodan]

I'm still a bit confused. Are you intending to actually remove the 32bit executables or just don't want to support them anymore? I'm asking because there's still a 32bit binary in the Linux version.

[Jimbodiah]

On 10/16/2018 at 6:50 AM, Ruedii said:

There is a high reliability version of the TI TMS9989 CPU that is incredibly popular in military airplane design.  It is a high-reliability 8bit variant of the TMS99000 CPU with differential voltage lines for prevention of glitching and other errors. Considering that the TMS99000 line is the highest performance CPU of it's (it's era being the late 70s, and exceeding the arithmetic performance of an early 80386SX or late 80286)   It is particularly adept at handling lightweight bytecode interpreters which make it extremely high performance.

16bit/32bit hybrid MIPS specialty chips are also widely used.  Some even use the even smaller 4bit LPC external bus to reduce pin count and simplify board design.  Your router probably has an MIPS processor in it, and if you have a RealTek network chip or sound chip on your motherboard (which you probably have both) you no doubt have a MIPS specialty processor with a 4bit LPC bus connection to your chipset.

I doubt an airplane will run on Windows; that would give a new meaning to " your system crashing". Not even mentioning these systems are not meant to run KSP either, so bringing it up is kind of a moot point.

For systems that are meant to play KSP, these have been 64-bit for most of the 21st century

Dang. They skipped 1.5.0 and went straight for 1.5.1? Or did I miss something? (<yep, hotfix)

Edited October 22, 2018 by Jimbodiah

[Dr. Jet]

On 10/15/2018 at 7:25 AM, Ruedii said:

Direct3D 11 also doesn't add that much in all honestly.   HLSL is used in Direct3D 9 as well. 

In KSP it does add RAM usage efficiency. A lot.

Edited October 22, 2018 by Dr. Jet

[Ruedii]

On 10/22/2018 at 3:55 PM, Dr. Jet said:

In KSP it does add RAM usage efficiency. A lot. 

Technically Direct3D 10 w/ SM3 is just as good on KSP.   I don't even know if KSP uses SM4/SM5 shaders at all.

Direct3D 10 changed the context management method for texture maps, improving memory footprint drastically.

OpenGL probably has the best memory savings. BTW (Vulkan probably better still, but it's horribly buggy.  I'm surprised they build with the beta Vulkan support in Unity.)

On 10/21/2018 at 11:56 PM, Jimbodiah said:

I doubt an airplane will run on Windows; that would give a new meaning to " your system crashing". Not even mentioning these systems are not meant to run KSP either, so bringing it up is kind of a moot point.

For systems that are meant to play KSP, these have been 64-bit for most of the 21st century

Dang. They skipped 1.5.0 and went straight for 1.5.1? Or did I miss something? (<yep, hotfix)

They went released 1.5.1 only a couple days later with a small number bug fixes.

[SpaceCube2000]

Long time coming. I doubt that there's a 32-bit computer that's been able to run KSP since 2012. Intel stopped making 32-bit CPU's in 2008, if I remember correctly. 

[YNM]

12 hours ago, SpaceCube2000 said:

I doubt that there's a 32-bit computer that's been able to run KSP since 2012.

I still have one sitting in my parent's bedroom, played KSP on it 'till 2016 (then I moved out to uni). Bought it in 2013. And it's 32-bit Windows 7 in all it's glory (used to only have 2 gig ram as well ! then I upgraded it).

Edited October 25, 2018 by YNM

[SpaceCube2000]

7 hours ago, YNM said:

I still have one sitting in my parent's bedroom, played KSP on it 'till 2016 (then I moved out to uni). Bought it in 2013. And it's 32-bit Windows 7 in all it's glory (used to only have 2 gig ram as well ! then I upgraded it).

What CPU did it have? I believe Intel stopped making 32-bit processors with the release of the Core 2 Duo. 

[WhereAmI]

Will I be able to play 1.5 before the end of 2018?