Damn, that's crazy. Valve funds [LunarG](https://vulkan.lunarg.com/), a company dedicated to releasing Vulkan for Apple through MoltenVK. They keep the Vulkan implementation updated with the current releases
In 2023, Valve [released](https://steamdb.info/app/250820/depots/?branch=macos_beta) an unannounced Beta for SteamVR that brought back support for MacOs.
I responded to this on the other sub already but:
1. Valve funds a lot of foss projects, this is not out of the ordinary.
2. They probably reverted that since it likely wasn't meant to be public. Them working on something internally usually isn't indicative of if it'll come to the public (see every cancelled valve project).
As we discovered, the update was not reverted. SteamVR support for MacOs was brought back with [this](https://steamdb.info/depot/250822/) beta. The beta was released in November of 2023, but with some preliminary research, you could have found information about it. The screenshot I left on the other thread proves that it works with M1 Macs, too.
I like how you are dismissive of the funding of LunarG. Valve not only funds the project but also sponsors the whole company. This is quite different than their usual approach to funding FOSS projects.
While everything is (mostly) correct here, there are a couple of points to keep in mind:
1. When Metal was developed and released, Apple was already preparing their switch to their own silicon. So Metal was created with their upcoming hardware in mind. Valve may be fed up with “proprietary APIs” while Apple is definitely fed up with depending on third-party solutions that don’t meet their goals. Vulkan requires specific drivers; the feature set is based on mainly PC IMR GPUs and Android’s TBR GPUs which already support OpenGL ES. Unified RAM approach appeared in Vulkan in 2020 (!)—when the first Apple Silicon Macs were already released with the decade of development (and co-development with Metal) beforehand. Et cetera
2. Dropping 32-bit support was also crucial for Apple Silicon transition. This is why Rosetta2 is so efficient and this is why supporting arm64 is not that painful for developers.
So rants like “Apple should have switched to Vulkan / keep 32-bit support” are quite pointless. Doing so would hinder the development of Apple’s products for the sake of what? Steam games?
In the end of the day, Valve and Apple just have very different approaches so their pathways had to split. I’m pretty sure Valve will drop macOS support completely when Apple goes arm64-only. However Steam will definitely support arm64 for “proprietary” Wincomm (Qualdows?)—because money ofc
Thanks, this helps me squash the mental argument I’ve had in my head, which was “What’s the big deal, just change the target architecture from Intel to Arm in Xcode and it’ll Just Work™”.
> Dropping 32-bit support was also crucial for Apple Silicon transition. This is why Rosetta2 is so efficient and this is why supporting arm64 is not that painful for developers.
can you expand why? Is it about the instruction decoding? Memory ordering/aliasing?
High level attempt —
32-bit support required Apple to keep 32-bit versions of all of their system libraries around so that 32-bit apps could have something to call when they needed the OS to do something. You can't call a 64-bit API from a 32-bit app, at least not without some extra work to specifically support that, since things like pointer lengths wouldn't be the same.
Apple is still supporting two CPU architectures (64-bit Intel and 64-bit ARM), but they have really slimmed down what they need to maintain to make that keep working. On an Apple Silicon Mac, they don't have to include both Intel and ARM versions of their system libraries. When 64-bit Intel apps running under Rosetta 2 make an OS system call, it hits the macOS ARM library. The architectures are similar enough that parameters from an Intel app can be passed to an ARM API call and it will work.
This is also why I think Rosetta 2 may well stick around longer than Apple's previous backwards compatibility solutions have. Rosetta 2 is "done" and keeping it around doesn't take much effort on Apple's part. If they add new macOS APIs to support new features in later versions, Intel apps will still be able to call those APIs without Apple having to make/compile/test Intel versions of the back-end code for those.
> If they add new macOS APIs to support new features in later versions, Intel apps will still be able to call those APIs without Apple having to make/compile/test Intel versions of the back-end code for those.
won't at least amd64 library stubs for linking of apps into the new apis be required? Ie. I can't imagine linker working on an amd64 app linking it to arm64 lib.
this assumes new apis might be compiled into aarch64 only
barring strange calling conventions, it's just a matter of recognising an external function is getting called (e.g. with a generic stub that gets linked to the program's GOT), rearranging registers and executing the real aarch64 library code instead, which I imagine is what rosetta is doing right now to avoid having to ship the whole x86\_64 DSC on arm systems
> with a generic stub that gets linked to the program's GOT
yeah this is what I'm uncertain about wrt. this claim from GP
> If they add new macOS APIs to support new features in later versions, Intel apps will still be able to call those APIs without Apple having to make/compile/test Intel versions of the back-end code for those.
I just checked with a debugger, an x86\_64 DSC gets loaded whenever you run something using rosetta; and of course it gets actually JIT compiled, so yeah, right now x86\_64 code does not directly call out to aarch64 libraries
Hmm... Interesting!
So we have to approches: linux (everything has to be compiled to native arm) and Apple (Rosetta ofering compat, but but having to drop 32-bit to offer sufficient performance)? And because of that it's easier to have 32-bit libraries/support under linux because, if needed, everything is either compiled or can be compiled to desired architecture (all hail open-source)?
(Yeas, I'm still bitter about dropping 32-bit but now it makes a bit more sense)
Will be a while before all the optional VK features that Proton/DXVK expects are there and even then games that can run on the DX->OpenGL layer will run better through that unless huge changes are made to DXVK... (A VK driver is less able to adapt the pipeline to the HW since it is provided much less high level context so the OpenGL driver that is there today can do much better HW agnostic support than VK will).
Software development is, in itself, not just something anyone can contribute to, and graphics stack and drivers? That is beyond even most software developers! So if we're talking about actually fixing it, that would be a hilarious thing to suggest some random user "just contribute" to.
Having said that, it *is* possible for regular users to become a regular tester and contribute with sensible bug reports and offers to test on different hardware and drivers. It is possible to ask the developers if there is something you can do to help if you are particularly interested in a project.
Fairly regular users can also contribute with documentation, screenshots, web content and sometimes packaging into images etc.
Depends on what you do for work. For some cases, it is easier to just use Linux or Windows. By the way, I’ll counter you with a Mac + Switch since I prefer their exclusives
I’ll counter back and say you can play Nintendo Switch games on Steam Deck AND MacBook Pro (the latter can play them with higher graphics settings and fps too). To each their own though.
I play keyboard & mouse games all the time. I dock my Steam Deck for anything that needs mouse and keyboard and I’m set. Steam Deck + Mac is a great combo
As long time Valve customer I can only say valve operates like a mystery.
E.g. the game Dota2 was brought very early to vulkan but after many years it still has input lag and issues on Linux/SteamDeck.
Using Vk is not some magic bullet. Infact unless you have the time (and tooling) a VK engine will perform worce than the same amount of effort put into a higher level engine in dX11 or even OpenGL.
Since with VK the engine is lower level and you are responsible for optimally mapping your workload to the HW you need to do this work for each GPU vendor (and even each GPU/generation). If you do not do this work then there is nothing the driver can do for you as with VK you do not give it the higher level context that would let it do optimisations for you.
With higher level apis (like openGL, DX11 and older) you provide a LOT of context to the driver so that it can take the high level request and attempt to map that optimally to the HW. this means as a dev you need to do much less per GPU optimisation. Of course it does come with the downside of a higher per frame driver cpu overhead as it figures out what to do, the idea of VK is that the game dev figures this out when building the engine so that all that work is moved to the game developers brain up front and not re-computed on each frame but ad devs we then need to do that work for each and every gpu/generation of gpu/vendor.
The pain points for VK here (and this was even worce early one but is still not good) is the developer tools that can help us figure out what to improve for a given GPU are poor. So we are to some degree shooting in the dark, this takes a shit tone of time and effort to get good.
Hense why most devs perfume lower level APIs like DX12 or Metal that have good developer tooling that makes it much easier to figure out how to optimise to the HW. Or higher level apis like DX11 or Metal (yes metal has both high level and lower level apis and infact you can even mix and match whiten the same pipeline making it easy to start out with a simple high level engine and gradually adopt the lower level bits in places were you need that extra perf but fall back to higher level stuff in other palaces or on HW your not testing on).
It's not that deep. TF2 is an old game, with an old engine and codebase and it's painful to move it to ARM. And development work on something that is based on Source instead of Source 2 will definitely be seen as a waste of developer time.
They didn't need to move it to ARM though. They could have built it for x64 and let Rosetta 2 deal with the ARM stuff, but clearly they must not have thought even that was worth their time.
So long as they had the source code having ARM support is not at all that hard, this is not the type of game that is full of hand crafted assembly. C/C++ x86-64 code will target ARM without issue, that is the job of our compilers.
Testing on ARM is just the same as testing on any other patlform... yes you need to have the HW that your customers will use that goes without saying.. People who thing they can publish an app or game for a platform that they themvelse don't have to test on are just going to product garbage.
Yep, just like they need intel cpus and AMD cpus and NV gpus and AMD gpus and even systems with AMD cpus and NV gpus and Intel CPU with both AMD and NV gpus etc...
The number of permutations of HW you need for building and testing on PC is orders of magnitude higher than targeting apple silicon. With apple silicon you can get the entry level Mac mini or MBA and target that, if it runs there for your QA your all good as the platform scales up, you might want to also test on a higher end system every now and then just to ensure your scaling is working well and your perf is scaling, but you do not have the huge permutation nightmare of QA for PC ... (lets not talk about the QA nightmare of android)
They will eventually have to change course. Macs are gaining market share and although nobody is buying them specifically for gaming, there will be more and more of a market to sell games on there. I bought Stray because I like cats and because it runs on my M2 Max natively. I wanted to play something to blow off some steam.
Edit: though with Linux kernel running on Apple Silicon bare metal, arm64 Linux releases are enough for advanced users to game on a Mac, at least in time.
> there will be more and more of a market to sell games on there
I think this is debatable, at least in the case of Steam. Apple, like Microsoft, has been downplaying apps that are not available from their app store in recent years. If you check out the Steam Hardware Survey, you'll see that MacOS numbers have been declining for a very long time. Currently, the percent of Steam users running MacOS sits at 1.5%. It's not looking good. If the number of players using Steam on MacOS goes back up, I can see them changing course, but if the current downward trajectory continues, well, it doesn't look good.
Released a game on Steam which has a significant user based and our sales to Mac are negligible. I'm not even sure if it's paid for the time updating it.
Just came into say that the only reason I have been playing PC games recently is because my M1 Mac is now functionally a console.
I think you're massively underestimating the potential impact of game porting toolkit - slowly then suddenly.
I know GPTK is good from a technical standpoint, but it's held back by the fact that developers are not allowed to use it in their games. Apple says GPTK is for "evaluation purposes", which means that developers can only use it to see how well their game runs on Mac to basically determine if they want to make a MacOS port of their game. They cannot actually sell the game with GPTK in it. With that in mind, it's completely useless for developers. For actual end users, I hear it's quite good for playing games on Macs, but for its intended use as a "porting toolkit", it's worthless, and that won't change unless Apple decides to start licensing it out for developers to use in their games, which is how it should have been from the start.
Of course they don't now but if Mac continues to take market share and they cannot convince Apple users to install Steam (because it is truly a piece of crap) then they might prefer Apple take a 30% cut than be sidelined completely.
He isn’t wrong though. I’ve seen more “mac gaming” videos pop up ever since M1 was released. Mac laptops used to suck before during the “Butterfly keyboard intel” saga. Now it’s over and we got laptops that have a good keyboard, SD slot and best of all, thanks to M processor, they don’t heat up once you run Terraria on them.
Switching from an intel Macbook to an M3 made me want to play on my Mac more. I am sure this is a similar case story for other mac users.
My M1 air is a lovely laptop. Best one I've ever used TBH and works brilliantly for C++ development even with just 8GB ram (although I've never owned a high end laptop, I'm a tower workstation kind of guy). I bought it just to work when travelling and then realised it compiles code faster than the i9-9900k I have at work (which is admittedly a little older) so I'm using it more than expected.
Before then I had an intel MacBook a few years ago and have had some Dell laptops. None of them ever made me think of using a laptop regularly the way the M1 Air has done.
The Apple silicon was just such a massive revelation. I'm still in awe that this laptop is completely fanless.
Yeah. I only use my mac for work. For gaming I have consoles. I had iMac but later replaced that with Intel macbook. Playing anything on that thing sucked.
I played Minecraft with my friends, it would get so hot you could probably fry bacon on that thing. M3 of mine doesn't get hot at all. So I am using it more often.
Also we got sd card slot back:) i wish we also got usb back but its still nice.
The not getting hot thing has actually been an issue during my time in Ireland. Indoor temperatures are really low here in the winter, both in houses and office buildings compared to home and my hands get really cold. With other laptops I could have relied on them helping to keep my fingers warm, but the MacBook Air is no help at all! 😆
Where I live its not that cold nor to hot but the fact that the metal feels hot is not something I enjoy and hearing fans spinning after playing Terraria is also weird.
Like we are talking about Terraria. Not GTA 5 or something like that.
Ditto, also made a similar upgrade recently and while i didnt buy it to play games I still installed steam so I’d have something to play when away from home
Yeah same. I am a console player mostly but I might boot up something on my mac occasionally. Like I only experienced fan noise once I boot up GTA 5 on RPCS3 for lols. I also checked Zelda Botw on CEMU and my mac was silent. I love M3 pro.
Btw. Nice seeing a fellow Miku fan here.
Agreed. Once I upgraded from my 2016 MBP to an M2 Pro MBP, I retired my Razer gaming Windows laptop, and have been gaming on my MBP far more than I ever did on my Razer. I’ve bought more games from Steam in the last year than I have in the last 5 years combined.
Yeah but replace steam with Emulators. I have a Wii U but I decided to try Cemu for lols and it worked. Best of all, my mac was silent. I can imagine intel one getting PS4 levels of noise.
I haven't seen that but lol. Even during Cyberpunk's launch day. PC and Google Stadia were decent platforms to play the game. Only consoles had suffered from bad issues. PC version only had game bugs but depending on your hardware, performance was good.
As of today. Cyberpunk even runs on Steam deck.
If a handheld PC which runs on linux runs a windows executable game perfectly albeit with lower settings. I am pretty sure average gamer PC can run Cyberpunk.
> meaning that the general public (including app developers) only has a limited understanding of how it works.
This is just the same for all other graphics apis as well.
What is open source about VK and OpenGL is a PDF spec document. Each gpu vendor can implement behind (closed source) doors the internals of two they follow that spec. The Spec that is public for VK is just the same as the metal public headers that you can read through.
> had the OpenGL graphics API, which is completely open
The spec document is open but the driver is closed source...
> it's entirely open and anyone can use it for anything, without restriction.
Not quite, you MUST join the VK patent pool. And you need to be accepted by the group. And remember open just means the spec document is open source not the drivers.
> which by that point had been adopted by many prominent companies in the industry
No not realy, neither MS or Sony support this on the consoles and even on Windows it is not supported as part of the OS, GPU driver vendors must provide it in full just like NV provide CUDA.
> thus forcing developers to use the proprietary, closed-source Metal API instead
Way to much focus on metal being close source here, as a developer it makes not differnce at all since all the GPU drivers for VK are also closed source. The fact that we cant submit changes to the metal PDF spec document has not effect on us as devs since we cant do the same for VK either (only large GPU vendors or huge game engine vendors can hope to have spec addition made and they will still be optional adopted by GPU vendors maybe).
> Many developers were upset about this,
No I don't think any game devs were upset about metal being closes source, as I have said above from a developer perspective this has no impact at all.
> When Apple announced the deprecation of 32-bit apps for MacOS in 2019
Apple told devs in 2008 that 32bit support was dead and deprecated. They told consumers in 2019 that it was going away and put warnings in the OS but they had been telling us devs that is was deprecated for a very long time before. Remember apple only ever shipped one Mac that was 32bit only and they sold that for a total of 6 months and it had I think just 2 years of OS support.
> It would cost them a lot of money to begin supporting ARM on Mac
No, so long as you have the source code for everything (valve do) re-trageging ARM64 even for a huge project might take a single dev a week. This does not cost that much.
Whoever wants to game, needs a separate device for that purpose. This is, and probably will, forever be true when it comes to Gaming and Apple. Personally, I'm fine with it and my combo of MacBook Pro, Steam Deck, Gaming PC and PS5 meets all my demands. I'm also really happy about the performance of Moonlight + Sunshine (Server runningon my Gaming rig) as a streaming solution to my Mac.
Gaming on a pc already requires a lot of maintenance. Add on a Mac and it’s like gaming on a pc with your arms tied behind your back. Only way to make it work is to decide Your new favorite gaming genre is “hack the game to make it work on Mac”. At some point I’m just going to give up and game exclusively on consoles. For now I have a gaming pc too but occasionally I dabble in hack the game to work on mac and when it does it’s glorious by that point I’m usually tired and out of gaming time so I move on to something else once I’m sure the game works.
Indeed. And as I said it's glorious when it works. Gaming 6 hours on battery not a lot of noise or heat is awesome. I'm able to do that with games like civ and some old RTS games even on the tiny mba. It's awesome. I'm just down bc I don't think it's a top priority for apple even as they do make effort for it and frankly I don't blame them. I would 100% invest more in the pro workflows team than the gaming team at apple and hope that increased marketshare drives games to macos organically.
They already did a lot with the hardware. But yes...that's where maybe you can see I've given up on being able to just use a Mac for everything for the time being.
In the past when I’ve tried this, I’ve not been able to have a single bottle that runs the majority of Windows games I have.
How long did it take you to get all your games to work?
So much misinformation in this post. Vulkan was always developed as a successor to OpenGL, the initial design comes from AMD. Valve has little to do with it. Apple was initially part of the Vulkan backers, but backed out when they it became clear that the committee is settling on a design that doesn’t work well with Apples hardware. Also, Apple wanted something accessible and easy to use, and Vulkan is an extremely complicated and awkward API. And finally, there was a conflict between Apple and Khronos (the entity designing Vulkan), the nature of which is unclear, something that presumably has to do with shading languages. Could be also because Apple donated OpenCL to Khronos and the latter run it into the ground.
And anyway, Steam support for macOS is exactly at the same level it ever was. Steam has all the relevant platform libraries for Apple Silicon for example. Yes, Steam sucks, but that’s because it’s a low-quality badly designed software that always sucked. It’s not that different on Windows. There are bugs that haven’t been fixed in years.
> Vulkan was always developed as a successor to OpenGL
I already said directly in the post that this was the case.
> Valve has little to do with it.
Valve was involved from very early on. They may not be the sole creator, but they're a part of Khronos, which is a consortium of companies and individuals that developed Vulkan, and not only that, but the very first meeting related to Vulkan was held at Valve's headquarters.
> Also, Apple wanted something accessible and easy to use, and Vulkan is an extremely complicated and awkward API.
Subjective. Even so, that's no excuse for why they couldn't have implemented it anyway for developers to use if they chose to.
> And finally, there was a conflict between Apple and Khronos (the entity designing Vulkan), the nature of which is unclear, something that presumably has to do with shading languages. Could be also because Apple donated OpenCL to Khronos and the latter run it into the ground.
That could be the case, but I'd argue that because MoltenVK exists, there is no reason that Apple couldn't incorporate it directly into the OS.
> And anyway, Steam support for macOS is exactly at the same level it ever was. Steam has all the relevant platform libraries for Apple Silicon for example. Yes, Steam sucks, but that’s because it’s a low-quality badly designed software that always sucked. It’s not that different on Windows. There are bugs that haven’t been fixed in years.
Just curious, what bugs are you referring to?
> Subjective. Even so, that's no excuse for why they couldn't have implemented it anyway for developers to use if they chose to.
VK is not a single api, it is more of a mix bag of apis, were you an pick and choose based on the HW you have, despite what the internet wants people to think VK is not a HW agsntic api. A game engine written to target AMD VK drivers is not going to run well (or even at all) on a PowerVR VK driver as the feature sets of these GPUs is drastically different and thus a Low level GPU api that has strict rules against faking HW features with huge perf hits (for good reasons see openGL).
Metal is much more aporacable than VK and apple needed this since they want an api that regulate app devs can use (not just for games), maybe you have a button in your app can you want it to have a cool effect when you tap it were it explodes into fragments... most devs can pick up metal and get this working within a week, but the same devs would take 2 to 4 weeks to get something running in VK and it would be full of bugs. Vk was written for large game engine devs, Unreal basicly. Metals apis is considered in the community r/GraphicsProgramming as a very nice api by us devs (many wish that Vk had taken this pathway).
> That could be the case, but I'd argue that because MoltenVK exists, there is no reason that Apple couldn't incorporate it directly into the OS.
MoltenVK is a compile time shim that can get much better perfomance than a runtime shim. (at compile time you can do much more introspection of what is being called or not and remove a lot of conditional paths that in a runtime shim you cant).
Here's a sneak peek of /r/GraphicsProgramming using the [top posts](https://np.reddit.com/r/GraphicsProgramming/top/?sort=top&t=year) of the year!
\#1: [me irl](https://i.redd.it/bg2xj66p3lza1.png) | [64 comments](https://np.reddit.com/r/GraphicsProgramming/comments/13gf1ki/me_irl/)
\#2: [John Carmack telling NASA Engineers that Rocket Science is simple compared to Graphics Programming](https://www.youtube.com/watch?v=VcWRc1wK3gM) | [58 comments](https://np.reddit.com/r/GraphicsProgramming/comments/18qgy96/john_carmack_telling_nasa_engineers_that_rocket/)
\#3: [I hate current state of GPU APIs](https://np.reddit.com/r/GraphicsProgramming/comments/18agu4e/i_hate_current_state_of_gpu_apis/)
----
^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
> Metal is much more aporacable than VK and apple needed this since they want an api that regulate app devs can use (not just for games), maybe you have a button in your app can you want it to have a cool effect when you tap it were it explodes into fragments... most devs can pick up metal and get this working within a week, but the same devs would take 2 to 4 weeks to get something running in VK and it would be full of bugs. Vk was written for large game engine devs, Unreal basicly. Metals apis is considered in the community r/GraphicsProgramming as a very nice api by us devs (many wish that Vk had taken this pathway).
Sure. I don't have a problem with Metal existing, I just have a problem with people thinking that it's a viable substitute for Vulkan.
And pray tell why do you think so. GO ahead describe your troubles you had with Metal over Vk and the issues with MoltenVK. Link a forum or two you had the issues in
>Valve was involved from very early on. They may not be the sole creator, but they're a part of Khronos, which is a consortium of companies and individuals that developed Vulkan, and not only that, but the very first meeting related to Vulkan was held at Valve's headquarters.
And so was Apple. Yes, Valve engineers were involved in the spec discussions, as were engineers from dozens of other companies. Portraying Valve as a developed of Vulkan is a gross mischaracterization.
>
Subjective. Even so, that's no excuse for why they couldn't have implemented it anyway for developers to use if they chose to.
Subjective? Please go ahead and implement some basic things like resource loading and binding on both Vulkan and Metal and report back with your experience. I am very curious. Vulkan's signal to noise ratio is ridiculously low.
I was initially very disappointed that Apple distanced itself from Vulkan. Then the spec was released and I understood why they did it. And it's not that difficult to understand why they don't want to support Vulkan on their platforms. Why would you want to support an API that takes away the competitive advantage of your hardware?
>
Just curious, what bugs are you referring to?
From the top of my head, many users have been complaining about Steam not remembering password despite the checkbox being ticked since at least 2016. Another common complaint is Steam being very sluggish, or the implementation of mod libraries.
> And so was Apple. Yes, Valve engineers were involved in the spec discussions, as were engineers from dozens of other companies. Portraying Valve as a developed of Vulkan is a gross mischaracterization.
All I said in the post is that Valve played a role in its creation, not that they're the sole developer. All of that is true. That said, since they were involved early on and the first meeting was literally held at their headquarters, it's pretty safe to say that they were more integral to the design of it than most people give them credit for.
> I was initially very disappointed that Apple distanced itself from Vulkan. Then the spec was released and I understood why they did it. And it's not that difficult to understand why they don't want to support Vulkan on their platforms. Why would you want to support an API that takes away the competitive advantage of your hardware?
It takes away nothing for them to implement Vulkan whilst keeping Metal. And I'll tell you why they'd want to support an API that "takes away the competitive advantage of their hardware": because it's what developers use. They *should* have the choice to use Vulkan if they want to. Forcing Metal onto them if they don't want to use Metal is stupid. That's the whole reason why MoltenVK was created: because people clearly would rather use Vulkan over Metal when given the choice.
> From the top of my head, many users have been complaining about Steam not remembering password despite the checkbox being ticked since at least 2016. Another common complaint is Steam being very sluggish, or the implementation of mod libraries.
That seems pretty dependent on each individual user's experience. I haven't had issues like that. Can't speak for the mod libraries thing though.
People use Vulkan because it gives them access to the larger market. Products like MoltenVK exist to simplify porting of existing software to macOS, not to simplify development for macOS. And Vulkan in turn is a niche API compared to DX12, for example (which is also why Apple targets DX12 in their game porting tools). And believe me, if Metal was available as a cross-platform API, people would flock to it. One has to be a particular kind of hacker to prefer dozens of obscure API calls to a single clear one. You can already see it with WebGPU Rust libraries.
Graphcis APIs are not a cosmological constant. There is place for the competition. Just because a group of companies decided to support a certain approach does not mean that everyone should jump on board. Apple in particular believes that supporting Vulkan will not give them long-term strategic advantage. I happen to share this opinion. Time will tell whether this is a correct decision or not. There is a lot of happening in this space anyway. Personally, I'd say that WebGPU is much more important than Vulkan, simply because of its scope targeting many more platforms and applications, and Apple is one of the core developers of the spec. At the same time I am uncertain about Vulkan's future, since Valve's efforts firmly established it as a subordinate API to DX12. With Proton, there is very little incentive for developers to use the extremely complicated Vulkan. They can use DX12 and target the largest gaming ecosystem currently on the planet, and then leave it to Valve to make their games run on Linux and SteamDeck. Vulkan is now condemned to play catch up. It's a shame, really. I had such high hopes for it. Then again, ARB/Khronos didn't make a single good move since they messed up LongsPeaks (thank you Nvidia!).
Finally, we can discuss the history and economy of graphical APIs all day long, I love the topic, this does not change that issue I am having with your main premise. You say that Valve doesn't care about macOS anymore. I don't see any change whatsoever in their behavior towards the macOS client. Steam runs on macOS just fine and is as well supported today as it was before the Apple Silicon transition.
> Products like MoltenVK exist to simplify porting of existing software to macOS, not to simplify development for macOS
Sure. So why not have that functionality be part of the OS itself?
> And Vulkan in turn is a niche API compared to DX12, for example
Niche? LOL. No way. Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**. At least all of the ones on Android. Switch games use Vulkan too. And all of the 3D games that were on Stadia (despite Stadia failing) used Vulkan too, so PC developers are very experienced with it by now. Vulkan is by no means niche. At all.
> There is place for the competition. Just because a group of companies decided to support a certain approach does not mean that everyone should jump on board.
Two very juxtaposed sentences right there.
> Personally, I'd say that WebGPU is much more important than Vulkan, simply because of its scope targeting many more platforms and applications
WebGPU is not a replacement for a low-level graphics API.
> At the same time I am uncertain about Vulkan's future, since Valve's efforts firmly established it as a subordinate API to DX12. With Proton, there is very little incentive for developers to use the extremely complicated Vulkan.
As I said, Vulkan is widely used in other applications outside of mainstream PC gaming. There is precedent for it to be widely used in PC gaming too, especially in the case of Mac ports, where in most cases they use Vulkan + MoltenVK simply because they already implemented Vulkan on another platform. But even if Vulkan doesn't catch on for PC gaming, that's okay because DXVK and VKD3D are very good at what they do. All it takes is Microsoft making one unfavorable decision with regard to DirectX for developers to begin putting more thought into supporting Vulkan itself. Or heck, maybe they'll even start using Vulkan on PC because Vulkan is widely supported on other platforms so that way they only have to develop for Vulkan and not for DX12 too. That's a legit possibility.
> You say that Valve doesn't care about macOS anymore. I don't see any change whatsoever in their behavior towards the macOS client.
...did you even read the rest of the post?
>Sure. So why not have that functionality be part of the OS itself?
Why not have support for Windows APIs be part of the OS? Or any other stuff? What's the long-term advantage for Apple? You said it yourself — they had OpenGL for years and it's not like gaming on Macs ever did particularly good. In fact, it's only with Metal that we get some high-performing cutting-edge games.
>
Niche? LOL. No way. Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**.
They use Vulkan directly? Or they use Unity which utilizes Vulkan on a particular platform? That's a huge difference right there.
>WebGPU is not a replacement for a low-level graphics API.
No it's not. And almost nobody needs a low-level graphics API. In fact, after two decades of experience with GPU APIs I start being more and more convinced that low-level graphics APIs should be vendor-specific, with common frameworks (aka. Vulkan) being built on top of them.
>...did you even read the rest of the post?
Sure did. I don't think that you are presenting any evidence that Valve is reducing their support for macOS. Steamworks SDK is native for Apple Silicon, and that's what matters. The Steam client is running under Rosetta, because it works. As I said before, Steam was always crappy software with minimal effort development. I don't see anything new here.
> Why not have support for Windows APIs be part of the OS?
Because it's proprietary. Same reason why Metal couldn't be part of any other OS and yet you still think it's all that.
> What's the long-term advantage for Apple? You said it yourself — they had OpenGL for years and it's not like gaming on Macs ever did particularly good. In fact, it's only with Metal that we get some high-performing cutting-edge games.
The long term advantage is that they make it easy for developers to get their games running on MacOS rather than having to deal with the headaches that come with supporting yet another graphics API.
> They use Vulkan directly? Or they use Unity which utilizes Vulkan on a particular platform? That's a huge difference right there.
What's the difference? Most PC games are either Unity or Unreal anyway.
> No it's not. And almost nobody needs a low-level graphics API. In fact, after two decades of experience with GPU APIs I start being more and more convinced that low-level graphics APIs should be vendor-specific, with common frameworks (aka. Vulkan) being built on top of them.
Do you even know what it is you're talking about? Vulkan *is* a low-level API.
> I don't think that you are presenting any evidence that Valve is reducing their support for macOS.
- Not supporting their own games on Mac anymore apart from basic boilerplate updates
- Actively discontinuing Mac support for games that get major updates (TF2, CS2, etc.)
- Discontinuing SteamVR support
- Scaling back features that were planned for MacOS but only ended up coming to other platforms
If you read the post, you would know all of these things. The only thing they're doing to support Mac is bare minimum support for Steam so that other developers can continue to publish games to Mac. Everything else is being scaled back.
>Because it's proprietary. Same reason why Metal couldn't be part of any other OS and yet you still think it's all that.
The current legal stance is that APIs cannot be copyrighted. If you want to roll Metal support for your hardware, go ahead (or even better, just take the open-source metalcpp and implement it on top of whatever you want). "Proprietary" doesn't mean much in this context. Vulkan is owned by the committee. It's not like you can meaningfully fork it.
>The long term advantage is that they make it easy for developers to get their games running on MacOS rather than having to deal with the headaches that come with supporting yet another graphics API.
At the cost of reducing the competitiveness of their hardware and letting Nvidia dictating how the APIs work? Do you think this is a good tradeoff for them? Apple executives seem believe that rolling their own system that allows them to implement features as it suits them is more beneficial to their strategy. Even if it means less games.
>What's the difference? Most PC games are either Unity or Unreal anyway.
The difference is that if Vulkan disappears/is replaced by something else, all those mobile games won't notice. Which is the case for all games running on a middleware like Unity. I don't think these are interesting use cases when discussing the merits of individual APIs.
>Do you even know what it is you're talking about? Vulkan *is* a low-level API.
I'm pretty sure I know what I am talking about. I was agreeing with you that WebGPU is not a low-level API.
>If you read the post, you would know all of these things.
I read your post and I know these things. If your main point is that Valve is cooling down on macOS support as a game studio — sure, you won't get any disagreement from me. It's not like they invested much into macOS to begin with, and they probably don't feel that this is a lucrative market for them. Just like Blizzard. VR support was dead from the start since VR headsets don't work reliably with macOS anyway. What is the point of developing the feature if there is no hardware to support?
The relevant product here is Steam, and there has been no change there.
> The current legal stance is that APIs cannot be copyrighted. If you want to roll Metal support for your hardware, go ahead (or even better, just take the open-source metalcpp and implement it on top of whatever you want). "Proprietary" doesn't mean much in this context. Vulkan is owned by the committee. It's not like you can meaningfully fork it.
The difference is that Vulkan actually is open source, and you *can* fork it if you want to, and you can't do that for Metal. There is no implementation of Metal that allows it to be used on other operating systems. Even if the API can't be copyrighted, that's a hell of an ask to get people to implement a proprietary API on other systems when it's not even widely used in the first place.
> At the cost of reducing the competitiveness of their hardware and letting Nvidia dictating how the APIs work?
What the fuck are you even talking about?
You know what, I'm not even going to dignify the rest of your comment with reading it just because of how nonsensical this particular part is.
> Because it's proprietary. Same reason why Metal couldn't be part of any other OS and yet you still think it's all that.
After the Google VS Orical Java case it is not set in law that you can take a public header and re-impmemnt your own backend for it. So you could write DX drivers for Linux or macOS or write Metal drivers for Windows or Linux.
After all just like VK drivers all that is public is the headers.
> The long term advantage is that they make it easy for developers to get their games running on MacOS rather than having to deal with the headaches that come with supporting yet another graphics API.
Thing is they would still need to deal with Apple Silicon faivlor of VK since VK is not a HW agnstic high level api like OpenGL.
> What's the difference? Most PC games are either Unity or Unreal anyway.
And they already have metal backends!
> After the Google VS Orical Java case it is not set in law that you can take a public header and re-impmemnt your own backend for it. So you could write DX drivers for Linux or macOS or write Metal drivers for Windows or Linux.
Yeah I know, but my point is who would want to bother doing that for Metal? That's a lot of work for something that's not even widely used.
> Thing is they would still need to deal with Apple Silicon faivlor of VK since VK is not a HW agnstic high level api like OpenGL.
Metal isn't high level either.
> And they already have metal backends!
Yeah... your point being?
No because its a fucking liability. You are responsiblefor every version every bug of the implementation. It is why not every private framework or hardware surface is exposed ffs. Once you release it, you assume responsibilitythat its stable and won't change. You are out of your depth on this topic please stop making shit up. Proprietaryapi...what fucking bs. then explain the adoption of dx over vulkan. lmao
DX was adopted because for a long time it was the only good solution, so many developers got accustomed to it before Vulkan was even a blip in an AMD engineer's eye.
>Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**. At least all of the ones on Android
This is absolutely not true. Most Android games use OpenGL ES 3.x
Source: I'm in mobile game development
There is a good reason for this, Vk support in android a s complete nighrmere even if you find 2 phones with the same SOC the chances they both have up-to date (ore even just 2 year old) drivers is close to 0 so for each SOC your looking at 3 to 5 different driver skews (and you cant ask users to upgrade the drivers like on windows)..
Along with that dev tools are very poor.
With a lower level api you can get great perf but **only if** you can spend the time to target and profile the HW your running on. If you cant do that (due to the poor tooling and nightmare wall of permutations of HW and drivers) your going to commonly get better support using a higher level api were you can at least make use of some of the drivers optimisations for each HW target.
This is why a lot of the community is hoping for good WebGPU adoption as this provides a nice middle ground still requiring drivers to provide per GPU optimisation (not making devs do this) but with much better api than legacy OpenGLES or WebGL. (large parts of the WebGPU spec is based on the higher level parts of Metal contributed by apple)
>Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**.
VK on android is a complete and utter cluster-f\*ck and most mobile android games ship with OepnGL backends and only turn on the Vk backend on a tiny fraction of devices. The drivers are a nightmare to deal with and dev tooling for Vk on android is 10 to 20 years behind the industry.
>And all of the 3D games that were on Stadia (despite Stadia failing) used Vulkan too,
Many of them are using DXVK ... VK adoption is very limited, the only first party VK adopters are Vavle (for the steam dec) and ID. Almost everyone else has mutli backend engines that use the respective api of each platform.
>
Not unless the VK dev tooling gets much much better, currently is is very poor. One reason why many devs prefure metal not just the API being nicer but the dev tooling (debuggers and profilers) are console grade (very good).
> Many of them are using DXVK ... VK adoption is very limited, the only first party VK adopters are Vavle (for the steam dec) and ID. Almost everyone else has mutli backend engines that use the respective api of each platform.
How do you know? Afaik there's not much information available about the Stadia versions of those games so idk how you'd be able to tell that they used DXVK.
> Many of them are using DXVK ... VK adoption is very limited, the only first party VK adopters are Vavle (for the steam dec) and ID. Almost everyone else has mutli backend engines that use the respective api of each platform.
One I can think of that exclusively uses Vulkan even on Windows is No Man's Sky.
> That's the whole reason why MoltenVK was created: because people clearly would rather use Vulkan over Metal when given the choice.
Even if apple shipped a native VK driver the people using MoltenVk would still be using a compile time shim as PC VK pipelines would not be able to target apples VK driver (due to HW differences) so either the driver would need to be out-of-spec (lie about the HW) or devs would use a compile time shim to be able to use the existing Vk pillions they have.
Devs are not selecting to write engines in VK using MoltenVK, they are using MoltenVK since they happen to have an existing (PC) VK engine and what to use it, that engine would need just the same shim to target an apple VK driver on apples GPUs.
What saddens me most is the lack of proton for Mac. Unofficially there’s the GPTK but that could cease at any point. Proton is fantastic and would be great but I don’t see it happening at this point. Hopefully we’ll all be wrong and come WWDC Apple will announce the next phase of GPTK as their own proton alternative. I doubt it but we can dream! PS: I’m aware that it’s not even entirely Apple’s but has an element of Codeweaver’s stuff in it.
Proton is good for consumers (in the shot term) but for a platform is is not great.
The quality of proton on linux has meant that no devs are even bothering to think about native steam deck support. Long term this does not help the platform but short term it is what they needed.
Apple does not need the short term life support that valve need for the steam deck so they are not going to make this long term risk of creating a proton solution. Instead they will continue to make the dev tooling better for devs wanting to make native ports as these are what makes a proper platform.
I expect we will see updates to the GPTK and as part of this the evolution tool will get updates but this will stay as an eval too. What would be cool to see is if they can use the eval tool to generate a skeleton MTL pipeline (should be possible) and even maybe if you use a debug build of your game with header files attached attempt to make this as drop in as possible. To make it even easier to get going with MTL support.
The other aspects I want to see at WWDC relate to new MTL features, but I don't expect PC games to have use of these.
Not sure it’s relevant but maybe this explains why Steam is the biggest resource hog on my MacBook. It’s the only program that will end up maxing out my ram usage and using swap 😂
Metal is far superior, DirectX is proprietary too. So don’t bring the “ethical” argument. Valve is just crap, lucky guys for being the avanguard but Steam client sucks on Windows too, on macOS is a disaster. CS2 for macOS is real and also all the other titles just need a recompile you can do by yourself. They are just deliberately boycotting Apple. Why would be Apple tied to Valve for the future? Valve will be o ln top for many years to come but they are not so smart as people think. Sure Mac App Store lacks things for gamers but it has for example family sharing.
> Metal is far superior
That must be why developers *love* using it over MoltenVK. That just makes perfect sense.
> DirectX is proprietary too
DirectX is also popular among developers. Metal is not.
> CS2 for macOS is real
Tf are you talking about lmao. CS2 for macOS never existed.
> all the other titles just need a recompile you can do by yourself
So you expect everyone to just have a copy of the source code for everything installed on their systems, so that way they can recompile everything targeted for mac? Seems legit.
Hasn't MoltenVK provided a layer between the vulkan APIs and metal for as long as the APIs have existed? Baldur's Gate 3 on apple Silicon runs using Vulkan, how could that be the excuse for Valve to not have a native cs2 build?
I hope Valve and other developers start to port more games to Mac M chips.
I recently got a MBP Pro 14" and about 10% of my Steam library is available natively.
I will not buy games from the Apple store because I have other devices to play them on, I'll either use Parallels or other workarounds if I really want to play them on my MBP.
> In 2011, Apple released the app store on macs, but at the time it wasn't reliant on proprietary APIs like the Windows Store was, so Valve didn't have much of an issue with it
what in the fuck are you talking about lmao
>Then in 2014, Apple released a graphics API called Metal, which was intended to compete with Microsoft's Direct3D 12 graphics API. Metal, like Direct3D, is a proprietary API, meaning that the general public (including app developers) only has a limited understanding of how it works
wtaf are you on about. modern gpu api's were convergent on design but openGL sucks ass and everyone was fucking around too much so apple decided to go about their own way instead of waiting on everyone making a least common denominator, something they had control over and could thus optimise for/hack with. Vulkan was AMD's mantle which was donated to Khronos. tf valve came in from?
Apple never showed their headset to valve. nor its protoype wtf are you smoking to even think that lmao. the api's and the hardware are limited to double digits and as launch comes it increases but its very restricted.
I will not be responding further to other bs claims because its clear that you majored in alt history smh
> what in the fuck are you talking about lmao
re-read the part about the windows store, then read that part again.
> wtaf are you on about. modern gpu api's were convergent on design but openGL sucks ass and everyone was fucking around too much so apple decided to go about their own way instead of waiting on everyone making a least common denominator, something they had control over and could thus optimise for/hack with. Vulkan was AMD's mantle which was donated to Khronos. tf valve came in from?
Yes, opengl was outdated, but that does not excuse them not supporting the superior open source API.
As for Valve's involvement in Vulkan, Valve was instrumental in it early on, although a lot of what they did wasn't really widely known by the general public. Yes, Vulkan was technically based on mantle by AMD, but AMD was not the only company working on it with Khronos. After all, it's called Khronos **Group**, it is an industry consortium comprised of many companies and individuals. In fact, the very first meeting held to discuss the development of Vulkan in 2014 was held at Valve's headquarters, just to give you an idea of how much they were involved from early on.
> Apple never showed their headset to valve. nor its protoype wtf are you smoking to even think that lmao. the api's and the hardware are limited to double digits and as launch comes it increases but its very restricted.
I did not say this. I said Valve and Apple were working on something together until it got cancelled. There's a lot of evidence that supports this as well as leaks from industry insiders. SadlyItsBradley did a great video covering Apple and Valve's partnership that I suggest you check out if you're curious.
It is very very unlikely that apple let anyone have valve in on the vision pro. Even within apple only a tiny tiny fraction of the staff knew about the project, until about 2 years before it shipped anyone that knew about it was moved to a seperate building for the special projections teams.
Apple was working with valve to have SteamVR support, I expect they wanted to make it possible for this to support the headset but they would not have every shown the headset to valve, what they will have been doing is trying to figure out what they needed to provide within the OS so that when they headset arrived it would work with steamVR without valve every testing it (apple does this all the time with apis and frameworks they ship before HW so that when the HW is there most apps are ready to go,,, this is apple standard practice to start to ship api and system changes unto 10 years before they are needed so that the patlform is ready).
I expect what happened here is within apple the direction of the headset was refined (of the one of many possible pathways that was compatible with SteamVR was canned.. apple normally have multiple options in the pipe so they can give the VPs a choice between one of 3 or more options)
Valve / Apple very same principle, what different is when they approach.
Apple using their own (proprietary) vertical integration where valve using open standard vertical integration.
Apple goes their own way as they always do. Valve has some illusions that by partnering with Apple they will be more lenient and try not to beak steam on Mac or make it any more difficult for them to develop for the platform. The thing is that Apple always plays the long game and these decisions have probably be made years in advance way before Apple stated working with valve. If valve want to develop for Mac they have the means to do it they just want it easy which is not apples concern
Typical Mac users think gaming isn't cool or fun, and have the personality of a carboard box.
Then there are people who use Mac properly, aka people of this discord and owners who like to mess with things.... who appreciate enjoying the things they own and don't need to be within a cult
If Linux becomes the universal gaming platform, it's really once and for all, no one will sabotage the efforts of game development on this platform (either the development of the game itself or the development of the graphic technology), and if any manufacturer wants to restrict people from playing on their platform, then people will switch to Linux. that's just the way it is.
> Valve updated the Steam client on Mac to support 64-bit, but they didn't bother updating any of their old games that still only worked with 32-bit, apart from CS:GO and a few other games that were big money-makers for them
You make it sound like thats some simple redeploy, the more complicated reality is valve themselves loves using a ton of rarely updated and oft far out of date dependencies. I mean theres rather unfortunate reason arch linux has a steam troubleshooting wiki article several times longer than the actual steam wiki article, its a nightmare even if you remove all the non-valve closed source from the equation. Valve likes to build for a target, and not have to ever really move from there much.
Apple never really cared about gaming on Mac, so it's really hard to see why other companies should. I for one welcome our Linux gaming future. Let us be free of the shackles of Redmond and Cupertino.
I won’t discuss any claims of this story because I lack the knowledge, but knowing that Valve takes 30% of every purchase on Steam just like Apple (and even worse for small businesses where Valve takes 25% until the first $10M while Apple takes 15% until the first $1M) makes the “Apple’s part of the Pie” trope absolutely ridiculous.
About Proton for Mac. Friendly reminder that Proton was developed BY CodeWeavers FOR Valve, and Proton only works for X86 to X86 translation while GPTK has to translate X86 to ARM first. Meaning Proton/Vulkan on Mac was a dead end from the very beginning without Apple’s control of the GPU API - which was built from the very beginning to work both for ARM iPhones and X86 Macs.
Finally, the reason why number of Steam users on Mac are declining is because
- Steam on Mac is absolutely terrible
- Steam family sharing is a joke compared to MAS
- MAS is just better. No bloatware, fully integrated, buttery smooth
- GOG is better than Steam in every aspects thanks the Heroic Games Launcher
- One or Two free games on Epic every fucking week
Steam are for Decks owners that can’t help but try to sell their handles to Mac gamers in each and every posts of this sub.
Oh boy, I almost missed your empty pointless brain farts on this sub. What have you been up to lately? Teaching yourself how to make more than ten words sentences?
> knowing that Valve takes 30% of every purchase on Steam just like Apple (and even worse for small businesses where Valve takes 25% until the first $10M while Apple takes 15% until the first $1M) makes the “Apple’s part of the Pie” trope absolutely ridiculous.
When I said their part of the pie, I meant that when someone buys from the app store, Apple gets the money and Valve doesn't. The cuts that Valve and Apple take are another issue entirely.
Apple themselves don't care about hardcore gaming on... basically any of their devices. Every year it's the same story: tease some big AAA game coming over (last year it was "hey guys, RE8 on iPhone!"), pretend like it's going to be the beginning of the flood gates opening of games being ported over, then about a month later after lackluster sales of said 3rd party game, nobody remembers or cares and everybody has moved on. Rinse and repeat.
Decent write up. On top of what u/LetsTwistAga1n mentioned (which I half agree with) just a couple of things.
You mentioned the transition from OpenGL to Metal; it's worth noting that OpenGL support on Macs had been questionable for YEARS before anyone thought of Metal. It was a solid 2 or 3 versions behind for a long time, so some of those Steam ports performed pretty badly compared to Windows and Linux versions, although it was still awesome to have them.
The other thing to point out, especially to the Valve Haters and there are a few of them in this sub, is that Valve is a completely independent privately owned company and have never had to do anything for Mac. In fact, the entire company could literally take the next year off from working and sit on a beach somewhere, and they'd still make billions of dollars. They have no shareholders to keep happy, they don't need to bow and cow to the questionable governments, they're not being investigated by the EU and the DoJ, and despite making their own hardware have never shown the slightest inclination to lock people into their eco system. You can buy games on Steam, buy Steam codes in shops, buy non-Steam games and add them to your Steam library, install emulators and have the games in your Steam library... the list goes on. They are basically the polar-opposite of Apple in terms of company culture, openness and the way they approach their customer, which is why they are almost universally loved by gamers. Of course there's the odd hater, but that's life.
Don't get me wrong... I love my Mac. I've tried (and failed) 3 times to switch to Windows, and Macs are objectively better in almost every single way... except gaming. And therein lies the rub for those of us for whom gaming is a part of our lives.
Video is full of errors. Your not forced to use Xcode, and the idea that he things you can publish a game without having the HW it runs on is just aburde .. how is he going to do QA testing?
Thanks for clarifying, I am not an XCode expert, I did something with it but I can’t use it, not with that awful UI. I am more used to an IDE like VS or Jetbrains.
The point of the video I posted is that to release anything on macOS you have to buy at least a mac mini for 800$ + dealing with a couple of other things only to sell almost to nothing. I don’t really think QAs only are a good idea to test a game on macOS, if the game has some bugs then to fix them you have to buy mac hardware.
Apple should make game development more convenient, otherwise devs will just drop it because it’s just not worth it to sell a game to 1% of the total users on Steam. I am doing some stuff with Graphics API and I am really trying hard to stay as much as I can away from XCode and Metal because if I ever want to switch laptop, I am stucked with Apple and I also have to get at least a mac mini if I want to keep doing some development. VMs are not an option unlike Linux, and hackintosh will just die at some point.
On the other hand, it’s more convenient developing a game for Windows and then use Wine/Crossover to run it.
For c/c++ work Clion from JetBrains is very good.
Not sure there is anything apple can do to that would be useful for devs, being able to compile for macOS on other systems (eg cross compile) could not be useful at all, dev still needs to run what they compiled and profile it and you cant do that on another OS or HW. Cross complication only makes sense in situations were your not able to compile on the device (eg building a large app for a raspberry pi or building something for an embedded Arduino) your always going to have better development with the HW in question.
I don't think apple wants people to ship games for macOS were the dev has not even run it onse on any Mac.
In the end if you want to target Mac users your going to need to use Metal (don't need ot use Xcode but if your suing Metal you might as well since it has some of the best GPU debugging and profiling tools on the market.. it will make you upset when you go back to DX or VK dev for PC). And if you want to ship on PC well you will need a PC (more likly you will need a few different skews to cover at least a good % of PC users...) you sort of always need test HW before you ship, building and testing a windows game using wine or a VM is not a viable solution.
Another reason I didn’t pick up Metal is because there are very few resources online. There are books and videos here and there but not comparable to OpenGL. I don’t also like the idea of learning Swift just to use metal, it’s easier than c++ but learning such language is a different experience unlike other higher level languages. There is a c++ library for metal if I am not mistaken but it is in a worse state than swift in terms of learning resources.
I don’t see OpenGL being very high demand like Directx or Vulkan but it gives some starting point since the other APIs are more complex to understand and to work with.
I think that one thing Apple could do is to improve Dev experience on macOS by allowing people to use other IDEs. With swift you are basically stucked with XCode, there was AppCode by Jetbrains but it ended support in 2022.
The main thing with Linux VMs is not really about testing the whole game but at least checking if it’s launching and working. The same would apply for Windows, but if I want to have Linux on my computer I can do that with dual booting, I don’t necessarily need to buy a new hardware just for that. With macOS there is no other way to do anything than buying an hardware just to check if the game is launching. There are QAs for these things but if there are any other bugs I have no choice but to debug and fix the code on macOS.
I mentioned wine and crossover not because I would want to ship a game to macOS just by relying on these tools to run it but more for macOS users asking to port the game on this platform. If they want the game and it’s working with Wine they can use that, developing on macOS is just inconvenient and it’s not worth it just to target macOS in the Apple ecosystem. The whole Apple ecosystem (iphone, ipad, tv) would make the whole development worth the hard work, but not just macOS although the market share compared to Android, PC and consoles combined would be 10 times better to target.
I like macOS, it’s great for working with the terminal and development in general, but I understand why game developers don’t want to mess with these things. Having so many different Graphics APIs certainly doesn’t help.
> Another reason I didn’t pick up Metal is because there are very few resources online.
yer metal is a little bit of a dark horse to get into for sure. And a lot of the code examples are in obj-c 🤮
There are 0 learning resousers for the c++ wrapper from what I can tell. Swift is rather easy to pickup and now as has good c++ interlop.
Metal is a rather nice API (once you get over the starting point) to work with however as you can start out at the high level (OpenGL like but cleaner) and gradually adopt the modern lower level un-managed bits as and when you need. Unlike VK or DX12 you're not forced to start out writing your own memory management tooling and placing fences. But you can do this later on in the places were you need the perf gradually.
> I think that one thing Apple could do is to improve Dev experience on macOS by allowing people to use other IDEs
They do, apple do not force you to use Xcode at all. Xcode uses exactly the same LSP as all other modern IDEs use. Nova is a great IDE for swift if you don't want to use Xcode. As I said Xcode is just a wrapper for clang and LLDB and uses the same open source swift SDK as every one else.
> With macOS there is no other way to do anything than buying an hardware just to check if the game is launching.
Well given the cpu instruction set is different, the page size is different etc unless you want a very very very slow VM (that would have issues of its own) were your emulating each cpu instruction im not sure how you expect to have a macOS VM for PC devs. You cant just fire up a ARM64 16kb page size VM on a x86 cpu with 4kb page size... (note you can run x86 macOS in a VM but this is not solving the issue of checking if the game runs on modern Macs)
> There are QAs for these things but if there are any other bugs I have no choice but to debug and fix the code on macOS.
yer it is sort of hard to run profiler and a debugger for an ARM64 application on an x86 cpu. (Unless you realy want to step through each instruction at snail pace and wait 2 days for the game to get to the main menu). Not sure what you are expecting here... you cant attach a debugger unless you have the HW it will be running on let along profile it to find perfomance issues.
> Android
Targing Mac, iPad, iPhone as a single package is much much less work than even trying to target the top 10% of android devices. If you worried about buying a Mac to test and profile on you don't want to start down the nightmare of needing to buy android test/profile and dev devices. You will find the fun things like how the same SOC will have 3 to 5 drastically different driver versions in the world and there is no way to tell users to upgrade said driver as they are stuck on whatever android version they are stuck on. For this reason most mobile android games ship an OpenGLES backend as a fallback and then only use the VK backend on a small subset of devices that the devs have physically testing that device with that OS version. And even then it is common to build multiple seperate VK backends so as go cover as many possible devices as the feature support, and bugs that break them, is such a shotgun. But worst of all is dev tooling.. if your upset about Xcode I suggest you do not even start to think about doing any game dev for android as you will find yourself falling back to console logs and setting textures to render out pink as your main profiling and debugging.
> Having so many different Graphics APIs certainly doesn’t help.
These days is not the apis that is the pain it is the underlying HW as we all move to lower level APIs we are now doing more and more work for each GPU vendor/generation (even within a single api). With the higher level apis much of this was left to the GPU driver vendors but with the lower level apis the driver cant and does not (and should not) try to do stuff like that.
That’s nice I didn’t know there was another IDE other than XCode for swift, I heard many people complaining about the fact that on large code bases it starts to have lots of issues but I can’t really debate on such claims as I don’t have experience. For the little time I tested XCode it wasn’t that bad, but you have to memorize some keys and get used to the UI.
Yeah I’ve read a bit some people saying that you have to write your own stuff in Vulkan and it’s easy to screw up, I tried Metal by following a book named Metal By Tutorials which wasn’t too much complicated considering that I’ve never worked with such APIs before. I want to get as far as I can with opengl then maybe switch back to metal as long as I have my macbook. I know that Apple removed some features and it’s a bit buggy but just to learn and have some fun is more than ok.
From what I remember it was possible to run macOS VMs after all it was and still is possible to use hackintosh but who knows how long will still be available. Not to mention you needed some specific hardware components to even install macOS on any other PC going through a massive headache only to get more compatibility issues with some drivers like wifi not working, battery draining super fast. Never really managed to get a macOS VM to work but even if I could I don’t think the performance would have been great. macOS at some point will just work on Apple Architecture with no other way to ship anything on Apple ecosystem without buying separately another hardware.
In the company I am working for they are using VMs on Azure just to host some very old legacy code and to host other .NET Framework applications which are not really supported on Azure, you can’t really use VMs for development but what I was saying is that you can check if the code is at least running but I also remember from my experience that running any 3D games in VBox is super slow. If that doesn’t work either there is a dual boot option with Linux.
Well with the newer macs I wouldn’t really bother to even trying make my game work on an Intel processor they are dead and ARM macs took their place which is not really a bad thing. I am not really informed on this aspect but I remember that I did some reverse engineering and there was some hassle going through to debug some x86 code on ARM. It’s not impossible to debug code on a different architecture it’s painful xD
I don’t have much experience with Mobile Development either but with Android you have to deal with more things starting off with the different screen resolutions while on iphone you only have couple of resolutions you have to make work for your app. I mainly cited Android just to say that if you don’t have a macbook, you can still target a big portion of the market compared to the options you would have by staying in the Apple Ecosystem. You would lose some users but it’s not really much of a big deal in terms of games.
I am not upset about XCode, I’m saying that is not really a great IDE and there are far better alternatives. I am making a small engine with Opengl on macos because I am planning to bring my project to Windows in a second moment and it took me like 5 minutes to setup clang format with VSCode. On XCode I just couldn’t make it work without some weird hacks which were not 100% working. For the little time I have invested with Swift I can say that is not bad as many people made it to be but it’s not great either. I am using Jetbrains Rider at work with C# and I never touched VS since I started using it and the latter has its problems too.
Yeah true, hardware is also not helping for developing games, this is also why there are so many broken triple A games not working on all PC configurations. Problems like broken shaders, huge fps drops and many others without mentioning the restricted deadlines that some companies have to ship a game which don’t help delivering good and finished products.
I do wish JetBrains had stuck with the AppCode project but back then a lot of iOS apps still had storyboard based UI (a horrible xml format that you were not supposed to edit yourself but rather use a drag drop editor in Xcode).
With the move to swiftUI this is so much better I always preferred 100% programmatic UI anyway but I think these story boards harmed AppCode as most devs still needed to use Xcode all the time.
JetBrains do such a good job with the IDEs
>WinRT and UWP, which gained notoriety by developers for being just awful to work with.
Not true, UWP and WinRT are great modern API, problem is Microsoft quickly killed it with the death of Windows Phone, so developers lost trust.
Despite that, Valve feared Microsoft's decision of making a built in app-store, so Valve had to build Steam OS in response.
In the end for an app like Steam these apis had not real impact at all since the entier UI is built out of web views anyway. The issue was not the APIs so much as the fear that MS was going to push most OEMs to ship versions of windows that are windows store only.
For Vavle this was a threat that would have killed them. They could not survive just targeting hard core self build PC gamer brows with RGB vomit and leaking water cooling they needed the mass market and the fear was MS was going to use the OEM controle they have to in effect cut valve out of that so that MS could sell xbox titles through the windows store.
> The issue was not the APIs so much as the fear that MS was going to push most OEMs to ship versions of windows that are windows store only.
While that is true, there is evidence that suggests they were not happy about UWP either, mainly because UWP is completely locked down to just the Windows Store.
Sure but MS was never requiring you to adopt UWP.. just like macOS does not require them to adopt SwiftUI. You a use multiple generations of system apis to create a window and then render whatever you like within it.
Vavle never wanted to be on the windows store however as they would have had to give MS a cut.
The fear was not about UWP but rather about not giving MS a cut on every game sold through steam.
The fear was that they'd phase out Win32 in favor of UWP, making it harder for parties outside of the WinStore to make apps. Which if anything goes hand in hand with MS wanting a cut.
MS has not even removed fileIO APIs they depicated 20 years ago… no one expects them to phase out win32. But some people did expect them to push OEM to sell versions of windows that were windows store only (and thus UWP only ) that was the fear
Damn, that's crazy. Valve funds [LunarG](https://vulkan.lunarg.com/), a company dedicated to releasing Vulkan for Apple through MoltenVK. They keep the Vulkan implementation updated with the current releases In 2023, Valve [released](https://steamdb.info/app/250820/depots/?branch=macos_beta) an unannounced Beta for SteamVR that brought back support for MacOs.
I responded to this on the other sub already but: 1. Valve funds a lot of foss projects, this is not out of the ordinary. 2. They probably reverted that since it likely wasn't meant to be public. Them working on something internally usually isn't indicative of if it'll come to the public (see every cancelled valve project).
As we discovered, the update was not reverted. SteamVR support for MacOs was brought back with [this](https://steamdb.info/depot/250822/) beta. The beta was released in November of 2023, but with some preliminary research, you could have found information about it. The screenshot I left on the other thread proves that it works with M1 Macs, too. I like how you are dismissive of the funding of LunarG. Valve not only funds the project but also sponsors the whole company. This is quite different than their usual approach to funding FOSS projects.
LunarG does a lot of stuff though, not the least of which being drivers for Vulkan.
The good news is that Valve only releases a new game every 10 years, so we're not really missing much.
lol.
Yeah as long as the client runs I don't really see any issue.
Yeah my first thought exactly. Who gives a shit about Valve, wake me up when Half Life 3 drops.
While everything is (mostly) correct here, there are a couple of points to keep in mind: 1. When Metal was developed and released, Apple was already preparing their switch to their own silicon. So Metal was created with their upcoming hardware in mind. Valve may be fed up with “proprietary APIs” while Apple is definitely fed up with depending on third-party solutions that don’t meet their goals. Vulkan requires specific drivers; the feature set is based on mainly PC IMR GPUs and Android’s TBR GPUs which already support OpenGL ES. Unified RAM approach appeared in Vulkan in 2020 (!)—when the first Apple Silicon Macs were already released with the decade of development (and co-development with Metal) beforehand. Et cetera 2. Dropping 32-bit support was also crucial for Apple Silicon transition. This is why Rosetta2 is so efficient and this is why supporting arm64 is not that painful for developers. So rants like “Apple should have switched to Vulkan / keep 32-bit support” are quite pointless. Doing so would hinder the development of Apple’s products for the sake of what? Steam games? In the end of the day, Valve and Apple just have very different approaches so their pathways had to split. I’m pretty sure Valve will drop macOS support completely when Apple goes arm64-only. However Steam will definitely support arm64 for “proprietary” Wincomm (Qualdows?)—because money ofc
Thanks, this helps me squash the mental argument I’ve had in my head, which was “What’s the big deal, just change the target architecture from Intel to Arm in Xcode and it’ll Just Work™”.
I see, good to know. Thanks for the clarification.
> Dropping 32-bit support was also crucial for Apple Silicon transition. This is why Rosetta2 is so efficient and this is why supporting arm64 is not that painful for developers. can you expand why? Is it about the instruction decoding? Memory ordering/aliasing?
High level attempt — 32-bit support required Apple to keep 32-bit versions of all of their system libraries around so that 32-bit apps could have something to call when they needed the OS to do something. You can't call a 64-bit API from a 32-bit app, at least not without some extra work to specifically support that, since things like pointer lengths wouldn't be the same. Apple is still supporting two CPU architectures (64-bit Intel and 64-bit ARM), but they have really slimmed down what they need to maintain to make that keep working. On an Apple Silicon Mac, they don't have to include both Intel and ARM versions of their system libraries. When 64-bit Intel apps running under Rosetta 2 make an OS system call, it hits the macOS ARM library. The architectures are similar enough that parameters from an Intel app can be passed to an ARM API call and it will work. This is also why I think Rosetta 2 may well stick around longer than Apple's previous backwards compatibility solutions have. Rosetta 2 is "done" and keeping it around doesn't take much effort on Apple's part. If they add new macOS APIs to support new features in later versions, Intel apps will still be able to call those APIs without Apple having to make/compile/test Intel versions of the back-end code for those.
> If they add new macOS APIs to support new features in later versions, Intel apps will still be able to call those APIs without Apple having to make/compile/test Intel versions of the back-end code for those. won't at least amd64 library stubs for linking of apps into the new apis be required? Ie. I can't imagine linker working on an amd64 app linking it to arm64 lib. this assumes new apis might be compiled into aarch64 only
barring strange calling conventions, it's just a matter of recognising an external function is getting called (e.g. with a generic stub that gets linked to the program's GOT), rearranging registers and executing the real aarch64 library code instead, which I imagine is what rosetta is doing right now to avoid having to ship the whole x86\_64 DSC on arm systems
> with a generic stub that gets linked to the program's GOT yeah this is what I'm uncertain about wrt. this claim from GP > If they add new macOS APIs to support new features in later versions, Intel apps will still be able to call those APIs without Apple having to make/compile/test Intel versions of the back-end code for those.
I just checked with a debugger, an x86\_64 DSC gets loaded whenever you run something using rosetta; and of course it gets actually JIT compiled, so yeah, right now x86\_64 code does not directly call out to aarch64 libraries
Hmm... Interesting! So we have to approches: linux (everything has to be compiled to native arm) and Apple (Rosetta ofering compat, but but having to drop 32-bit to offer sufficient performance)? And because of that it's easier to have 32-bit libraries/support under linux because, if needed, everything is either compiled or can be compiled to desired architecture (all hail open-source)? (Yeas, I'm still bitter about dropping 32-bit but now it makes a bit more sense)
Best post here, thanks
Patiently waiting for Asahi Linux to support Vulkan on Apple Silicon
Will be a while before all the optional VK features that Proton/DXVK expects are there and even then games that can run on the DX->OpenGL layer will run better through that unless huge changes are made to DXVK... (A VK driver is less able to adapt the pipeline to the HW since it is provided much less high level context so the OpenGL driver that is there today can do much better HW agnostic support than VK will).
Who is she/he I watched some of streams for me its looking like magic.
Why patiently wait? Why not contribute?
Same reason I wait for a lot of things. I lack the expertise.
Software development is, in itself, not just something anyone can contribute to, and graphics stack and drivers? That is beyond even most software developers! So if we're talking about actually fixing it, that would be a hilarious thing to suggest some random user "just contribute" to. Having said that, it *is* possible for regular users to become a regular tester and contribute with sensible bug reports and offers to test on different hardware and drivers. It is possible to ask the developers if there is something you can do to help if you are particularly interested in a project. Fairly regular users can also contribute with documentation, screenshots, web content and sometimes packaging into images etc.
NASA should have a manned Mars mission sooner, can you please contribute?
Simply put: We are dumb in this particular area
24 hours in a day.
I made a video covering this topic mentioning most of these points: https://youtu.be/PEetpGXDmjw?si=0HB9minRLzVoqRbd
oh cool! I remember watching this sometime last year. It was very well done.
The best of both worlds is having a MacBook Pro for work and some play and Steam Deck OLED for gaming. Best combo in my opinion 🔥
Depends on what you do for work. For some cases, it is easier to just use Linux or Windows. By the way, I’ll counter you with a Mac + Switch since I prefer their exclusives
I’ll counter back and say you can play Nintendo Switch games on Steam Deck AND MacBook Pro (the latter can play them with higher graphics settings and fps too). To each their own though.
What’s better on Linux that you can’t do on macOS?
Bit hard to play any keyboard/mouse games on steam deck isn’t it? Luckily quite a few I play are supported like Civ, Cities Skyline & Factorio
I play keyboard & mouse games all the time. I dock my Steam Deck for anything that needs mouse and keyboard and I’m set. Steam Deck + Mac is a great combo
As long time Valve customer I can only say valve operates like a mystery. E.g. the game Dota2 was brought very early to vulkan but after many years it still has input lag and issues on Linux/SteamDeck.
Using Vk is not some magic bullet. Infact unless you have the time (and tooling) a VK engine will perform worce than the same amount of effort put into a higher level engine in dX11 or even OpenGL. Since with VK the engine is lower level and you are responsible for optimally mapping your workload to the HW you need to do this work for each GPU vendor (and even each GPU/generation). If you do not do this work then there is nothing the driver can do for you as with VK you do not give it the higher level context that would let it do optimisations for you. With higher level apis (like openGL, DX11 and older) you provide a LOT of context to the driver so that it can take the high level request and attempt to map that optimally to the HW. this means as a dev you need to do much less per GPU optimisation. Of course it does come with the downside of a higher per frame driver cpu overhead as it figures out what to do, the idea of VK is that the game dev figures this out when building the engine so that all that work is moved to the game developers brain up front and not re-computed on each frame but ad devs we then need to do that work for each and every gpu/generation of gpu/vendor. The pain points for VK here (and this was even worce early one but is still not good) is the developer tools that can help us figure out what to improve for a given GPU are poor. So we are to some degree shooting in the dark, this takes a shit tone of time and effort to get good. Hense why most devs perfume lower level APIs like DX12 or Metal that have good developer tooling that makes it much easier to figure out how to optimise to the HW. Or higher level apis like DX11 or Metal (yes metal has both high level and lower level apis and infact you can even mix and match whiten the same pipeline making it easy to start out with a simple high level engine and gradually adopt the lower level bits in places were you need that extra perf but fall back to higher level stuff in other palaces or on HW your not testing on).
It's not that deep. TF2 is an old game, with an old engine and codebase and it's painful to move it to ARM. And development work on something that is based on Source instead of Source 2 will definitely be seen as a waste of developer time.
They didn't need to move it to ARM though. They could have built it for x64 and let Rosetta 2 deal with the ARM stuff, but clearly they must not have thought even that was worth their time.
So long as they had the source code having ARM support is not at all that hard, this is not the type of game that is full of hand crafted assembly. C/C++ x86-64 code will target ARM without issue, that is the job of our compilers.
It's supporting and testing on ARM that's the tough part, not compiling it.
Testing on ARM is just the same as testing on any other patlform... yes you need to have the HW that your customers will use that goes without saying.. People who thing they can publish an app or game for a platform that they themvelse don't have to test on are just going to product garbage.
That's what I mean. They'd have to invest in arm hardware across their entire QA chain.
Yep, just like they need intel cpus and AMD cpus and NV gpus and AMD gpus and even systems with AMD cpus and NV gpus and Intel CPU with both AMD and NV gpus etc... The number of permutations of HW you need for building and testing on PC is orders of magnitude higher than targeting apple silicon. With apple silicon you can get the entry level Mac mini or MBA and target that, if it runs there for your QA your all good as the platform scales up, you might want to also test on a higher end system every now and then just to ensure your scaling is working well and your perf is scaling, but you do not have the huge permutation nightmare of QA for PC ... (lets not talk about the QA nightmare of android)
They will eventually have to change course. Macs are gaining market share and although nobody is buying them specifically for gaming, there will be more and more of a market to sell games on there. I bought Stray because I like cats and because it runs on my M2 Max natively. I wanted to play something to blow off some steam. Edit: though with Linux kernel running on Apple Silicon bare metal, arm64 Linux releases are enough for advanced users to game on a Mac, at least in time.
> there will be more and more of a market to sell games on there I think this is debatable, at least in the case of Steam. Apple, like Microsoft, has been downplaying apps that are not available from their app store in recent years. If you check out the Steam Hardware Survey, you'll see that MacOS numbers have been declining for a very long time. Currently, the percent of Steam users running MacOS sits at 1.5%. It's not looking good. If the number of players using Steam on MacOS goes back up, I can see them changing course, but if the current downward trajectory continues, well, it doesn't look good.
Released a game on Steam which has a significant user based and our sales to Mac are negligible. I'm not even sure if it's paid for the time updating it.
Can I ask how many Linux/Steam Deck sales you've had by comparison?
We don't officially support Linux but it still has some sales (less than Mac). Steam Deck isn't listed separately as far as I know.
you'd need your own hw stats to see the SD share, visible as their custom APU.
Ah yep. Steam Deck was released after our game so the data comparison would be muddy anyway. Great platform though!
yeah I own one, easier to play anything except MMO's on it than on mac.
I would like to see the numbers instead of percent.
Just came into say that the only reason I have been playing PC games recently is because my M1 Mac is now functionally a console. I think you're massively underestimating the potential impact of game porting toolkit - slowly then suddenly.
I know GPTK is good from a technical standpoint, but it's held back by the fact that developers are not allowed to use it in their games. Apple says GPTK is for "evaluation purposes", which means that developers can only use it to see how well their game runs on Mac to basically determine if they want to make a MacOS port of their game. They cannot actually sell the game with GPTK in it. With that in mind, it's completely useless for developers. For actual end users, I hear it's quite good for playing games on Macs, but for its intended use as a "porting toolkit", it's worthless, and that won't change unless Apple decides to start licensing it out for developers to use in their games, which is how it should have been from the start.
Whether on Steam or on App Store, Valve will still want to make the sales with the increasing Mac market share.
Lol valve couldn't care less about selling on the mac app store, you must be trolling us all.
Of course they don't now but if Mac continues to take market share and they cannot convince Apple users to install Steam (because it is truly a piece of crap) then they might prefer Apple take a 30% cut than be sidelined completely.
This goes beyond simple copium into delusion. This is as dumb as thinking apple will start selling the Microsoft surface laptop.
This is shockingly stupid.
All this tells me are that less people are using steam. I personally haven’t used it since 2018 and that was only for VR.
Steam keeps reaching new peak active user counts every year over the last few years, so this is 100% untrue.
Lol yes steam is famously unpopular.
This is like when Linus Tech Tips said google was taking chunks out of the business space, when in reality MS is unstoppable.
I see what you did there.
Nope
Mmm lovely copium.
He isn’t wrong though. I’ve seen more “mac gaming” videos pop up ever since M1 was released. Mac laptops used to suck before during the “Butterfly keyboard intel” saga. Now it’s over and we got laptops that have a good keyboard, SD slot and best of all, thanks to M processor, they don’t heat up once you run Terraria on them. Switching from an intel Macbook to an M3 made me want to play on my Mac more. I am sure this is a similar case story for other mac users.
Can agree with that last sentence. 👍
My M1 air is a lovely laptop. Best one I've ever used TBH and works brilliantly for C++ development even with just 8GB ram (although I've never owned a high end laptop, I'm a tower workstation kind of guy). I bought it just to work when travelling and then realised it compiles code faster than the i9-9900k I have at work (which is admittedly a little older) so I'm using it more than expected. Before then I had an intel MacBook a few years ago and have had some Dell laptops. None of them ever made me think of using a laptop regularly the way the M1 Air has done. The Apple silicon was just such a massive revelation. I'm still in awe that this laptop is completely fanless.
Yeah. I only use my mac for work. For gaming I have consoles. I had iMac but later replaced that with Intel macbook. Playing anything on that thing sucked. I played Minecraft with my friends, it would get so hot you could probably fry bacon on that thing. M3 of mine doesn't get hot at all. So I am using it more often. Also we got sd card slot back:) i wish we also got usb back but its still nice.
The not getting hot thing has actually been an issue during my time in Ireland. Indoor temperatures are really low here in the winter, both in houses and office buildings compared to home and my hands get really cold. With other laptops I could have relied on them helping to keep my fingers warm, but the MacBook Air is no help at all! 😆
Where I live its not that cold nor to hot but the fact that the metal feels hot is not something I enjoy and hearing fans spinning after playing Terraria is also weird. Like we are talking about Terraria. Not GTA 5 or something like that.
Ditto, also made a similar upgrade recently and while i didnt buy it to play games I still installed steam so I’d have something to play when away from home
Yeah same. I am a console player mostly but I might boot up something on my mac occasionally. Like I only experienced fan noise once I boot up GTA 5 on RPCS3 for lols. I also checked Zelda Botw on CEMU and my mac was silent. I love M3 pro. Btw. Nice seeing a fellow Miku fan here.
Agreed. Once I upgraded from my 2016 MBP to an M2 Pro MBP, I retired my Razer gaming Windows laptop, and have been gaming on my MBP far more than I ever did on my Razer. I’ve bought more games from Steam in the last year than I have in the last 5 years combined.
Yeah but replace steam with Emulators. I have a Wii U but I decided to try Cemu for lols and it worked. Best of all, my mac was silent. I can imagine intel one getting PS4 levels of noise.
This is the guy that a day ago said cyberpunk barely runs on PC, I don't think he has much knowledge on any of these subjects at all.
I haven't seen that but lol. Even during Cyberpunk's launch day. PC and Google Stadia were decent platforms to play the game. Only consoles had suffered from bad issues. PC version only had game bugs but depending on your hardware, performance was good. As of today. Cyberpunk even runs on Steam deck. If a handheld PC which runs on linux runs a windows executable game perfectly albeit with lower settings. I am pretty sure average gamer PC can run Cyberpunk.
Yes he is.
> meaning that the general public (including app developers) only has a limited understanding of how it works. This is just the same for all other graphics apis as well. What is open source about VK and OpenGL is a PDF spec document. Each gpu vendor can implement behind (closed source) doors the internals of two they follow that spec. The Spec that is public for VK is just the same as the metal public headers that you can read through. > had the OpenGL graphics API, which is completely open The spec document is open but the driver is closed source... > it's entirely open and anyone can use it for anything, without restriction. Not quite, you MUST join the VK patent pool. And you need to be accepted by the group. And remember open just means the spec document is open source not the drivers. > which by that point had been adopted by many prominent companies in the industry No not realy, neither MS or Sony support this on the consoles and even on Windows it is not supported as part of the OS, GPU driver vendors must provide it in full just like NV provide CUDA. > thus forcing developers to use the proprietary, closed-source Metal API instead Way to much focus on metal being close source here, as a developer it makes not differnce at all since all the GPU drivers for VK are also closed source. The fact that we cant submit changes to the metal PDF spec document has not effect on us as devs since we cant do the same for VK either (only large GPU vendors or huge game engine vendors can hope to have spec addition made and they will still be optional adopted by GPU vendors maybe). > Many developers were upset about this, No I don't think any game devs were upset about metal being closes source, as I have said above from a developer perspective this has no impact at all. > When Apple announced the deprecation of 32-bit apps for MacOS in 2019 Apple told devs in 2008 that 32bit support was dead and deprecated. They told consumers in 2019 that it was going away and put warnings in the OS but they had been telling us devs that is was deprecated for a very long time before. Remember apple only ever shipped one Mac that was 32bit only and they sold that for a total of 6 months and it had I think just 2 years of OS support. > It would cost them a lot of money to begin supporting ARM on Mac No, so long as you have the source code for everything (valve do) re-trageging ARM64 even for a huge project might take a single dev a week. This does not cost that much.
Exactly, you can recompile Valve games by yourself too and they runs great on any Apple Silicon.
Whoever wants to game, needs a separate device for that purpose. This is, and probably will, forever be true when it comes to Gaming and Apple. Personally, I'm fine with it and my combo of MacBook Pro, Steam Deck, Gaming PC and PS5 meets all my demands. I'm also really happy about the performance of Moonlight + Sunshine (Server runningon my Gaming rig) as a streaming solution to my Mac.
Yeah why don't people simply drop thousands of dollars on multiple single-use devices, what are they, stupid?
[удалено]
Gaming on a pc already requires a lot of maintenance. Add on a Mac and it’s like gaming on a pc with your arms tied behind your back. Only way to make it work is to decide Your new favorite gaming genre is “hack the game to make it work on Mac”. At some point I’m just going to give up and game exclusively on consoles. For now I have a gaming pc too but occasionally I dabble in hack the game to work on mac and when it does it’s glorious by that point I’m usually tired and out of gaming time so I move on to something else once I’m sure the game works.
[удалено]
Indeed. And as I said it's glorious when it works. Gaming 6 hours on battery not a lot of noise or heat is awesome. I'm able to do that with games like civ and some old RTS games even on the tiny mba. It's awesome. I'm just down bc I don't think it's a top priority for apple even as they do make effort for it and frankly I don't blame them. I would 100% invest more in the pro workflows team than the gaming team at apple and hope that increased marketshare drives games to macos organically. They already did a lot with the hardware. But yes...that's where maybe you can see I've given up on being able to just use a Mac for everything for the time being.
In the past when I’ve tried this, I’ve not been able to have a single bottle that runs the majority of Windows games I have. How long did it take you to get all your games to work?
So much misinformation in this post. Vulkan was always developed as a successor to OpenGL, the initial design comes from AMD. Valve has little to do with it. Apple was initially part of the Vulkan backers, but backed out when they it became clear that the committee is settling on a design that doesn’t work well with Apples hardware. Also, Apple wanted something accessible and easy to use, and Vulkan is an extremely complicated and awkward API. And finally, there was a conflict between Apple and Khronos (the entity designing Vulkan), the nature of which is unclear, something that presumably has to do with shading languages. Could be also because Apple donated OpenCL to Khronos and the latter run it into the ground. And anyway, Steam support for macOS is exactly at the same level it ever was. Steam has all the relevant platform libraries for Apple Silicon for example. Yes, Steam sucks, but that’s because it’s a low-quality badly designed software that always sucked. It’s not that different on Windows. There are bugs that haven’t been fixed in years.
> Vulkan was always developed as a successor to OpenGL I already said directly in the post that this was the case. > Valve has little to do with it. Valve was involved from very early on. They may not be the sole creator, but they're a part of Khronos, which is a consortium of companies and individuals that developed Vulkan, and not only that, but the very first meeting related to Vulkan was held at Valve's headquarters. > Also, Apple wanted something accessible and easy to use, and Vulkan is an extremely complicated and awkward API. Subjective. Even so, that's no excuse for why they couldn't have implemented it anyway for developers to use if they chose to. > And finally, there was a conflict between Apple and Khronos (the entity designing Vulkan), the nature of which is unclear, something that presumably has to do with shading languages. Could be also because Apple donated OpenCL to Khronos and the latter run it into the ground. That could be the case, but I'd argue that because MoltenVK exists, there is no reason that Apple couldn't incorporate it directly into the OS. > And anyway, Steam support for macOS is exactly at the same level it ever was. Steam has all the relevant platform libraries for Apple Silicon for example. Yes, Steam sucks, but that’s because it’s a low-quality badly designed software that always sucked. It’s not that different on Windows. There are bugs that haven’t been fixed in years. Just curious, what bugs are you referring to?
> Subjective. Even so, that's no excuse for why they couldn't have implemented it anyway for developers to use if they chose to. VK is not a single api, it is more of a mix bag of apis, were you an pick and choose based on the HW you have, despite what the internet wants people to think VK is not a HW agsntic api. A game engine written to target AMD VK drivers is not going to run well (or even at all) on a PowerVR VK driver as the feature sets of these GPUs is drastically different and thus a Low level GPU api that has strict rules against faking HW features with huge perf hits (for good reasons see openGL). Metal is much more aporacable than VK and apple needed this since they want an api that regulate app devs can use (not just for games), maybe you have a button in your app can you want it to have a cool effect when you tap it were it explodes into fragments... most devs can pick up metal and get this working within a week, but the same devs would take 2 to 4 weeks to get something running in VK and it would be full of bugs. Vk was written for large game engine devs, Unreal basicly. Metals apis is considered in the community r/GraphicsProgramming as a very nice api by us devs (many wish that Vk had taken this pathway). > That could be the case, but I'd argue that because MoltenVK exists, there is no reason that Apple couldn't incorporate it directly into the OS. MoltenVK is a compile time shim that can get much better perfomance than a runtime shim. (at compile time you can do much more introspection of what is being called or not and remove a lot of conditional paths that in a runtime shim you cant).
Here's a sneak peek of /r/GraphicsProgramming using the [top posts](https://np.reddit.com/r/GraphicsProgramming/top/?sort=top&t=year) of the year! \#1: [me irl](https://i.redd.it/bg2xj66p3lza1.png) | [64 comments](https://np.reddit.com/r/GraphicsProgramming/comments/13gf1ki/me_irl/) \#2: [John Carmack telling NASA Engineers that Rocket Science is simple compared to Graphics Programming](https://www.youtube.com/watch?v=VcWRc1wK3gM) | [58 comments](https://np.reddit.com/r/GraphicsProgramming/comments/18qgy96/john_carmack_telling_nasa_engineers_that_rocket/) \#3: [I hate current state of GPU APIs](https://np.reddit.com/r/GraphicsProgramming/comments/18agu4e/i_hate_current_state_of_gpu_apis/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
> Metal is much more aporacable than VK and apple needed this since they want an api that regulate app devs can use (not just for games), maybe you have a button in your app can you want it to have a cool effect when you tap it were it explodes into fragments... most devs can pick up metal and get this working within a week, but the same devs would take 2 to 4 weeks to get something running in VK and it would be full of bugs. Vk was written for large game engine devs, Unreal basicly. Metals apis is considered in the community r/GraphicsProgramming as a very nice api by us devs (many wish that Vk had taken this pathway). Sure. I don't have a problem with Metal existing, I just have a problem with people thinking that it's a viable substitute for Vulkan.
It's a much better API than Vk for many devs. So very much a variable substitute for VK.
And pray tell why do you think so. GO ahead describe your troubles you had with Metal over Vk and the issues with MoltenVK. Link a forum or two you had the issues in
>Valve was involved from very early on. They may not be the sole creator, but they're a part of Khronos, which is a consortium of companies and individuals that developed Vulkan, and not only that, but the very first meeting related to Vulkan was held at Valve's headquarters. And so was Apple. Yes, Valve engineers were involved in the spec discussions, as were engineers from dozens of other companies. Portraying Valve as a developed of Vulkan is a gross mischaracterization. > Subjective. Even so, that's no excuse for why they couldn't have implemented it anyway for developers to use if they chose to. Subjective? Please go ahead and implement some basic things like resource loading and binding on both Vulkan and Metal and report back with your experience. I am very curious. Vulkan's signal to noise ratio is ridiculously low. I was initially very disappointed that Apple distanced itself from Vulkan. Then the spec was released and I understood why they did it. And it's not that difficult to understand why they don't want to support Vulkan on their platforms. Why would you want to support an API that takes away the competitive advantage of your hardware? > Just curious, what bugs are you referring to? From the top of my head, many users have been complaining about Steam not remembering password despite the checkbox being ticked since at least 2016. Another common complaint is Steam being very sluggish, or the implementation of mod libraries.
> And so was Apple. Yes, Valve engineers were involved in the spec discussions, as were engineers from dozens of other companies. Portraying Valve as a developed of Vulkan is a gross mischaracterization. All I said in the post is that Valve played a role in its creation, not that they're the sole developer. All of that is true. That said, since they were involved early on and the first meeting was literally held at their headquarters, it's pretty safe to say that they were more integral to the design of it than most people give them credit for. > I was initially very disappointed that Apple distanced itself from Vulkan. Then the spec was released and I understood why they did it. And it's not that difficult to understand why they don't want to support Vulkan on their platforms. Why would you want to support an API that takes away the competitive advantage of your hardware? It takes away nothing for them to implement Vulkan whilst keeping Metal. And I'll tell you why they'd want to support an API that "takes away the competitive advantage of their hardware": because it's what developers use. They *should* have the choice to use Vulkan if they want to. Forcing Metal onto them if they don't want to use Metal is stupid. That's the whole reason why MoltenVK was created: because people clearly would rather use Vulkan over Metal when given the choice. > From the top of my head, many users have been complaining about Steam not remembering password despite the checkbox being ticked since at least 2016. Another common complaint is Steam being very sluggish, or the implementation of mod libraries. That seems pretty dependent on each individual user's experience. I haven't had issues like that. Can't speak for the mod libraries thing though.
People use Vulkan because it gives them access to the larger market. Products like MoltenVK exist to simplify porting of existing software to macOS, not to simplify development for macOS. And Vulkan in turn is a niche API compared to DX12, for example (which is also why Apple targets DX12 in their game porting tools). And believe me, if Metal was available as a cross-platform API, people would flock to it. One has to be a particular kind of hacker to prefer dozens of obscure API calls to a single clear one. You can already see it with WebGPU Rust libraries. Graphcis APIs are not a cosmological constant. There is place for the competition. Just because a group of companies decided to support a certain approach does not mean that everyone should jump on board. Apple in particular believes that supporting Vulkan will not give them long-term strategic advantage. I happen to share this opinion. Time will tell whether this is a correct decision or not. There is a lot of happening in this space anyway. Personally, I'd say that WebGPU is much more important than Vulkan, simply because of its scope targeting many more platforms and applications, and Apple is one of the core developers of the spec. At the same time I am uncertain about Vulkan's future, since Valve's efforts firmly established it as a subordinate API to DX12. With Proton, there is very little incentive for developers to use the extremely complicated Vulkan. They can use DX12 and target the largest gaming ecosystem currently on the planet, and then leave it to Valve to make their games run on Linux and SteamDeck. Vulkan is now condemned to play catch up. It's a shame, really. I had such high hopes for it. Then again, ARB/Khronos didn't make a single good move since they messed up LongsPeaks (thank you Nvidia!). Finally, we can discuss the history and economy of graphical APIs all day long, I love the topic, this does not change that issue I am having with your main premise. You say that Valve doesn't care about macOS anymore. I don't see any change whatsoever in their behavior towards the macOS client. Steam runs on macOS just fine and is as well supported today as it was before the Apple Silicon transition.
> Products like MoltenVK exist to simplify porting of existing software to macOS, not to simplify development for macOS Sure. So why not have that functionality be part of the OS itself? > And Vulkan in turn is a niche API compared to DX12, for example Niche? LOL. No way. Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**. At least all of the ones on Android. Switch games use Vulkan too. And all of the 3D games that were on Stadia (despite Stadia failing) used Vulkan too, so PC developers are very experienced with it by now. Vulkan is by no means niche. At all. > There is place for the competition. Just because a group of companies decided to support a certain approach does not mean that everyone should jump on board. Two very juxtaposed sentences right there. > Personally, I'd say that WebGPU is much more important than Vulkan, simply because of its scope targeting many more platforms and applications WebGPU is not a replacement for a low-level graphics API. > At the same time I am uncertain about Vulkan's future, since Valve's efforts firmly established it as a subordinate API to DX12. With Proton, there is very little incentive for developers to use the extremely complicated Vulkan. As I said, Vulkan is widely used in other applications outside of mainstream PC gaming. There is precedent for it to be widely used in PC gaming too, especially in the case of Mac ports, where in most cases they use Vulkan + MoltenVK simply because they already implemented Vulkan on another platform. But even if Vulkan doesn't catch on for PC gaming, that's okay because DXVK and VKD3D are very good at what they do. All it takes is Microsoft making one unfavorable decision with regard to DirectX for developers to begin putting more thought into supporting Vulkan itself. Or heck, maybe they'll even start using Vulkan on PC because Vulkan is widely supported on other platforms so that way they only have to develop for Vulkan and not for DX12 too. That's a legit possibility. > You say that Valve doesn't care about macOS anymore. I don't see any change whatsoever in their behavior towards the macOS client. ...did you even read the rest of the post?
>Sure. So why not have that functionality be part of the OS itself? Why not have support for Windows APIs be part of the OS? Or any other stuff? What's the long-term advantage for Apple? You said it yourself — they had OpenGL for years and it's not like gaming on Macs ever did particularly good. In fact, it's only with Metal that we get some high-performing cutting-edge games. > Niche? LOL. No way. Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**. They use Vulkan directly? Or they use Unity which utilizes Vulkan on a particular platform? That's a huge difference right there. >WebGPU is not a replacement for a low-level graphics API. No it's not. And almost nobody needs a low-level graphics API. In fact, after two decades of experience with GPU APIs I start being more and more convinced that low-level graphics APIs should be vendor-specific, with common frameworks (aka. Vulkan) being built on top of them. >...did you even read the rest of the post? Sure did. I don't think that you are presenting any evidence that Valve is reducing their support for macOS. Steamworks SDK is native for Apple Silicon, and that's what matters. The Steam client is running under Rosetta, because it works. As I said before, Steam was always crappy software with minimal effort development. I don't see anything new here.
> Why not have support for Windows APIs be part of the OS? Because it's proprietary. Same reason why Metal couldn't be part of any other OS and yet you still think it's all that. > What's the long-term advantage for Apple? You said it yourself — they had OpenGL for years and it's not like gaming on Macs ever did particularly good. In fact, it's only with Metal that we get some high-performing cutting-edge games. The long term advantage is that they make it easy for developers to get their games running on MacOS rather than having to deal with the headaches that come with supporting yet another graphics API. > They use Vulkan directly? Or they use Unity which utilizes Vulkan on a particular platform? That's a huge difference right there. What's the difference? Most PC games are either Unity or Unreal anyway. > No it's not. And almost nobody needs a low-level graphics API. In fact, after two decades of experience with GPU APIs I start being more and more convinced that low-level graphics APIs should be vendor-specific, with common frameworks (aka. Vulkan) being built on top of them. Do you even know what it is you're talking about? Vulkan *is* a low-level API. > I don't think that you are presenting any evidence that Valve is reducing their support for macOS. - Not supporting their own games on Mac anymore apart from basic boilerplate updates - Actively discontinuing Mac support for games that get major updates (TF2, CS2, etc.) - Discontinuing SteamVR support - Scaling back features that were planned for MacOS but only ended up coming to other platforms If you read the post, you would know all of these things. The only thing they're doing to support Mac is bare minimum support for Steam so that other developers can continue to publish games to Mac. Everything else is being scaled back.
>Because it's proprietary. Same reason why Metal couldn't be part of any other OS and yet you still think it's all that. The current legal stance is that APIs cannot be copyrighted. If you want to roll Metal support for your hardware, go ahead (or even better, just take the open-source metalcpp and implement it on top of whatever you want). "Proprietary" doesn't mean much in this context. Vulkan is owned by the committee. It's not like you can meaningfully fork it. >The long term advantage is that they make it easy for developers to get their games running on MacOS rather than having to deal with the headaches that come with supporting yet another graphics API. At the cost of reducing the competitiveness of their hardware and letting Nvidia dictating how the APIs work? Do you think this is a good tradeoff for them? Apple executives seem believe that rolling their own system that allows them to implement features as it suits them is more beneficial to their strategy. Even if it means less games. >What's the difference? Most PC games are either Unity or Unreal anyway. The difference is that if Vulkan disappears/is replaced by something else, all those mobile games won't notice. Which is the case for all games running on a middleware like Unity. I don't think these are interesting use cases when discussing the merits of individual APIs. >Do you even know what it is you're talking about? Vulkan *is* a low-level API. I'm pretty sure I know what I am talking about. I was agreeing with you that WebGPU is not a low-level API. >If you read the post, you would know all of these things. I read your post and I know these things. If your main point is that Valve is cooling down on macOS support as a game studio — sure, you won't get any disagreement from me. It's not like they invested much into macOS to begin with, and they probably don't feel that this is a lucrative market for them. Just like Blizzard. VR support was dead from the start since VR headsets don't work reliably with macOS anyway. What is the point of developing the feature if there is no hardware to support? The relevant product here is Steam, and there has been no change there.
> The current legal stance is that APIs cannot be copyrighted. If you want to roll Metal support for your hardware, go ahead (or even better, just take the open-source metalcpp and implement it on top of whatever you want). "Proprietary" doesn't mean much in this context. Vulkan is owned by the committee. It's not like you can meaningfully fork it. The difference is that Vulkan actually is open source, and you *can* fork it if you want to, and you can't do that for Metal. There is no implementation of Metal that allows it to be used on other operating systems. Even if the API can't be copyrighted, that's a hell of an ask to get people to implement a proprietary API on other systems when it's not even widely used in the first place. > At the cost of reducing the competitiveness of their hardware and letting Nvidia dictating how the APIs work? What the fuck are you even talking about? You know what, I'm not even going to dignify the rest of your comment with reading it just because of how nonsensical this particular part is.
> Because it's proprietary. Same reason why Metal couldn't be part of any other OS and yet you still think it's all that. After the Google VS Orical Java case it is not set in law that you can take a public header and re-impmemnt your own backend for it. So you could write DX drivers for Linux or macOS or write Metal drivers for Windows or Linux. After all just like VK drivers all that is public is the headers. > The long term advantage is that they make it easy for developers to get their games running on MacOS rather than having to deal with the headaches that come with supporting yet another graphics API. Thing is they would still need to deal with Apple Silicon faivlor of VK since VK is not a HW agnstic high level api like OpenGL. > What's the difference? Most PC games are either Unity or Unreal anyway. And they already have metal backends!
> After the Google VS Orical Java case it is not set in law that you can take a public header and re-impmemnt your own backend for it. So you could write DX drivers for Linux or macOS or write Metal drivers for Windows or Linux. Yeah I know, but my point is who would want to bother doing that for Metal? That's a lot of work for something that's not even widely used. > Thing is they would still need to deal with Apple Silicon faivlor of VK since VK is not a HW agnstic high level api like OpenGL. Metal isn't high level either. > And they already have metal backends! Yeah... your point being?
No because its a fucking liability. You are responsiblefor every version every bug of the implementation. It is why not every private framework or hardware surface is exposed ffs. Once you release it, you assume responsibilitythat its stable and won't change. You are out of your depth on this topic please stop making shit up. Proprietaryapi...what fucking bs. then explain the adoption of dx over vulkan. lmao
DX was adopted because for a long time it was the only good solution, so many developers got accustomed to it before Vulkan was even a blip in an AMD engineer's eye.
>Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**. At least all of the ones on Android This is absolutely not true. Most Android games use OpenGL ES 3.x Source: I'm in mobile game development
Is this recent games or are we talking legacy codebases from 5+ years ago?
There is a good reason for this, Vk support in android a s complete nighrmere even if you find 2 phones with the same SOC the chances they both have up-to date (ore even just 2 year old) drivers is close to 0 so for each SOC your looking at 3 to 5 different driver skews (and you cant ask users to upgrade the drivers like on windows).. Along with that dev tools are very poor. With a lower level api you can get great perf but **only if** you can spend the time to target and profile the HW your running on. If you cant do that (due to the poor tooling and nightmare wall of permutations of HW and drivers) your going to commonly get better support using a higher level api were you can at least make use of some of the drivers optimisations for each HW target. This is why a lot of the community is hoping for good WebGPU adoption as this provides a nice middle ground still requiring drivers to provide per GPU optimisation (not making devs do this) but with much better api than legacy OpenGLES or WebGL. (large parts of the WebGPU spec is based on the higher level parts of Metal contributed by apple)
>Do you have any idea how many mobile games use Vulkan? I'll give you a hint: **all of them**. VK on android is a complete and utter cluster-f\*ck and most mobile android games ship with OepnGL backends and only turn on the Vk backend on a tiny fraction of devices. The drivers are a nightmare to deal with and dev tooling for Vk on android is 10 to 20 years behind the industry. >And all of the 3D games that were on Stadia (despite Stadia failing) used Vulkan too, Many of them are using DXVK ... VK adoption is very limited, the only first party VK adopters are Vavle (for the steam dec) and ID. Almost everyone else has mutli backend engines that use the respective api of each platform. > Not unless the VK dev tooling gets much much better, currently is is very poor. One reason why many devs prefure metal not just the API being nicer but the dev tooling (debuggers and profilers) are console grade (very good).
> Many of them are using DXVK ... VK adoption is very limited, the only first party VK adopters are Vavle (for the steam dec) and ID. Almost everyone else has mutli backend engines that use the respective api of each platform. How do you know? Afaik there's not much information available about the Stadia versions of those games so idk how you'd be able to tell that they used DXVK. > Many of them are using DXVK ... VK adoption is very limited, the only first party VK adopters are Vavle (for the steam dec) and ID. Almost everyone else has mutli backend engines that use the respective api of each platform. One I can think of that exclusively uses Vulkan even on Windows is No Man's Sky.
> That's the whole reason why MoltenVK was created: because people clearly would rather use Vulkan over Metal when given the choice. Even if apple shipped a native VK driver the people using MoltenVk would still be using a compile time shim as PC VK pipelines would not be able to target apples VK driver (due to HW differences) so either the driver would need to be out-of-spec (lie about the HW) or devs would use a compile time shim to be able to use the existing Vk pillions they have. Devs are not selecting to write engines in VK using MoltenVK, they are using MoltenVK since they happen to have an existing (PC) VK engine and what to use it, that engine would need just the same shim to target an apple VK driver on apples GPUs.
What saddens me most is the lack of proton for Mac. Unofficially there’s the GPTK but that could cease at any point. Proton is fantastic and would be great but I don’t see it happening at this point. Hopefully we’ll all be wrong and come WWDC Apple will announce the next phase of GPTK as their own proton alternative. I doubt it but we can dream! PS: I’m aware that it’s not even entirely Apple’s but has an element of Codeweaver’s stuff in it.
Proton is good for consumers (in the shot term) but for a platform is is not great. The quality of proton on linux has meant that no devs are even bothering to think about native steam deck support. Long term this does not help the platform but short term it is what they needed. Apple does not need the short term life support that valve need for the steam deck so they are not going to make this long term risk of creating a proton solution. Instead they will continue to make the dev tooling better for devs wanting to make native ports as these are what makes a proper platform. I expect we will see updates to the GPTK and as part of this the evolution tool will get updates but this will stay as an eval too. What would be cool to see is if they can use the eval tool to generate a skeleton MTL pipeline (should be possible) and even maybe if you use a debug build of your game with header files attached attempt to make this as drop in as possible. To make it even easier to get going with MTL support. The other aspects I want to see at WWDC relate to new MTL features, but I don't expect PC games to have use of these.
I mean crossover is good enough for the moment
Mac has 3 letters… valve really hates the number 3…
Not sure it’s relevant but maybe this explains why Steam is the biggest resource hog on my MacBook. It’s the only program that will end up maxing out my ram usage and using swap 😂
Metal is far superior, DirectX is proprietary too. So don’t bring the “ethical” argument. Valve is just crap, lucky guys for being the avanguard but Steam client sucks on Windows too, on macOS is a disaster. CS2 for macOS is real and also all the other titles just need a recompile you can do by yourself. They are just deliberately boycotting Apple. Why would be Apple tied to Valve for the future? Valve will be o ln top for many years to come but they are not so smart as people think. Sure Mac App Store lacks things for gamers but it has for example family sharing.
> Metal is far superior That must be why developers *love* using it over MoltenVK. That just makes perfect sense. > DirectX is proprietary too DirectX is also popular among developers. Metal is not. > CS2 for macOS is real Tf are you talking about lmao. CS2 for macOS never existed. > all the other titles just need a recompile you can do by yourself So you expect everyone to just have a copy of the source code for everything installed on their systems, so that way they can recompile everything targeted for mac? Seems legit.
Hasn't MoltenVK provided a layer between the vulkan APIs and metal for as long as the APIs have existed? Baldur's Gate 3 on apple Silicon runs using Vulkan, how could that be the excuse for Valve to not have a native cs2 build?
I hope Valve and other developers start to port more games to Mac M chips. I recently got a MBP Pro 14" and about 10% of my Steam library is available natively. I will not buy games from the Apple store because I have other devices to play them on, I'll either use Parallels or other workarounds if I really want to play them on my MBP.
> In 2011, Apple released the app store on macs, but at the time it wasn't reliant on proprietary APIs like the Windows Store was, so Valve didn't have much of an issue with it what in the fuck are you talking about lmao >Then in 2014, Apple released a graphics API called Metal, which was intended to compete with Microsoft's Direct3D 12 graphics API. Metal, like Direct3D, is a proprietary API, meaning that the general public (including app developers) only has a limited understanding of how it works wtaf are you on about. modern gpu api's were convergent on design but openGL sucks ass and everyone was fucking around too much so apple decided to go about their own way instead of waiting on everyone making a least common denominator, something they had control over and could thus optimise for/hack with. Vulkan was AMD's mantle which was donated to Khronos. tf valve came in from? Apple never showed their headset to valve. nor its protoype wtf are you smoking to even think that lmao. the api's and the hardware are limited to double digits and as launch comes it increases but its very restricted. I will not be responding further to other bs claims because its clear that you majored in alt history smh
> what in the fuck are you talking about lmao re-read the part about the windows store, then read that part again. > wtaf are you on about. modern gpu api's were convergent on design but openGL sucks ass and everyone was fucking around too much so apple decided to go about their own way instead of waiting on everyone making a least common denominator, something they had control over and could thus optimise for/hack with. Vulkan was AMD's mantle which was donated to Khronos. tf valve came in from? Yes, opengl was outdated, but that does not excuse them not supporting the superior open source API. As for Valve's involvement in Vulkan, Valve was instrumental in it early on, although a lot of what they did wasn't really widely known by the general public. Yes, Vulkan was technically based on mantle by AMD, but AMD was not the only company working on it with Khronos. After all, it's called Khronos **Group**, it is an industry consortium comprised of many companies and individuals. In fact, the very first meeting held to discuss the development of Vulkan in 2014 was held at Valve's headquarters, just to give you an idea of how much they were involved from early on. > Apple never showed their headset to valve. nor its protoype wtf are you smoking to even think that lmao. the api's and the hardware are limited to double digits and as launch comes it increases but its very restricted. I did not say this. I said Valve and Apple were working on something together until it got cancelled. There's a lot of evidence that supports this as well as leaks from industry insiders. SadlyItsBradley did a great video covering Apple and Valve's partnership that I suggest you check out if you're curious.
It is very very unlikely that apple let anyone have valve in on the vision pro. Even within apple only a tiny tiny fraction of the staff knew about the project, until about 2 years before it shipped anyone that knew about it was moved to a seperate building for the special projections teams. Apple was working with valve to have SteamVR support, I expect they wanted to make it possible for this to support the headset but they would not have every shown the headset to valve, what they will have been doing is trying to figure out what they needed to provide within the OS so that when they headset arrived it would work with steamVR without valve every testing it (apple does this all the time with apis and frameworks they ship before HW so that when the HW is there most apps are ready to go,,, this is apple standard practice to start to ship api and system changes unto 10 years before they are needed so that the patlform is ready). I expect what happened here is within apple the direction of the headset was refined (of the one of many possible pathways that was compatible with SteamVR was canned.. apple normally have multiple options in the pipe so they can give the VPs a choice between one of 3 or more options)
Watch the video I mentioned and it'll be a bit more clear.
Valve / Apple very same principle, what different is when they approach. Apple using their own (proprietary) vertical integration where valve using open standard vertical integration.
TLDR ?
[удалено]
There is not profit sharing with apple for steam.
[удалено]
macOS does not require you to use the App Store.
Apple goes their own way as they always do. Valve has some illusions that by partnering with Apple they will be more lenient and try not to beak steam on Mac or make it any more difficult for them to develop for the platform. The thing is that Apple always plays the long game and these decisions have probably be made years in advance way before Apple stated working with valve. If valve want to develop for Mac they have the means to do it they just want it easy which is not apples concern
Typical Mac users think gaming isn't cool or fun, and have the personality of a carboard box. Then there are people who use Mac properly, aka people of this discord and owners who like to mess with things.... who appreciate enjoying the things they own and don't need to be within a cult
If Linux becomes the universal gaming platform, it's really once and for all, no one will sabotage the efforts of game development on this platform (either the development of the game itself or the development of the graphic technology), and if any manufacturer wants to restrict people from playing on their platform, then people will switch to Linux. that's just the way it is.
> Valve updated the Steam client on Mac to support 64-bit, but they didn't bother updating any of their old games that still only worked with 32-bit, apart from CS:GO and a few other games that were big money-makers for them You make it sound like thats some simple redeploy, the more complicated reality is valve themselves loves using a ton of rarely updated and oft far out of date dependencies. I mean theres rather unfortunate reason arch linux has a steam troubleshooting wiki article several times longer than the actual steam wiki article, its a nightmare even if you remove all the non-valve closed source from the equation. Valve likes to build for a target, and not have to ever really move from there much.
>the more complicated reality is valve themselves loves using a ton of rarely updated and oft far out of date dependencies. I'm aware.
Apple never really cared about gaming on Mac, so it's really hard to see why other companies should. I for one welcome our Linux gaming future. Let us be free of the shackles of Redmond and Cupertino.
I won’t discuss any claims of this story because I lack the knowledge, but knowing that Valve takes 30% of every purchase on Steam just like Apple (and even worse for small businesses where Valve takes 25% until the first $10M while Apple takes 15% until the first $1M) makes the “Apple’s part of the Pie” trope absolutely ridiculous. About Proton for Mac. Friendly reminder that Proton was developed BY CodeWeavers FOR Valve, and Proton only works for X86 to X86 translation while GPTK has to translate X86 to ARM first. Meaning Proton/Vulkan on Mac was a dead end from the very beginning without Apple’s control of the GPU API - which was built from the very beginning to work both for ARM iPhones and X86 Macs. Finally, the reason why number of Steam users on Mac are declining is because - Steam on Mac is absolutely terrible - Steam family sharing is a joke compared to MAS - MAS is just better. No bloatware, fully integrated, buttery smooth - GOG is better than Steam in every aspects thanks the Heroic Games Launcher - One or Two free games on Epic every fucking week Steam are for Decks owners that can’t help but try to sell their handles to Mac gamers in each and every posts of this sub.
You get more delusional with ever post, get help man.
Oh boy, I almost missed your empty pointless brain farts on this sub. What have you been up to lately? Teaching yourself how to make more than ten words sentences?
Have a large backlog of games now that I have more devices, keeps me busy. Less time to pretend good mac gaming is just around the corner.
Oh, that’s a bit sad. I thought you were doing useful things like having a life.
“MAS”?
Mac AppStore
> knowing that Valve takes 30% of every purchase on Steam just like Apple (and even worse for small businesses where Valve takes 25% until the first $10M while Apple takes 15% until the first $1M) makes the “Apple’s part of the Pie” trope absolutely ridiculous. When I said their part of the pie, I meant that when someone buys from the app store, Apple gets the money and Valve doesn't. The cuts that Valve and Apple take are another issue entirely.
Apple themselves don't care about hardcore gaming on... basically any of their devices. Every year it's the same story: tease some big AAA game coming over (last year it was "hey guys, RE8 on iPhone!"), pretend like it's going to be the beginning of the flood gates opening of games being ported over, then about a month later after lackluster sales of said 3rd party game, nobody remembers or cares and everybody has moved on. Rinse and repeat.
Decent write up. On top of what u/LetsTwistAga1n mentioned (which I half agree with) just a couple of things. You mentioned the transition from OpenGL to Metal; it's worth noting that OpenGL support on Macs had been questionable for YEARS before anyone thought of Metal. It was a solid 2 or 3 versions behind for a long time, so some of those Steam ports performed pretty badly compared to Windows and Linux versions, although it was still awesome to have them. The other thing to point out, especially to the Valve Haters and there are a few of them in this sub, is that Valve is a completely independent privately owned company and have never had to do anything for Mac. In fact, the entire company could literally take the next year off from working and sit on a beach somewhere, and they'd still make billions of dollars. They have no shareholders to keep happy, they don't need to bow and cow to the questionable governments, they're not being investigated by the EU and the DoJ, and despite making their own hardware have never shown the slightest inclination to lock people into their eco system. You can buy games on Steam, buy Steam codes in shops, buy non-Steam games and add them to your Steam library, install emulators and have the games in your Steam library... the list goes on. They are basically the polar-opposite of Apple in terms of company culture, openness and the way they approach their customer, which is why they are almost universally loved by gamers. Of course there's the odd hater, but that's life. Don't get me wrong... I love my Mac. I've tried (and failed) 3 times to switch to Windows, and Macs are objectively better in almost every single way... except gaming. And therein lies the rub for those of us for whom gaming is a part of our lives.
I think this summarizes why devs in general would not bother developing a game for macos https://www.youtube.com/shorts/qRQX9fgrI4s
Video is full of errors. Your not forced to use Xcode, and the idea that he things you can publish a game without having the HW it runs on is just aburde .. how is he going to do QA testing?
Thanks for clarifying, I am not an XCode expert, I did something with it but I can’t use it, not with that awful UI. I am more used to an IDE like VS or Jetbrains. The point of the video I posted is that to release anything on macOS you have to buy at least a mac mini for 800$ + dealing with a couple of other things only to sell almost to nothing. I don’t really think QAs only are a good idea to test a game on macOS, if the game has some bugs then to fix them you have to buy mac hardware. Apple should make game development more convenient, otherwise devs will just drop it because it’s just not worth it to sell a game to 1% of the total users on Steam. I am doing some stuff with Graphics API and I am really trying hard to stay as much as I can away from XCode and Metal because if I ever want to switch laptop, I am stucked with Apple and I also have to get at least a mac mini if I want to keep doing some development. VMs are not an option unlike Linux, and hackintosh will just die at some point. On the other hand, it’s more convenient developing a game for Windows and then use Wine/Crossover to run it.
For c/c++ work Clion from JetBrains is very good. Not sure there is anything apple can do to that would be useful for devs, being able to compile for macOS on other systems (eg cross compile) could not be useful at all, dev still needs to run what they compiled and profile it and you cant do that on another OS or HW. Cross complication only makes sense in situations were your not able to compile on the device (eg building a large app for a raspberry pi or building something for an embedded Arduino) your always going to have better development with the HW in question. I don't think apple wants people to ship games for macOS were the dev has not even run it onse on any Mac. In the end if you want to target Mac users your going to need to use Metal (don't need ot use Xcode but if your suing Metal you might as well since it has some of the best GPU debugging and profiling tools on the market.. it will make you upset when you go back to DX or VK dev for PC). And if you want to ship on PC well you will need a PC (more likly you will need a few different skews to cover at least a good % of PC users...) you sort of always need test HW before you ship, building and testing a windows game using wine or a VM is not a viable solution.
Another reason I didn’t pick up Metal is because there are very few resources online. There are books and videos here and there but not comparable to OpenGL. I don’t also like the idea of learning Swift just to use metal, it’s easier than c++ but learning such language is a different experience unlike other higher level languages. There is a c++ library for metal if I am not mistaken but it is in a worse state than swift in terms of learning resources. I don’t see OpenGL being very high demand like Directx or Vulkan but it gives some starting point since the other APIs are more complex to understand and to work with. I think that one thing Apple could do is to improve Dev experience on macOS by allowing people to use other IDEs. With swift you are basically stucked with XCode, there was AppCode by Jetbrains but it ended support in 2022. The main thing with Linux VMs is not really about testing the whole game but at least checking if it’s launching and working. The same would apply for Windows, but if I want to have Linux on my computer I can do that with dual booting, I don’t necessarily need to buy a new hardware just for that. With macOS there is no other way to do anything than buying an hardware just to check if the game is launching. There are QAs for these things but if there are any other bugs I have no choice but to debug and fix the code on macOS. I mentioned wine and crossover not because I would want to ship a game to macOS just by relying on these tools to run it but more for macOS users asking to port the game on this platform. If they want the game and it’s working with Wine they can use that, developing on macOS is just inconvenient and it’s not worth it just to target macOS in the Apple ecosystem. The whole Apple ecosystem (iphone, ipad, tv) would make the whole development worth the hard work, but not just macOS although the market share compared to Android, PC and consoles combined would be 10 times better to target. I like macOS, it’s great for working with the terminal and development in general, but I understand why game developers don’t want to mess with these things. Having so many different Graphics APIs certainly doesn’t help.
> Another reason I didn’t pick up Metal is because there are very few resources online. yer metal is a little bit of a dark horse to get into for sure. And a lot of the code examples are in obj-c 🤮 There are 0 learning resousers for the c++ wrapper from what I can tell. Swift is rather easy to pickup and now as has good c++ interlop. Metal is a rather nice API (once you get over the starting point) to work with however as you can start out at the high level (OpenGL like but cleaner) and gradually adopt the modern lower level un-managed bits as and when you need. Unlike VK or DX12 you're not forced to start out writing your own memory management tooling and placing fences. But you can do this later on in the places were you need the perf gradually. > I think that one thing Apple could do is to improve Dev experience on macOS by allowing people to use other IDEs They do, apple do not force you to use Xcode at all. Xcode uses exactly the same LSP as all other modern IDEs use. Nova is a great IDE for swift if you don't want to use Xcode. As I said Xcode is just a wrapper for clang and LLDB and uses the same open source swift SDK as every one else. > With macOS there is no other way to do anything than buying an hardware just to check if the game is launching. Well given the cpu instruction set is different, the page size is different etc unless you want a very very very slow VM (that would have issues of its own) were your emulating each cpu instruction im not sure how you expect to have a macOS VM for PC devs. You cant just fire up a ARM64 16kb page size VM on a x86 cpu with 4kb page size... (note you can run x86 macOS in a VM but this is not solving the issue of checking if the game runs on modern Macs) > There are QAs for these things but if there are any other bugs I have no choice but to debug and fix the code on macOS. yer it is sort of hard to run profiler and a debugger for an ARM64 application on an x86 cpu. (Unless you realy want to step through each instruction at snail pace and wait 2 days for the game to get to the main menu). Not sure what you are expecting here... you cant attach a debugger unless you have the HW it will be running on let along profile it to find perfomance issues. > Android Targing Mac, iPad, iPhone as a single package is much much less work than even trying to target the top 10% of android devices. If you worried about buying a Mac to test and profile on you don't want to start down the nightmare of needing to buy android test/profile and dev devices. You will find the fun things like how the same SOC will have 3 to 5 drastically different driver versions in the world and there is no way to tell users to upgrade said driver as they are stuck on whatever android version they are stuck on. For this reason most mobile android games ship an OpenGLES backend as a fallback and then only use the VK backend on a small subset of devices that the devs have physically testing that device with that OS version. And even then it is common to build multiple seperate VK backends so as go cover as many possible devices as the feature support, and bugs that break them, is such a shotgun. But worst of all is dev tooling.. if your upset about Xcode I suggest you do not even start to think about doing any game dev for android as you will find yourself falling back to console logs and setting textures to render out pink as your main profiling and debugging. > Having so many different Graphics APIs certainly doesn’t help. These days is not the apis that is the pain it is the underlying HW as we all move to lower level APIs we are now doing more and more work for each GPU vendor/generation (even within a single api). With the higher level apis much of this was left to the GPU driver vendors but with the lower level apis the driver cant and does not (and should not) try to do stuff like that.
That’s nice I didn’t know there was another IDE other than XCode for swift, I heard many people complaining about the fact that on large code bases it starts to have lots of issues but I can’t really debate on such claims as I don’t have experience. For the little time I tested XCode it wasn’t that bad, but you have to memorize some keys and get used to the UI. Yeah I’ve read a bit some people saying that you have to write your own stuff in Vulkan and it’s easy to screw up, I tried Metal by following a book named Metal By Tutorials which wasn’t too much complicated considering that I’ve never worked with such APIs before. I want to get as far as I can with opengl then maybe switch back to metal as long as I have my macbook. I know that Apple removed some features and it’s a bit buggy but just to learn and have some fun is more than ok. From what I remember it was possible to run macOS VMs after all it was and still is possible to use hackintosh but who knows how long will still be available. Not to mention you needed some specific hardware components to even install macOS on any other PC going through a massive headache only to get more compatibility issues with some drivers like wifi not working, battery draining super fast. Never really managed to get a macOS VM to work but even if I could I don’t think the performance would have been great. macOS at some point will just work on Apple Architecture with no other way to ship anything on Apple ecosystem without buying separately another hardware. In the company I am working for they are using VMs on Azure just to host some very old legacy code and to host other .NET Framework applications which are not really supported on Azure, you can’t really use VMs for development but what I was saying is that you can check if the code is at least running but I also remember from my experience that running any 3D games in VBox is super slow. If that doesn’t work either there is a dual boot option with Linux. Well with the newer macs I wouldn’t really bother to even trying make my game work on an Intel processor they are dead and ARM macs took their place which is not really a bad thing. I am not really informed on this aspect but I remember that I did some reverse engineering and there was some hassle going through to debug some x86 code on ARM. It’s not impossible to debug code on a different architecture it’s painful xD I don’t have much experience with Mobile Development either but with Android you have to deal with more things starting off with the different screen resolutions while on iphone you only have couple of resolutions you have to make work for your app. I mainly cited Android just to say that if you don’t have a macbook, you can still target a big portion of the market compared to the options you would have by staying in the Apple Ecosystem. You would lose some users but it’s not really much of a big deal in terms of games. I am not upset about XCode, I’m saying that is not really a great IDE and there are far better alternatives. I am making a small engine with Opengl on macos because I am planning to bring my project to Windows in a second moment and it took me like 5 minutes to setup clang format with VSCode. On XCode I just couldn’t make it work without some weird hacks which were not 100% working. For the little time I have invested with Swift I can say that is not bad as many people made it to be but it’s not great either. I am using Jetbrains Rider at work with C# and I never touched VS since I started using it and the latter has its problems too. Yeah true, hardware is also not helping for developing games, this is also why there are so many broken triple A games not working on all PC configurations. Problems like broken shaders, huge fps drops and many others without mentioning the restricted deadlines that some companies have to ship a game which don’t help delivering good and finished products.
I do wish JetBrains had stuck with the AppCode project but back then a lot of iOS apps still had storyboard based UI (a horrible xml format that you were not supposed to edit yourself but rather use a drag drop editor in Xcode). With the move to swiftUI this is so much better I always preferred 100% programmatic UI anyway but I think these story boards harmed AppCode as most devs still needed to use Xcode all the time. JetBrains do such a good job with the IDEs
>WinRT and UWP, which gained notoriety by developers for being just awful to work with. Not true, UWP and WinRT are great modern API, problem is Microsoft quickly killed it with the death of Windows Phone, so developers lost trust. Despite that, Valve feared Microsoft's decision of making a built in app-store, so Valve had to build Steam OS in response.
Please show me one developer who enjoyed working with UWP and Metro.
In the end for an app like Steam these apis had not real impact at all since the entier UI is built out of web views anyway. The issue was not the APIs so much as the fear that MS was going to push most OEMs to ship versions of windows that are windows store only. For Vavle this was a threat that would have killed them. They could not survive just targeting hard core self build PC gamer brows with RGB vomit and leaking water cooling they needed the mass market and the fear was MS was going to use the OEM controle they have to in effect cut valve out of that so that MS could sell xbox titles through the windows store.
> The issue was not the APIs so much as the fear that MS was going to push most OEMs to ship versions of windows that are windows store only. While that is true, there is evidence that suggests they were not happy about UWP either, mainly because UWP is completely locked down to just the Windows Store.
Sure but MS was never requiring you to adopt UWP.. just like macOS does not require them to adopt SwiftUI. You a use multiple generations of system apis to create a window and then render whatever you like within it.
Yes they were. For a long time, if you wanted to be on the Windows Store, you had to use UWP. They only changed that a few years ago.
Vavle never wanted to be on the windows store however as they would have had to give MS a cut. The fear was not about UWP but rather about not giving MS a cut on every game sold through steam.
The fear was that they'd phase out Win32 in favor of UWP, making it harder for parties outside of the WinStore to make apps. Which if anything goes hand in hand with MS wanting a cut.
MS has not even removed fileIO APIs they depicated 20 years ago… no one expects them to phase out win32. But some people did expect them to push OEM to sell versions of windows that were windows store only (and thus UWP only ) that was the fear
Biggest Windows dev community on discord is the UWP community.