source-sdk-2013
source-sdk-2013 copied to clipboard
ValveSoftware
64bit Support for macOS Catalina
Hi,
Based on what I have read, it looks like macOS Catalina (slated for release in the next few months) will drop support for 32bit applications. I believe this impacts this SDK, which will mean that my game (Estranged: Act I) and others will cease to run natively on macOS after the user upgrades their OS.
~~A few questions:~~ ~~1. Is that assessment correct? I only see 32bit dependencies in this repository for macOS~~ ~~2. Will this impact Half-Life 2, Episode 1, Episode 2, Team Fortress 2 and Portal?~~ ~~3. If it does and Valve plans to fix those titles, will that work be upstreamed into this SDK?~~
Edit - since this is confirmed to be affecting older Valve first party titles, a few questions based on that:
- Will this be addressed for older Valve first party titles?
- If it will be, will that work be merged into this SDK?
- Are there any plans to merge the Vulkan support as described below to this SDK?
Thanks, Alan
I currently have Catalina installed & cannot start Half-Life 2 anymore. CS:GO works tho.
Apple will also drop support for OpenGL (which was deprecated in 10.14 Mojave) if Catalina hasn't already dropped it, which means that not only x64 support is needed, but also Vulkan support (trough MoltenVK) needs to be backported from more recent engine branches like CSGO and Dota 2, as it's unlikely that the engine will ever see native Metal support.
If you want to play games, your best bet is to stay on Mojave and sit it out (it's also a great signal towards Apple that they can't just break stuff whenever they like.) Tough it's primarily valve's fault for not anticipating this and working ahead to bring their own engine on par with today's standards.
I am a native dev & needs latest macOS softwares, I am sad that I cannot start HL2 again :'(
Problem is: most people won't know that unless they upgrade & try to start their game...
I even tried Left for Dead 2, same issue... :'(
Yes, asking users to stay on an old version of macOS is not a viable workaround. This is not a surprise annoucement from Apple, it has been several years in the making - as @neico mentioned, this unfortunately sits with Valve as they didn't work ahead and bring the legacy engine branches up to date.
That said, they may not ever do that, I just wanted to express interest in this on behalf of my Mac players in case someone at Valve might have the capacity to do this.
Somewhat related, but if you are in the same position as I am - it looks like Steam will support the distinction between a 32bit and 64bit Mac app and alter the UX accordingly: https://steamcommunity.com/groups/steamworks#announcements/detail/3632639303428097613
I would also like to play HL2 on Catalina. Really sad to see it break. Hopefully Valve can rebuild the apps for 64-bit relatively easy!
It's very likely or unlikely that the 64-bit ports of classic Source engine games (pre-Source 2) are in a form of development hell, making this the 3rd Valve project in development hell after Half-Life 3.
My favorite part of the MacOS user comments is how they blame the developers of old software, for an OS choosing NOT to be backwards compliant. This is CLEARLY intended to steer users to new hardware and software.
What happened to the philosophy that if you CAN keep it backwards compatible without too much trouble, you should! I mean, how hard would it be for the mac dev team to include openGL and 32bit support as a downloadable compatibility package? NOT hard!
But if you read the comments, instead of them adding a SIMPLE option to download and opt to use old code for a game to work properly... they expect valve to COMPLETELY redevelop their 8-15 year old software stack so it can support their new BS driver they prefer now.
Talk about backwards thinking! You've drank the koolaid and I suspect it's too late for you to get good technical representation. You bought the hook, line, the sinker, AND the brooklyn bridge at that point.
It's a little game we play in the industry called, Apple or MS Dev trying to make a name for himself: oh hey guys, if we don't include this old code here, all the old games will stop working, the users will blame the game companies, and we'll sell a TON of new hardware and new games on our app market! Y'know the new expensive ones that people aren't buying because they'd prefer to play through such blockbuster title's as HL2... Apple or MS Exec: LETS DO IT! (I used to just say apple was like this, but MS is copying from the play book lately).
Hey Apple, FIX CATALINA. EVERY mac user I meet that's upgraded to it complains about wanting to downgrade back to Mojave!!
As much as I agree with you Sam that it’s annoying, removing 32bit support is not intended to make Apple more sales. If anything, it would prevent people from upgrading due to backwards compatibility.
32bit needs to die, and Apple gave people more than suitable notice that it was intending to remove 32bit support.
Valve don’t need to redevelop their entire old library, it would be nice but it’s not expected. What they do need to do is update the steam client to be 64bit and any new games they release.
Anyone releasing 32bit games or software in 2020 is a moron.
@SamWWJD420 I don't agree with what Apple is doing at all, but the problem here is that Valve isn't adverting on their source games' steam pages that these games aren't going to work with Catalina. This is false advertisement and can lead many unassuming customers into buying software that was never going to work on their system in the first place.
@Laim
As much as I agree with you Sam that it’s annoying, removing 32bit support is not intended to make Apple more sales. If anything, it would prevent people from upgrading due to backwards compatibility.
Why would Apple intend people not to upgrade? Their entire business model lately has been to prematurely phaseout the old and bring in the new. What, your saying they did this solely because they didn't want to spend money on supporting 32-bit?
I disagree. 32bit doesn't need to die. No more than 16 bit! I have this cool archive on a 16bit windows 3.0 CD. Not only can I run it, due to phenomenal backwards compatibility, I can also run current 64bit applications.
In truth, 32bit apps take less ram; and for some processes they even perform faster on a 64bit architecture with proper support.
Have you heard of backwards compatible? I actually think Steve Jobs promoted this ideal back in the day... but The idea is, as long as you CAN provide backwards support, especially with little or no effort (a line of code that says "include 32bitarchitecture" or something) it isn't as though they have to program something new on 64bit OS software to support 32bit. Like... it's already built and not changing. I haven't heard much about it holding back new technology.
In fact, it only has to do with the size of the DWORD that is available for a variable... If you've ever programmed you'll know it's a cinch between 32bit and 64 bit. It's basically the same code; just 64 bit has longer variables AND can perform more functions. If a programmer uses LESS architecture by choice, and makes a 32bit program, we've all been raised in computers since the 50's to TRY to keep old programs working unless it's something like hardware that breaks things.
Maybe atom's and their arm architecture are what's having trouble supporting 32bit...? I dunno, I guess I can see this clearly:
Mac runs on a version of the Linux kernel. If you have access as a root user on a mac you could in theory compile and add 32 bit support yourself. Why do I know this? Because on any 64 bit linux distribution I install that doesn't have 32 bit architecture, I can download and add that with one to a few lines from the command prompt. It's deception to say that it needs to die; as though it's some anthropomorphic entity that is clawing at the tail of 64 bit like a beast that JUST WONT KEEL OVER AND DIE DARN IT! lol.
No, it's existing code, that works, and you just have to include it. it can't break 64 bit systems UNLESS THEY DON'T INCLUDE THE ALREADY EXISTING CODE!
On Sat, Jan 11, 2020 at 1:50 PM Yetoo1 [email protected] wrote:
@SamWWJD420 https://github.com/SamWWJD420 I don't agree with what Apple is doing at all, but the problem here is that Valve isn't adverting on their source games' steam pages that macs aren't going to work with Catalina. This is false advertisement and can lead many unassuming customers into buying software that was never going to work on their system in the first place.
@Laim https://github.com/Laim
As much as I agree with you Sam that it’s annoying, removing 32bit support is not intended to make Apple more sales. If anything, it would prevent people from upgrading due to backwards compatibility. Why would Apple intend people not to upgrade? They're entire business model lately has been to prematurely phaseout the old and bring in the new. What, your saying the did this solely because they didn't want to spend money on 32-bit?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/source-sdk-2013/issues/481?email_source=notifications&email_token=AOIBDYST65YBKC4B2RPGAGDQ5I5LFA5CNFSM4IUPN5D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWL4HQ#issuecomment-573357598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBDYQ7XUL2H2HJ7WRT3PDQ5I5LFANCNFSM4IUPN5DQ .
@SamWWJD420 I think you misread what I said (or what you read was mangled by Github's mailing process and those quotes were omitted and merged with the statement). I agree that 32-bit should be supported, I disagree with Apple removing it along with supporting it. Macs use XNU which is completely different from the Linux kernel (although not relevant to the discussion) and keeps relatively same user land api and abi as FreeBSD and other BSDs as far as my understanding. What makes Macs similar to Unix is the user land which as said earlier is based off of FreeBSD and other BSDs. What my understanding of what they did was drop the internal data structures to handle 32-bit so compiling standalone libraries won't work. They couldn't have alleviated a lot of the concern and possible exodus by implementing a virtualization solution which would be able to virtualize those data structures on 64 bit, but of course the wouldn't because the entire point was to save money by reduction in time spent in unneeded (to them) areas.
Most likely Steam will go the way they went with SteamOS and linux boxes; and they'll find a way to run in a VM or else include the needed libraries that used to be included in MacOS pre Catalina.
I think I was mostly replying to Liam :) I didn't see your post Yetoo1 until after I'd already replied, sorry!
And Liam, I kinda think it IS for Mac to profit from upgrades and software sales.. I can't imagine it anything to reduce the time spent supporting things..
I'm not really sure if this is the place to argue about who's right or wrong, Valve, Apple, or whatever.
But 64-bit CPUs have been around for ALMOST two decades and have been pretty much standard for over the last 10 years. Nearly everyone has a 64-bit machine with a 64-bit OS.
I'm sure there's very few people who are developing 32-bit only as an explicit choice.
32-bit is the default target when using Visual Studio. (which it really should target the native architecture of the OS) But why change to 64-bit if everything's already working, right?
The continued support and bias for 32-bit has likely had an impact on developers supporting that only.
It is going to suck to rip off the band-aid, but ultimately it is best if operating systems tend toward completely removing 32-bit support, and developers have had loads of time to move over to a 64-bit ecosystem.
If we continue with this not moving forward to 64-bit development, it will only widen the legacy gap and create an artificial dependence on 32-bit. So developers really need to start supporting 64-bit, and operating systems should PLAN to phase 32-bit out, just as OS X has.
I agree with Laim's sentiment that it's stupid to develop a new application and target 32-bit nowadays. Even relatively new applications still run 32-bit only on Windows, such as Discord, which is silly.
Anyway, since this topic is about the Source SDK, I believe CS:GO is already 64-bit native on OS X and Linux. It would be really nice if we could get an updated SDK with 64-bit support, or a Source 2 SDK. I'd settle for either.
Software developers all around have seen increase in performance ever since removing support for XP and x86 (32 bit). Why? Simple, because those things require lots of workarounds and sometimes outright block new features that are a no-brainer on x64. It not only increases the address space of memory, it also introduces faster instructions that sometimes were provided as extensions on x86 (but inconsistently, so you couldn't blindly rely upon them) which are now part of the core instruction set in x64
On the other hand we have Microsoft, the only company still having a major OS still supporting x86 as the default choice (on all other platforms you need to get active to even get your hands on it) And until VS2017 VS was even x86 only (except for the compiler tools) which caused some severe bottlenecks in regard to memory usage. At Valve, their founding members originally came from Microsoft so you'd expect them to have a similar mindset regarding that.
Even then, all their recent games are native x64, CS:GO (source1-2 hybrid), Dota2 (source2) and Half-Life: Alyx is going to be x64 game only for the sole reason that Source 2 doesn't even support x86 anymore. (and would probably cause again some bottlenecks because of VR being pretty demanding)
So the move of apple to remove support to that should be nothing new to a person decently aware of computers. (Even Android is 64 bit per default nowadays)
The real neck breaker here is that they are also removing support for OpenGL, which is very much still one of the major graphics API's, especially cross-platform (second only to Vulkan), there is a decent wrapper for Vulkan (MoltenVK, which wraps around apple's Metal API), but source1 doesn't even support Vulkan. Something that again is a non-issue for Source 2, but the chances of Source2013 getting another update to fix this all up are slim.
The best you can do is watch carefully what will happen to Team Fortress 2, which is an updated branch of Source2013, if that doesn't get those needed changes then mods never will.
Source 2 doesn't even support x86 anymore
That's not accurate. Dota 2 still ships a 32-bit build on Windows (in addition to 64-bit) and is on Source 2.
Many of the older DirectX versions are not officially supported by Microsoft anymore. List of versions and possible same EOL dates as main support for Microsoft's operating systems: DirectX 1.0, 2.0, and 3.0: EOL dates unknown DirectX 4.0: unreleased, never made supported DirectX 5: Windows 95's EOL date (12-31-2001) DirectX 6: Windows 98's EOL date (7-11-2006) DirectX 7: Windows 2000's EOL date (7-13-2010) DirectX 8: Windows XP RTM & SP1's EOL date (10-10-2006) DirectX 9: Windows XP's final EOL date (4-8-2014) DirectX 10: Windows Vista's EOL date (4-11-2017) Either Valve doesn't care about development on currently supported DirectX versions or developing on newer DirectX releases cost more than the older releases, or developing stuff exclusive to 64-bit processors is more expensive than the 32-bit counterparts. So in my speculations, Valve is likely buying most 64-bit PCs but are mislabeling them as 32-bit PCs to call it their own 64-bit PCs. To me, that translates to ViacomCBS buying HTML5 development books but are mislabeling them as HTML4 development books to call it their own HTML5 development books. This means that the 64-bit version of Steam for Windows & Linux, as well as all 64-bit updates for all older pre-Source 2 games are currently in development hell.
So in other words to Valve, re-release all Source Engine games on macOS again and then will buy them, but this time ship it with a new codebase and a cleaner optimized version, by using the CS:GO Source 1-2 hybrid codebase, rather than just the aging & now crappy Source 2013/Orange Box codebase stuff we get multiple patches for patched out exploits multiple times a year. Give us what we want.
GoldScr, kind of a different story, still not officially in 64-bit beta, and even if Valve backported 64-bit code from either Source 2 or some Quake 1 source port with a native 64-bit release, it's very unlikely if the latter engine is getting upgraded to 64-bit.
I upgraded to 10.15 and didn't realize that I would lose access to all of my HL2 games :(. It's really too bad, I cherish that I can still play these games that I bought over 12 years ago. I still have my linux laptop but it isn't quite the same as the performance on my MBP.
why does nobody mention bootcamp here? I think it‘s the best option.
Bootcamp is good, and it's an ok alternative, but it shouldn't need to be used tbh
I upgraded to 10.15 and didn't realize that I would lose access to all of my HL2 games :(. It's really too bad, I cherish that I can still play these games that I bought over 12 years ago. I still have my linux laptop but it isn't quite the same as the performance on my MBP.
Here's an idea for you to entertain: make a portable installation of your favorite gaming/MBP friendly Linux distro on an USB drive and then boot your MBP off of it.
Personally, I would just replace macOS entirely but I can guess you don't want to do that and I can't recommend a dual boot since those are usually a hassle to do in a completely safe manner.
I upgraded to 10.15 and didn't realize that I would lose access to all of my HL2 games :(. It's really too bad, I cherish that I can still play these games that I bought over 12 years ago. I still have my linux laptop but it isn't quite the same as the performance on my MBP.
Here's an idea for you to entertain: make a portable installation of your favorite gaming/MBP friendly Linux distro on an USB drive and then boot your MBP off of it.
Personally, I would just replace macOS entirely but I can guess you don't want to do that and I can't recommend a dual boot since those are usually a hassle to do in a completely safe manner.
Yeah, an extra step but not a bad idea. Unfortunately I think this is the main option, other than dual booting windows (so that I can get double my civ6 performance, the mac client crashes continuously and wont run on my linux setup ugh).
Wait for Half Life 3.
No but seriously. not even the most frequently updated games like Team Fortress 2 are supported anymore. Why can't they just compile the engine in 64bit and push an engine update for all the games?
I have an older Macbook running Catalina, the OS itself runs fine. But most new games that are 64bit run really bad. The source engine games were the only games that ran really well on this book. Now can't even play portal...
I would downgrade to Mojave but some apps like Xcode won't run under Mojave.
source was leaked, now other devs can compile it to 64bit if valve won't do it.
why does nobody mention bootcamp here? I think it‘s the best option.
The bootcamp touchpad driver is a disaster and the Touchpad++ driver looks completely untrustworthy to say the least.
source was leaked, now other devs can compile it to 64bit if valve won't do it.
As smb told me leaked sources miss vphysics, so it will be hard to do without (use vphysics from 2003 engine leak + patch it, maybe). Also, sources are extremely outdated.
May be Valve release Source 1 engine for public one day :)
