I don’t like this decision, since I know the lack of support for different platforms than Windows as someone playing on Linux. Valve invests into proton and thus game support on Steam Deck and ChromeOS, so I’d have thought they’d make sure CS runs on macOS too.
Big difference I see from Linux and Windows is that they are OS that can be installed on different devices. MacOS is not the case, and even trying to get Linux to be stable and reliable on Apple hardware after the move to their own CPUs is a project in itself with Asahi Linux.
So I can see the lack of interest with how MacOS is a very restrictive Mac hardware only type experience for most people with how getting a hackintosh working is rather involved.
I’d have thought the pain point would have been the processor architecture (ARM64) rather than operating system - MacOS still supports AMD64 using a compatibility layer but it would probably be quite a drawback to game performance.
Not really, unless the game code was written in X86-64 assembly language, does low-level VM allocation for some reason, or otherwise has special dependencies on Intel CPU-isms. With a few exceptions, C/C++/Objective-C code written for X86-64 can be easily recompiled for ARM64.
The PowerPC to X86 transition was much rougher, because of the byte order change + PPC allowing integer division by zero while X86 disallowed it.
What’s your experience here? I’m interested to hear about projects that you have done this for.
The source engine has code that’s over 20 years old. A monolithic project like a game engine, which is statically and dynamically linked with god knows how many libraries they don’t even have code for, let alone permission, to compile in a different architecture, is not gonna be an easy thing to do.
I’ve brought various apps, bundles, and frameworks from PowerPC to Intel to 64-bit to ARM ever since macOS 10.0 first launched. Usually the most difficult parts were:
During the PPC to Intel transition, converting code that expected all data to be big-endian over to handling little-endian data, and catching integer division by zero before sending such operations to the CPU
During the 64-bit transition, switching from all the APIs Apple removed over to newer APIs, if not already done, and converting all code that expected integers and pointers to be 32-bit over to 64-bit
During the ARM transition, converting code that abused variadic functions to code that used them properly, and converting all code that expected long doubles to be 128-bit over to 64-bit (I know some developers were burned by the VM page size change, but that didn’t affect anything I did)
But yeah, usually the most difficult part of the transition is managing the dependencies. Whenever Apple transitions CPU architectures, if your app depends on a closed-source third-party library or kernel extension made by developers that went out of business years ago, you’re more or less screwed unless you can find or build a replacement.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !gaming@beehaw.org
From video gaming to card games and stuff in between, if it’s gaming you can probably discuss it here!
Please Note: Gaming memes are permitted to be posted on Meme Mondays, but will otherwise be removed in an effort to allow other discussions to take place.
I don’t like this decision, since I know the lack of support for different platforms than Windows as someone playing on Linux. Valve invests into proton and thus game support on Steam Deck and ChromeOS, so I’d have thought they’d make sure CS runs on macOS too.
Big difference I see from Linux and Windows is that they are OS that can be installed on different devices. MacOS is not the case, and even trying to get Linux to be stable and reliable on Apple hardware after the move to their own CPUs is a project in itself with Asahi Linux.
So I can see the lack of interest with how MacOS is a very restrictive Mac hardware only type experience for most people with how getting a hackintosh working is rather involved.
I’d have thought the pain point would have been the processor architecture (ARM64) rather than operating system - MacOS still supports AMD64 using a compatibility layer but it would probably be quite a drawback to game performance.
Not really, unless the game code was written in X86-64 assembly language, does low-level VM allocation for some reason, or otherwise has special dependencies on Intel CPU-isms. With a few exceptions, C/C++/Objective-C code written for X86-64 can be easily recompiled for ARM64.
The PowerPC to X86 transition was much rougher, because of the byte order change + PPC allowing integer division by zero while X86 disallowed it.
What’s your experience here? I’m interested to hear about projects that you have done this for.
The source engine has code that’s over 20 years old. A monolithic project like a game engine, which is statically and dynamically linked with god knows how many libraries they don’t even have code for, let alone permission, to compile in a different architecture, is not gonna be an easy thing to do.
I’ve brought various apps, bundles, and frameworks from PowerPC to Intel to 64-bit to ARM ever since macOS 10.0 first launched. Usually the most difficult parts were:
But yeah, usually the most difficult part of the transition is managing the dependencies. Whenever Apple transitions CPU architectures, if your app depends on a closed-source third-party library or kernel extension made by developers that went out of business years ago, you’re more or less screwed unless you can find or build a replacement.