Apple did contribute to the Wine codebase and have their own translation layer.
Performance and compatibility seem to be much better than what Codeweavers showed which is expected given the translation appears to be DXIL to MSIL instead of DX to VK to MS.
The Mac gaming Reddit has a bunch of people posting results
This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.
> This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.
I wish. Unfortunately the MetalD3D is proprietary under a very restrictive license. The rest is just Wine code written by Codeweavers.
I don't understand your pessimism. If Apple finds and fixes a gap in Wine's coverage/compatibility, those changes will necessarily be open source. Quite simply, any work which Apple does that could be useful to the wine project will be open source.
Obviously it would be nice if MetalD3D was also released under a better license, but it's hardly as though this omission is a big loss to the wine project.
Apple did not upstream anything to Wine here. They just use CodeWeavers code for macOS support, plus their own changes, and released a 20k line diff to be compliant.
The license to their translation layer(which is closed source) is very restrictive and basically only allows use for evaluation purposes.
> The license to their translation layer(which is closed source) is very restrictive
The Windows EULA didn't allow people who built their own computer to buy the cheaper OEM version of Windows. They were supposed to pay full retail.
I would expect to see people care about this license agreement restriction just as much as they did when they built their own PC and installed the OEM version of Windows on it.
So what you're saying is that Apple didn't do anything useful for the Wine project and you're angry because after Apple did nothing, they failed to open source the nothing. Okay then. I don't follow you.
It's still not a great thing to do. Apple used to contribute a lot more, even if some of their stuff was exclusive to their platform. https://opensource.apple.com
They can’t really do anything because of the massive liabilities GPL v3 opens them up to.
My understanding; the license won’t allow them to settle if a third party seeks patent licensing from them over shipped GPL code - they have to ensure everyone using any derivative of the upstreamed code is also covered by that patent license.
The Game Porting Toolkit contains a proprietary (143 MiB) D3DMetal framework that directly translates the Direct3D calls to Metal. They don't use the Direct3D --Wine--> Vulkan --MoltenVK--> Metal path that opensource Wine/CrossOver Wine uses.
"you are granted a limited, non-exclusive, non-transferable, personal copyright license to (i) install, internally use, and test the Apple Software for the sole purpose of developing, testing, or evaluating video games for use on Apple-branded products"
That does look like they have their own shader ir converter. But the fact that there's d3d9-d3d12 there, and under a wine directory, means those parts, at least, are borrowed.
That this exists is hilariously self-defeating. Linux gaming is becoming Proton-driven, so with this and VKD3D, we're potentially looking at Direct3D 12 as the most widely supported cross-platform API. Why write Vulkan or Metal when D3D runs everywhere now?
The release precedes CrossOver's 23 release with DirectX 12 support though. (Though you'd think that many bits are already there in prior releases.)
Edit: I poked around a little in the game porting toolkit and it seems different. They have a D3DMetal framework, whereas CrossOver's Direct3D 12 support goes through MoltenVK.
It seems to me that Apple invented their own proprietary graphics technology (Metal), never supported a cross-platform one (Vulkan), then found not enough games ever supported Metal, so they added a translation layer for another proprietary graphics technology (DX12).
Wouldn't they have been better off just supporting Vulkan?
Metal was launched before Vulkan (2014 vs 2016), Vulkan was before Mantle from AMD that they donated to the Khronos group, it was in development and Apple is part of the group so they were aware of it, but I can understand that depending on consensus across multiple parties could delay Apple agenda, same for Microsoft that could ditched Dx in favour of Vulkan, but they aren't.
There have been (though don't quote me on this) stories about how everything Khronos standardizes reeks of design-by-committee, to the detriment of the final standard.
An obvious example would be OpenGL, which nobody has called a well-designed API.
But there's other misfires as well. OpenCL hasn't exactly set the world on fire compared to CUDA. OpenVG was a standard for accelerating 2D Graphics that was a little too late to matter. OpenXR? Well, at least Oculus is actually using it. WebGL? The W3C is working on replacing it with the (far superior) WebGPU. WebCL? Well, that was a JavaScript system for OpenCL, and that was as bad of an idea as it sounds.
And of course, most recent example: Vulkan. Almost everyone who has actually used Metal has commented on how it is much, much easier to hit the ground running than Vulkan, because Vulkan requires mountains of boilerplate. (It's also worth remembering that every iOS Developer builds for Metal, so it isn't like there isn't knowledge out there about how to use it - it's just among mobile game developers instead of the AAA developers).
I'm a graphics programmer and basically write Vulkan code full time. It's an amazing and excellent API with an absolutely crazy good documentation. I've done some DirectX and Metal work too, and while they are definitely less verbose, I find them much harder to use because I have to rely on my intuition and prior experience for how things interact with each other. With Vulkan, it's spelled out for me in the specification.
Yes, Vulkan comes with more boilerplate. But who cares? Vulkan was meant to write your engine in, not something you call directly from client game code. It works extremely well and Khronos deeply cares about Vulkan and continuously improves it. Part of the verbosity also comes from the fact that Vulkan scales from small embedded SoCs to big gaming GPUs and everything inbetween, so the API has to cover a lot of potential hardware quirks. Viewing Vulkan as a kinda low level HAL helps explain a lot of the verbosity.
Anyways, long story short, I absolutely love working with Vulkan and after having been Vulkan programmer since basically day 1 of its existence, you can take it from my cold dead hands.
OpenGL wasn't designed by Khronos, rather it was designed by SGI and called GL. It was then given to Khronos and then maintained it.
OpenCL wasn't designed by Khronos either, rather it was designed by Apple and then given to Khronos to maintain. It was orphaned when Apple gave up on it, and not because of Kronos's leadership but rather Apple decided to go all in on Metal, their proprietary solution that did graphics and compute shaders.
Vulkan also wasn't fully designed by Khronos, rather it was based heavily on Molten from AMD, which was gifted to Khronos. It is much more widely used than Metal.
That said, benevolent dictators who are competent can out do committee decision making, but committee decision making is often better for an industry as a whole because it aligns different interest groups.
You could say the same about Vulkan though (outside Android, Vulkan is mainly used to run D3D games on Linux via dxvk).
The D3D APIs are by far the most popular for PC games, so it makes a lot more sense to support D3D. Also, Vulkan on Mac is already supported "well enough" via MoltenVk.
The goal with Metal was making sure they own IOS, and now their new AR platform. Macs are selling well regardless. They are just a nice to have.
I think they are keeping an evil eye on asahi linux. As soon as that becomes viable, they'll act to keep people on OSX. Their worst nightmare would be steam actively moving to support proton on mac and doing things outside the apple store. Asahi linux would be the pre-cursor to that happening.
>As soon as that becomes viable, they'll act to keep people on OSX.
If you think that (even with a fully parity with say Ubuntu on Intel Asahi) people would move to Linux on their Mac on any number enough to even raise an eyebrow (much less worry) Apple, you are delluding yourself.
People buy Macs to run macOS. A very tiny minority buys Macs to run Linux on. A slightly larger (but still insignificant) minority will convert an old Mac laying around to Linux.
It's enough to get a project like Asahi support, not enough to make even a 1% dent on Apple's software/services ecosystem bottom line (the hardware side is the same, as those people are still buying a Mac anyway).
I doubt they’ll do anything to Asahi. They went out of their way to add third party OS support to M-series Macs after deriving them from the famously single-OS iPad architecture. They’ve also said that they’d welcome Microsoft porting Windows to M-series Macs and wouldn’t do anything to stop it.
They clearly see the Mac a bit differently than they do the other iDevices.
You are getting me wrong. As soon as people start running games on Apple hardware outside of their software platform, they'll want to fix that. Asahi Linux is making rapid progress to enabling that. Hence the announcement of a porting toolkit. Imagine if they don't do that and then Steam suddenly announces rolling out proton to macs and the availability of their full catalog.
That's a scenario Apple would want to avoid. Hence the announcement of a porting kit.
Again, you are misunderstanding me. Asahi Linux is doing a lot of hard work and open sourcing that. That in turn enables porting back some of that software to OSX. Steam on Mac so far runs without proton so it can't run a lot of things. The people developing Asahi Linux are doing a lot of hard work figuring out all the low level details of how the hardware platform works. The resulting software could be adapted to run inside of OS X. The hard part would be reverse engineering the hardware. Which is exactly what they are doing. And with the wide distribution of macs, it's obviously attractive for Valve and game studios to target that platform. Apple is responding to that threat by offering game studios an alternative.
They would have dumped it eventually even if they did. We can tell from the OpenCL debacle and a lot of the things going on in WebKit standards that a perfectly usable technology can exist but developers internal at Apple are only rewarded for building tech invented there.
> and the open source community toils tirelessly making baby steps.
FWIW, the Open Source community has had DXVK running >80% of the titles on Windows for years now. The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion. Writing and maintaining Wine is a feat Apple is not legally well-poised to do - without the tireless toiling of Open Source contributors, this feature would not exist.
So welcome back to gaming, Mac users. Let's hope this isn't a stopgap offering and more of a jumping-off point for DirectX9 coverage and the like.
> The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion
Assuming this thing takes-off and suddenly the RGB LED-illuminated crowd switch to Apple hardware and macOS, then it's a very depressing thought because it means Apple will veritably make hundreds of millions (billions?) of dollars off Codeweaver's (and their extended community)'s work - and they'll get-away with it because their revenue can be classed as hardware sales, and not software licensing.
I honestly don't know how to feel about this.
I do feel a pang of smugness seeing the (post-iPhone) Apple having to stop pretending that copyleft doesn't exist[1] but also seeing them acknowledging that ecosystems other than their own do actually exist, but ultimately favourable smirks are in no way any kind of compensation to the unpaid effort put in by many of Wine-and-co's devs.
I suppose Apple could do the decent thing and offer to acqui-hire Codeweavers et al., but that's more akin to a heavenly afterlife for Codeweavers' people (i.e. after acquisition Codeweavers would necessarily die along with their mission (beyond Apple's own self-serving uses) which might be a bigger disservice to everyone involved, especially the community.
----------
Unrelated-but-related: is any of Wine or Codeweavers' code under GPLv3? If so, that's might be the undoing of Apple's locked-down bootloaders: supposing that iOS, iPadOS or visionOS/xrOS includes DX12 compat via GPLv3-derived code: would Apple be legally obligated to explicitly allow users to install their own firmware contrary to their user-hostile, regressive, and (imo) indefensible policies so far?
-----
[1]: Apple avoids the GPL, but so do all the large incumbents (though of course, like literally everyone, Apple is now fairly on-board with MIT/BSD licenses) - I do note that the KHTML-derived WebKit retains its GPL licensing, is a single, huge, exception, but I also note that Apple, internally, heavily firewalls-off their WebKit devs from anything else. (I've visited Apple's offices in-person and while the pizza place in the central cafeteria is nice, the fact that their SWEs can't casually walk down the hallway into another product team's office and exchange misc advice is just downright _weird_ to me, that's why I withdrew my only application to work there)
Apple is only providing this as a developer tool, to help simulate existing Windows games on macOS such that they can be ported more easily. Apple won't officially support a "Windows-Rosetta", this is not meant for users and won't ever be supported on iOS/iPadOS.
Definitely not. It's just funny to see the Open Source contributions reduced to "baby steps" because Apple had to play catch-up with their graphics API.
It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.
Since they use their own Direct3D on top of Metal (D3DMetal), you can immediately start investigating performance while not much of the game is ported yet. Even while running the game in Wine, you can already analyze graphics performance with Instruments.app.
At least this was the messaging in their talk about this: first you had to work months on a port to see how well a game would work on Mac hardware, now you can immediately run it, investigate bottlenecks and see where a port would land performance-wise before putting in any of the work.
I wonder if they will make the D3DMetal usable from native code as well, I can imagine that would make porting much easier:
- First you run on Wine + D3DMetal to get idea if your game would run well enough on Apple hardware at all.
- Then you start building the game natively, still using D3DMetal, so that you don't have to immediately port the graphics stuff.
- Once you have a running game on top of D3DMetal, you start porting it over to Metal with their shader converters, etc.
There is so much more to a modern engine than just 3D graphics. Sound, input, windowing integration, high-speed disk streaming IO, networking, robust OS integration (where to store save files, etc), just compiling it. Problem is that testing most of this depends on having a working renderer to display the game. This tool allows getting something on the screen faster so you can test everything all at once instead of having a bunch of sound, networking and platform engineers waiting around for the rendering team to get their part working.
Dunno about Apple's version but with Wine you can linnk native code against winelib, allowing you to test what you have already ported before you got everything up and running.
Of course if Vulkan was a suppoted API on macOS, developers could just port to Vulkan on Windows and then implement the rest on macOS.
I think that’s true today but it could change. I imagine Apple wants to encourage developers to build native games but I could see them loosening restrictions down the road. Maybe they eventually position this tech as the Bootcamp alternative for Apple Silicon. Time will tell.
Gaming on Apple is going to depend on how well optimized the drivers and shaders for the GPU are going to be. You'll also need some serious upscaling because most Macs come with super high res screens, a GPU that won't be able to drive modern games at those resolutions and an utterly lack of graphics card support, even in the new Pro.
Another factor is that major GPU companies put efforts into rewriting some games' shaders to make them run better on their hardware. I doubt Apple is going to do that so you'll probably end up with games performing better on other platforms soon after release.
There's more to getting games to run smoothly on a platform than compatibility software. So far, the GPU has been lacking despite Apple's attempts to hype up gaming for mac. With the rate things are going, the year of gaming on Mac may be the same as the mythical year of the Linux desktop: inching ever closer but never really arriving.
There's no need to run games at those high resolutions natively. Modern games now render only stuff like UI at the monitor's native resolution while the 3D viewport is rendered at a lower resolution and then potentially upscaled using DLSS or FSR.
So in the end... the easiest way to develop cross-platform PC games is just target Windows and Direct3D 12, and let Wine/other D3D12 emulators handle the heavy lifting.
As a user... Tell me why I shouldn't just run games directly on Windows, the native platform?
As a user... Tell me why I shouldn't just run games directly on Windows, the native platform?
If you’re fine with using Windows then knock yourself out! I just came from another thread where people were complaining bitterly about the nonsense and dark patterns Microsoft is pumping into Windows to monetize users to the hilt. Frankly, I’d rather just avoid all of that!
If you're ok with everything else that comes with windows, that's fine. I'd rather not. I don't want to deal with its shell, update schedule, ad pushing, etc. for example so the emulator is a better approach for me.
And +10 years ago nobody thought to play on Mac. But now with the market share they have… Hard to ignore as a business and if Apple do all the heavy lifting for us games are going to come on Mac.
> . But now with the market share they have… Hard to ignore as a busines
That is not true at all. Ignoring Mac as a gamedev is one of the easiest decisions we've ever made at every studio I worked at. Even the studio where the boss used a Mac! The market share is minuscule and lacks even the Steamdeck and proton pushing linux support into Steam games.
That Apple saw fit to half-effort this tooling then lock it behind a license which prevents gamedevs shipping with it, and steam from packaging it, means Apple has yet again demonstrated their time tested poor support for games.
Statcounter is websites, games are not websites and you need to use an appropriate data source. Steam reports 1-2% for Mac users. My own game's wishlist stats are showing Mac is less popular than linux!
> My own game's wishlist stats are showing Mac is less popular than linux!
If you're talking about Railgrade (from your bio), couldn't that simply be because your game only shows as supporting Windows? Why would a Mac user wishlist a game they can't play? Linux users have had Proton for a few years now and the discussed Mac toolkit was only announced a couple days ago.
The platform wishlist breakdown occurs when players make a specific choice. Players use it as a "vote" for their platform. Thus Linux users are voting for Linux trying to convince us as devs to support them, Mac users are doing likewise.
If the Linux users were vastly out of line, I'd question them. Instead they are inline with the Steam survey. Anyway, the idea that Mac users are not big games is about as controversial as the color of the sky.
That makes sense. I was just a bit confused. I wasn't aware that's how the wishlist was used by some. With that said, I imagine Linux users are probably more familiar with that use than Mac users (i.e., power user vs. casual user). But, if it's representative of the Steam survey, then I suppose it's as good a metric as any.
Regardless, I definitely didn't mean to imply that Mac users are big gamers. Most Macs are MacBooks and most people don't buy a laptop primarily for gaming. It'd be a secondary concern. There's also a chicken and egg situation in which Mac users may not be big gamers because there's not many games for Macs (not to mention that Steam runs terribly and is buggy on M-series Macs). Any Mac users that are big gamers probably have a console and/or PC (like myself) due to this situation, so any wishlisting is done on the device I play games on, despite the desire to be able to play on the go on my MacBook. Any Mac users that aren't big gamers may be due to having limited games. My wife who isn't a big gamer, but does like to play games occasionally, is relegated to using Bootcamp on her iMac.
Of course, that’s assuming that Steam is where all Mac users go to get games. Some of the bigger Mac titles like World of Warcraft aren’t on Steam, so it’s not hard to imagine a Mac user who more casually games not bothering to download Steam because their needs are met elsewhere.
Lag time in port availability also probably factors in too. If you open Steam on a Mac you’re shown a bunch of brand new games without Mac ports… if you don’t dig a little deeper it gives one the impression that they don’t have many Mac games and isn’t worth bothering with.
It does not sound like you have a better data source and are working backwards to explain the discrepancy.
Instead it sounds like you are reaching for excuses to ignore what you wish to be not-true. You clearly care a lot about gaming on Mac. Sadly Apple does not care. Hence how a rather decent US PC market share translates to trivial games market share.
When Apple starts caring they have the money to buy ports. There is no need for excuses.
I would say I care more about games being multiplatform by default (as most other software is now) than I do specifically Mac gaming. For playing games I have a custom built Windows tower, but would rather that not be necessary. While the situation has improved dramatically on Linux in the past few years it still has notable gaps (practically all of VR for example), and so the Windows partition persists.
Windows isn't my primary operating system because gaming isn't the primary thing I use my computer for.
I code, and in a similar way doing software development on Mac and Windows appears to be "just run Linux in a VM and pretend to use the primary operating system".
Because the experience of gaming on Steam Deck's SteamOS is better. Because I already have a MacBook and occassionally want to play a round of Civilization or Victoria 3 on it.
Removing OS silos for gaming is amazing, Valve really opened the floodgates with Proton. Windows, Linux and now macOS all being able to run same games is just great.
What's the point of censoring only one character from the word "fucking"? Both you and everyone that reads your comment know exactly what you are saying, so it's not like you are shielding anyone from anything. And neither is there anyone who is going to punish you for saying a naughty word on the internet. What are you afraid is going to happen if you write "fucking"?
I genuinely want to know the real answer, because this kind of behaviour confuses me. And every time I ask someone about it they don't answer, or give a non-answer.
If HN blocked comments with certain words, I'd understand.
If you genuinely find fuck an offensive word, and instead chose to use some other word instead, I would understand.
But this makes no sense. Please be so kind as to explain.
It is a stylistic device that serves as a sort of emphasis. Rhetorically censoring all or part calls attention to it as profanity.
You hear an analogous effect used a lot in spoken speech (definitely in the UK, not sure about USA), for example, "ff-<beat>-in' thing". This stresses it in a way, similar to varying tone or volume, that would be missed in a flat reading.
That's an interesting theory, but I don't believe any of it.
There are many better ways of calling attention, or adding emphasis to profanity without having to resort to making it look less profane.
And in the specific case of the comment I replied to it does not look like they were particularly angry or frustrated enough to apply this technique of yours to just one word, while the rest of the sentence is fairly innocuous. And I further doubt that if any (neutral) literary analysis were to be applied to that comment, that people would think that stormking was so angry that they were actually trying to apply any kind of emphasis the profanity.
Emphasis not just in the narrow sense of showing intense emotion, but rather the general concept of giving a sentence rhythm and prosody, often to highlight a wry or ironic situation. Your analysis is correct that GP likely did not do it entirely to invite readers to get annoyed on their behalf, but rather to humourously focus on the contrast between the arduity of setting up and waiting for a dual-boot on one hand, and playing a "f*cking game" on the other.
> There are many better ways of calling attention
Written expression is a form of art, not a formula with a correct answer.
I think you’re looking at it the wrong way. If you’re happy using Windows there’s no reason to stop using it. But a computer is capable of many more things than playing games and many of us prefer doing those things on macOS. This allows us to have the best of both worlds. If you don’t want it you’re under no obligation to take it.
Because you don't want to use Windows? I use Linux for gaming becasue I use Linux in general. Wine / dxvk / vkd3d-proton do a great job of helping to run games, but native games on Linux would be still better.
Some developers noticed this when Valve released the Steam Deck and Proton. Some had Linux ports but they were slow and didn't work perfectly. They just removed those and let the SD run the windows version through Proton. Boom, Linux version :D
The GPU in the M series chips is pretty good and if your software is optimized, it can run great. They also have great battery life even when playing games. Unfortunately, Apple has ignored game developers for a long time and even now they don't permit redistribution of the game porting toolkit
I haven't gotten a clear answer on what exactly this is. Is it a developer tool? Or is it like Wine? Can I just run an unmodified DX12 game from a Windows .exe on my Mac? If not, what's the process to port it? What portion of development work of porting a game does this cover?
It is a developer tool, and it is Wine. It sure seems like you can just run an unmodified DX12 game from a Windows .exe on your Mac, provided you're running the latest beta OS.
Yes, but the goal is developers to use that to come up with rough estimates for performance if they did optimizations. Users aren’t meant to directly use it - it’s a launching point for developers.
Also it’s more special than Proton for Mac because Proton does DirectX to Vulkan (needing a second round for Vulkan to Metal through MoltenVK), this is DirectX to Metal.
Right. The real reason appears to be helping developers figure out “is it worth the time to try and port my game to the Mac, or am I going to go through it all and end up at five frames per second?“
This isn’t quite true or at least doesn’t tell the whole story. This tool can do things that Wine can’t today. Namely supporting DX12 games. That support was added by Apple.
Wine generally doesn't really bother with any recent DirectX API's. However, vkd3d has been available as a means to play DirectX 12 games on Linux for a while now.
Of course Apple has split off their graphics API so they had to do the translation work for Metal themselves, but playing DX12 games on Wine isn't all that special.
So at this point we got the following rendering paths for DX12 on wine:
- Mainline D3D12 implementation on stock Wine;
- Proton (Which in theory should be just the "unstable" channel of the wine reference implementation plus some Gallium/VKDX/Valve specific stuff) plus a bunch of branches floating around (proton-ge, lutris custom builds, etc) ;
- Crossover (on the other side, this should lean on the safer side compared to reference wine, with just a bunch of explicitly whitelisted games);
- And now, the Game Porting Toolkit by Apple.
I wonder if there's some serendipity between those projects or we're gonna end up with some games running on some specific branch of Proton DX12, others stuck on mainline wine, and others for a reason or another working correctly just on Metal.
The PC gaming market is expected to be worth something north of $200bn in 2023, and (despite ongoing insanity among graphics cards manufacturers) is expected to keep growing in the coming years.
Apple has been doing their usual thing, with slowly moving pieces into place, but it's been pretty clear that they're ultimately going to go for a slice of that cake. Aside for mobile gaming, it's essentially an untapped market for them, given the footprint they now have with their devices. Also, they're going to want to shift the VR game development efforts to the Vision, in time for the release of the non-Pro version.
It'd be smart of them to partner, or at least cooperate with, Valve around this, but I'm not so sure about that one. Apple _might_ have enough hubris that they'd try to supplant Steam rather than work with it. This would be a mistake in my opinion.
Can you imagine anyone inside apple being passionate about supporting Steam? The app even after decades of work is so insanely janky even on its primary platform.
Honestly feels like a fractal of hacks upon hacks. Makes something like Slack feel native.
I know people are passionate about it because their games are locked into the service but the UI is godawful.
> Apple hid something AMAZING for Mac gaming at WWDC: a full Windows DirectX 12 gaming emulator.
Windows ... emulator? Does this mean we can now play old Windows EXE games? E.g. can I now run Fallout 2 and 3 like I did on an old Intel Mac with Crossover?
Can it also run Windows apps which don't use DirectX? I need some for work and have to use Parallels now.
Does it support Windows crypto APIs (certificates etc)?
It's Wine with some special sauce (Apple couldn't reuse VKD3D because they chose to invent Metal rather than stick with OpenGL/Vulkan so they had to build their graphics translation themselves). Crossover is built on the same technology. In fact, Apple's brew script literally links to Crossover's sources: https://raw.githubusercontent.com/apple/homebrew-apple/main/...
Apple's version of Wine is aimed at developers, though. It shouldn't take too long for someone to make an app or script to easily set up environments with the developer runtime, but I doubt they'll support it as well as Valve supports Proton. If your application of choice doesn't need any fancy graphics, there's a decent chance Wine/Crossover can already run it anyway, no need to mess with Apple's SDK.
With the M2 Max outputting 28fps at 1080p (screenshot linked), I wouldn't expect too much from the gaming performance of this thing, though.
OpenGL was a technological dead-end and Vulkan came 2 years after Metal, which as stated, came about because OpenGL was a technological dead-end. Besides, mobile gaming with Metal has been reasonably successful, whichever way you slice it.
Vulkan born out of Mantle which was released before Metal. Of course, Mantle wasn't openly developed in the beginning, but AMD and Apple were still partners in the GPU space back then. I don't see why Apple and AMD wouldn't cooperate in this space. Mantle would've been a much bigger success outside of the console market if iOS also used it, and Apple could have helped shape Mantle if they got in at the ground floor.
I know Apple isn't exactly a company that's open to adopting other people's standard when they might as well develop their own, but the split from the other API standards was still a choice they made.
I never thought Wine/Crossover can work on M2. Isn't the M2 CPU totally different from what ordinary Windows apps are meant to be ran on? I know there there is an Arm Windows version and apps built for it but there aren't many.
macOS runs x64 executables just fine through Rosetta so I don't see why Wine couldn't make use of that hardware acceleration.
It's also possible to only simulate the entrypoints through Rosetta and then execute native aarch64 code from there. On Linux https://github.com/ptitSeb/box64 does exactly that, for example. However, with the performance Apple has been able to squeeze out of Rosetta, I'm not sure of that workaround is even necessary.
This isn't the DX12 emulator itself, right? It's just a patch to crossover which makes it use the emulator which is proprietary and bundled with the OS (or Xcode)?
From a quick look, the patch doesn't seem to contain references to Metal, but just a lot of random updates—backports from upstream Wine to the CrossOver thing?—including an AMD ADL implementation that is clearly for Linux (using /sys/class/… stuff). Maybe the whole toolkit is… literally just CrossOver?
Nope. The Game Porting Toolkit itself contains a large `D3DMetal` framework that directly translates Direct3D calls into Metal. The Homebrew repo is only part of the toolkit. To actually use it, you have to move the Direct3D -> Metal translation layer into installed Homebrew prefix. From Apple's README:
The graphics bridge libraries need to be placed inside your Wine prefix in order to finalize your game evaluation environment. These instructions assume you have mounted the Game Porting Toolkit at /Volumes/Game Porting Toolkit-1.0.
• Copy the Game Porting Toolkit library directory into Wine’s library directory.
I play civ 5 from time to time, and it is a cross-platform (Linux, Mac, Windows). Why don't other gaming companies do what civ devs do to make it cross-platform? I understand why companies would make games on Windows exclusively if it was 10 years ago, but AFAIK, there already exist many cross-platform development tools you can leverage.
Porting your existing stack to new platforms is hard. The much, much harder part is getting your stack running on the new platform at a similar level of stability to the existing platforms. Corner cases and subtle incompatibilities all combine to make 'workaround soup'. It takes a lot of engineering work to support these platforms. The first 90% is bring up, the next 90% is stability.
Hell, something as basic as shipping a working binary for a non-trivial executable on Linux is a bit of a sick joke. Let alone having to support several windowing systems, and a whole bunch of new platform specific bugs in sound systems, graphics drivers, desktop environments, controller APIs.
Mac and Linux have just never been worth the tiny market for large studios. Many games using Unity and Unreal, which can target MacOS and Linux, don't bother providing Linux and MacOS builds because the development and support burden is too high for the number of users they'd gain.
It mostly boils down to the used game engine: Civ 5 is written in a custom engine (LORE), where you can choose which platforms to support. Other engines might make it easy (Unity), hard (Unreal), or impossible (Frostbite) to support Linux and Mac natively.
Platform support is of course an argument when choosing an engine.
Y'all are going to have a fun time when you realize the sad state of most D3D12 renderers, or the fact that there are still relatively very few D3D12 compatible games. Stutters, PSOs created mid frames, shader compilation happening at all times...
The market has suddenly (and conveniniently) been opened up to users of the second largest computer manufacturer. It would be foolish for any developer to neglect the opportunity to capitalise on this market, and they should be scrambling to port their products across in a fit state.
Remember that this isn't a toolkit aimed at users and hackers, it's a developer toolkit.
Don't let perfect be the enemy of good - things are only going to get better.
Nope, the market is still closed. Firstly, it's against terms and conditions to release your game with that tool and they still want to force you to port it to Metal. It's a developer toolkit to help migrate.
Also, game developers have been burned time and time again by Apple's inability to have a stable API + forced updates to the new crappy API, so no, they still won't port.
The market has always been open. It's just Apple is trying to move the needle on the porting cost. Time will tell how significant that will be in actually convincing studios to invest.
If only they would also add support for writing on NTFS drives they would probably kill all the competition - who needs a Windows PC when you can have a Mac which can do everything you needed Windows for?
Can't you just plug a latest nVidia card to you MacBook with Thunderbolt when you need it? Also doesn't M2 have some sort of an accelerator built-in specifically for ML?
> Can't you just plug a latest nVidia card to you MacBook with Thunderbolt when you need it?
No, even when they shipped that support initially it barely worked and then support ended one OS release. Nvidia stopped shipping drivers so it hasn't been possible for around 6+ years now?
Looked into it extensively at the time and price and support wise I ended up having to build a PC to use Nvidia for 3D work (Octane Render).
> Also doesn't M2 have some sort of an accelerator built-in specifically for ML?
Yes, and it's good for a laptop but to put it in perspective M1 Max takes around 45-50 seconds to generate a Stable Diffusion image, 3090 takes around 5 seconds.
Very very sad news. I hoped to switch from a PC laptop to MacBookAir someday and use a GPU and other PCIe things over Thunderbolt whenever I would need them.
Apple used to support external GPUs on Intel-based Macs but they killed that when they switched over to ARM. It seems the new Mac Pro won't support internal PCIe GPUs either. You're just stuck with whatever GPU is built into the SOC now.
Anyone who needs an OS that is not a toy, that is relatively open (or rather, allows you to shoot yourself in the foot easily should you want to), that is not dependent on one "benevolent" dictator to not restrict what you can do.
For example, what useful things does Windows let you do which MacOS doesn't? The only thing I can name when comparing Windows to Linux, besides being able to run full-blown VisualStudio and Adobe, is app-level firewall, but Mac has LittleSnitch.
WSL for Unix compatible applications and not having to rely on brew, which is basically curl | sh for hipsters. Thirty years of backwards compatible apps. Thirty years of backwards compatible APIs. Doesn't ban you from their stores on a whim. Doesn't need a store even. Has a more sensible filesystem and organisation than MacOS (which is pretty damning considering how bad NTFS is). Actively, technically superior on every front then it comes to kernel or APIs, more hardened than anything Apple has ever put out.
Important to note that this is different than what Codeweavers did and the timing of both their announcements is purely coincidental.
https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...
Apple did contribute to the Wine codebase and have their own translation layer.
Performance and compatibility seem to be much better than what Codeweavers showed which is expected given the translation appears to be DXIL to MSIL instead of DX to VK to MS.
The Mac gaming Reddit has a bunch of people posting results
https://reddit.com/r/macgaming/hot
And someone’s already made a tool to simplify running games
https://github.com/IsaacMarovitz/Whisky/releases/tag/pre-0.2...
This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.
Things look very promising.
> This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.
I wish. Unfortunately the MetalD3D is proprietary under a very restrictive license. The rest is just Wine code written by Codeweavers.
I don't understand your pessimism. If Apple finds and fixes a gap in Wine's coverage/compatibility, those changes will necessarily be open source. Quite simply, any work which Apple does that could be useful to the wine project will be open source.
Obviously it would be nice if MetalD3D was also released under a better license, but it's hardly as though this omission is a big loss to the wine project.
Apple did not upstream anything to Wine here. They just use CodeWeavers code for macOS support, plus their own changes, and released a 20k line diff to be compliant.
The license to their translation layer(which is closed source) is very restrictive and basically only allows use for evaluation purposes.
> The license to their translation layer(which is closed source) is very restrictive
The Windows EULA didn't allow people who built their own computer to buy the cheaper OEM version of Windows. They were supposed to pay full retail.
I would expect to see people care about this license agreement restriction just as much as they did when they built their own PC and installed the OEM version of Windows on it.
Sure, just trying to correct the notion of this being a "win" for open source, Apple still hates anything GPL :)
>> If Apple finds and fixes
> Apple did not upstream anything to Wine here.
So what you're saying is that Apple didn't do anything useful for the Wine project and you're angry because after Apple did nothing, they failed to open source the nothing. Okay then. I don't follow you.
This is not really important since Metal is Apple-exclusive, right? It's not like it can be used on Linux
It's still not a great thing to do. Apple used to contribute a lot more, even if some of their stuff was exclusive to their platform. https://opensource.apple.com
They can’t really do anything because of the massive liabilities GPL v3 opens them up to.
My understanding; the license won’t allow them to settle if a third party seeks patent licensing from them over shipped GPL code - they have to ensure everyone using any derivative of the upstreamed code is also covered by that patent license.
That's largely down to GPL3, unfortunately.
But it would be useful for OSS to do translation from Metal to DirectX - Apple probasbly doesn't want that.
> MetalD3D is proprietary under a very restrictive license
Can you explain this. Game Porting Toolkit code is LGPL the same as Wine.
The Game Porting Toolkit contains a proprietary (143 MiB) D3DMetal framework that directly translates the Direct3D calls to Metal. They don't use the Direct3D --Wine--> Vulkan --MoltenVK--> Metal path that opensource Wine/CrossOver Wine uses.
So there is more information here:
https://www.reddit.com/r/macgaming/comments/142tomx/apples_g...
And the restrictive license part is this:
"you are granted a limited, non-exclusive, non-transferable, personal copyright license to (i) install, internally use, and test the Apple Software for the sole purpose of developing, testing, or evaluating video games for use on Apple-branded products"
That does look like they have their own shader ir converter. But the fact that there's d3d9-d3d12 there, and under a wine directory, means those parts, at least, are borrowed.
That this exists is hilariously self-defeating. Linux gaming is becoming Proton-driven, so with this and VKD3D, we're potentially looking at Direct3D 12 as the most widely supported cross-platform API. Why write Vulkan or Metal when D3D runs everywhere now?
Is it coincidental? From
https://raw.githubusercontent.com/apple/homebrew-apple/main/...
:
The release precedes CrossOver's 23 release with DirectX 12 support though. (Though you'd think that many bits are already there in prior releases.)Edit: I poked around a little in the game porting toolkit and it seems different. They have a D3DMetal framework, whereas CrossOver's Direct3D 12 support goes through MoltenVK.
Toolkit deprecated in 3 years after Apple assembles a large enough game library :)
These results are amazing. Diablo IV, Elden Ring, Cyberpunk running (albeit not smoothly) today.
It seems to me that Apple invented their own proprietary graphics technology (Metal), never supported a cross-platform one (Vulkan), then found not enough games ever supported Metal, so they added a translation layer for another proprietary graphics technology (DX12).
Wouldn't they have been better off just supporting Vulkan?
Metal was launched before Vulkan (2014 vs 2016), Vulkan was before Mantle from AMD that they donated to the Khronos group, it was in development and Apple is part of the group so they were aware of it, but I can understand that depending on consensus across multiple parties could delay Apple agenda, same for Microsoft that could ditched Dx in favour of Vulkan, but they aren't.
Apple is not part of Khronos now and there is a bit of a weird relationship between the two these days. Some details here: https://news.ycombinator.com/item?id=22539633
There have been (though don't quote me on this) stories about how everything Khronos standardizes reeks of design-by-committee, to the detriment of the final standard.
An obvious example would be OpenGL, which nobody has called a well-designed API.
But there's other misfires as well. OpenCL hasn't exactly set the world on fire compared to CUDA. OpenVG was a standard for accelerating 2D Graphics that was a little too late to matter. OpenXR? Well, at least Oculus is actually using it. WebGL? The W3C is working on replacing it with the (far superior) WebGPU. WebCL? Well, that was a JavaScript system for OpenCL, and that was as bad of an idea as it sounds.
And of course, most recent example: Vulkan. Almost everyone who has actually used Metal has commented on how it is much, much easier to hit the ground running than Vulkan, because Vulkan requires mountains of boilerplate. (It's also worth remembering that every iOS Developer builds for Metal, so it isn't like there isn't knowledge out there about how to use it - it's just among mobile game developers instead of the AAA developers).
I'm a graphics programmer and basically write Vulkan code full time. It's an amazing and excellent API with an absolutely crazy good documentation. I've done some DirectX and Metal work too, and while they are definitely less verbose, I find them much harder to use because I have to rely on my intuition and prior experience for how things interact with each other. With Vulkan, it's spelled out for me in the specification.
Yes, Vulkan comes with more boilerplate. But who cares? Vulkan was meant to write your engine in, not something you call directly from client game code. It works extremely well and Khronos deeply cares about Vulkan and continuously improves it. Part of the verbosity also comes from the fact that Vulkan scales from small embedded SoCs to big gaming GPUs and everything inbetween, so the API has to cover a lot of potential hardware quirks. Viewing Vulkan as a kinda low level HAL helps explain a lot of the verbosity.
Anyways, long story short, I absolutely love working with Vulkan and after having been Vulkan programmer since basically day 1 of its existence, you can take it from my cold dead hands.
Your comment isn't really that informed.
OpenGL wasn't designed by Khronos, rather it was designed by SGI and called GL. It was then given to Khronos and then maintained it.
OpenCL wasn't designed by Khronos either, rather it was designed by Apple and then given to Khronos to maintain. It was orphaned when Apple gave up on it, and not because of Kronos's leadership but rather Apple decided to go all in on Metal, their proprietary solution that did graphics and compute shaders.
Vulkan also wasn't fully designed by Khronos, rather it was based heavily on Molten from AMD, which was gifted to Khronos. It is much more widely used than Metal.
That said, benevolent dictators who are competent can out do committee decision making, but committee decision making is often better for an industry as a whole because it aligns different interest groups.
I'm out of date on the subject, but Apple joined Khronos[0], not sure when they left.
[0] https://www.khronos.org/news/permalink/apple_dell_google_and...
Is Vulkan the default API for any platform except a subset of the newest Android devices?
By default, pretty much every gaming platform has it's own proprietary graphics tech.
we've got Metal on Macs and iOS, DirectX on Windows and XBox, and Gnmx on Playstation.
You could say the same about Vulkan though (outside Android, Vulkan is mainly used to run D3D games on Linux via dxvk).
The D3D APIs are by far the most popular for PC games, so it makes a lot more sense to support D3D. Also, Vulkan on Mac is already supported "well enough" via MoltenVk.
The goal with Metal was making sure they own IOS, and now their new AR platform. Macs are selling well regardless. They are just a nice to have.
I think they are keeping an evil eye on asahi linux. As soon as that becomes viable, they'll act to keep people on OSX. Their worst nightmare would be steam actively moving to support proton on mac and doing things outside the apple store. Asahi linux would be the pre-cursor to that happening.
>As soon as that becomes viable, they'll act to keep people on OSX.
If you think that (even with a fully parity with say Ubuntu on Intel Asahi) people would move to Linux on their Mac on any number enough to even raise an eyebrow (much less worry) Apple, you are delluding yourself.
People buy Macs to run macOS. A very tiny minority buys Macs to run Linux on. A slightly larger (but still insignificant) minority will convert an old Mac laying around to Linux.
It's enough to get a project like Asahi support, not enough to make even a 1% dent on Apple's software/services ecosystem bottom line (the hardware side is the same, as those people are still buying a Mac anyway).
> As soon as that becomes viable
Linux on the Desktop - Apple Silicon edition.
And still no Miller columns. What a ripoff, I'm going back to Xserve...
I doubt they’ll do anything to Asahi. They went out of their way to add third party OS support to M-series Macs after deriving them from the famously single-OS iPad architecture. They’ve also said that they’d welcome Microsoft porting Windows to M-series Macs and wouldn’t do anything to stop it.
They clearly see the Mac a bit differently than they do the other iDevices.
You are getting me wrong. As soon as people start running games on Apple hardware outside of their software platform, they'll want to fix that. Asahi Linux is making rapid progress to enabling that. Hence the announcement of a porting toolkit. Imagine if they don't do that and then Steam suddenly announces rolling out proton to macs and the availability of their full catalog.
That's a scenario Apple would want to avoid. Hence the announcement of a porting kit.
Let's be real here, the vast, vast majority of Apple customers are never installing Asahi on their machine. Like, ever.
Again, you are misunderstanding me. Asahi Linux is doing a lot of hard work and open sourcing that. That in turn enables porting back some of that software to OSX. Steam on Mac so far runs without proton so it can't run a lot of things. The people developing Asahi Linux are doing a lot of hard work figuring out all the low level details of how the hardware platform works. The resulting software could be adapted to run inside of OS X. The hard part would be reverse engineering the hardware. Which is exactly what they are doing. And with the wide distribution of macs, it's obviously attractive for Valve and game studios to target that platform. Apple is responding to that threat by offering game studios an alternative.
Even if Asahi Linux is a big hit, it will be a minuscule drop in the ocean for Apple. Plus they make money from selling Macs.
They would have dumped it eventually even if they did. We can tell from the OpenCL debacle and a lot of the things going on in WebKit standards that a perfectly usable technology can exist but developers internal at Apple are only rewarded for building tech invented there.
> and the open source community toils tirelessly making baby steps.
FWIW, the Open Source community has had DXVK running >80% of the titles on Windows for years now. The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion. Writing and maintaining Wine is a feat Apple is not legally well-poised to do - without the tireless toiling of Open Source contributors, this feature would not exist.
So welcome back to gaming, Mac users. Let's hope this isn't a stopgap offering and more of a jumping-off point for DirectX9 coverage and the like.
> The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion
Assuming this thing takes-off and suddenly the RGB LED-illuminated crowd switch to Apple hardware and macOS, then it's a very depressing thought because it means Apple will veritably make hundreds of millions (billions?) of dollars off Codeweaver's (and their extended community)'s work - and they'll get-away with it because their revenue can be classed as hardware sales, and not software licensing.
I honestly don't know how to feel about this.
I do feel a pang of smugness seeing the (post-iPhone) Apple having to stop pretending that copyleft doesn't exist[1] but also seeing them acknowledging that ecosystems other than their own do actually exist, but ultimately favourable smirks are in no way any kind of compensation to the unpaid effort put in by many of Wine-and-co's devs.
I suppose Apple could do the decent thing and offer to acqui-hire Codeweavers et al., but that's more akin to a heavenly afterlife for Codeweavers' people (i.e. after acquisition Codeweavers would necessarily die along with their mission (beyond Apple's own self-serving uses) which might be a bigger disservice to everyone involved, especially the community.
----------
Unrelated-but-related: is any of Wine or Codeweavers' code under GPLv3? If so, that's might be the undoing of Apple's locked-down bootloaders: supposing that iOS, iPadOS or visionOS/xrOS includes DX12 compat via GPLv3-derived code: would Apple be legally obligated to explicitly allow users to install their own firmware contrary to their user-hostile, regressive, and (imo) indefensible policies so far?
-----
[1]: Apple avoids the GPL, but so do all the large incumbents (though of course, like literally everyone, Apple is now fairly on-board with MIT/BSD licenses) - I do note that the KHTML-derived WebKit retains its GPL licensing, is a single, huge, exception, but I also note that Apple, internally, heavily firewalls-off their WebKit devs from anything else. (I've visited Apple's offices in-person and while the pizza place in the central cafeteria is nice, the fact that their SWEs can't casually walk down the hallway into another product team's office and exchange misc advice is just downright _weird_ to me, that's why I withdrew my only application to work there)
Apple is only providing this as a developer tool, to help simulate existing Windows games on macOS such that they can be ported more easily. Apple won't officially support a "Windows-Rosetta", this is not meant for users and won't ever be supported on iOS/iPadOS.
Worth noting that Apple is not just riding Proton/Wine’s coattails. As I wrote on another comment:
Previously: DirectX -> Proton/WINE -> Vulkan -> MoltenVK -> Metal (yuck)
Now: DirectX -> Apple GPT (groan at my pun, Game Porting Toolkit) -> Metal
You could call it Proton with a Metal backend and more developer tools?
Definitely not. It's just funny to see the Open Source contributions reduced to "baby steps" because Apple had to play catch-up with their graphics API.
It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.
Apple won’t be making an effort to support anything.
This is a Developer tool to help developers figure out what it’s going to take to port their games to the Mac.
End-users don’t get to use it. You can’t bundle it with your game. The license forbids it.
It’s very interesting, and I’m sure the community will make the best use of it they can, but it isn’t designed to be the Mac Proton.
"figure out what it’s going to take to port their games to the Mac"
By running them on a DX12 translation layer that they can't utilise? What would be the use case then?
Since they use their own Direct3D on top of Metal (D3DMetal), you can immediately start investigating performance while not much of the game is ported yet. Even while running the game in Wine, you can already analyze graphics performance with Instruments.app.
At least this was the messaging in their talk about this: first you had to work months on a port to see how well a game would work on Mac hardware, now you can immediately run it, investigate bottlenecks and see where a port would land performance-wise before putting in any of the work.
I wonder if they will make the D3DMetal usable from native code as well, I can imagine that would make porting much easier:
- First you run on Wine + D3DMetal to get idea if your game would run well enough on Apple hardware at all.
- Then you start building the game natively, still using D3DMetal, so that you don't have to immediately port the graphics stuff.
- Once you have a running game on top of D3DMetal, you start porting it over to Metal with their shader converters, etc.
There is so much more to a modern engine than just 3D graphics. Sound, input, windowing integration, high-speed disk streaming IO, networking, robust OS integration (where to store save files, etc), just compiling it. Problem is that testing most of this depends on having a working renderer to display the game. This tool allows getting something on the screen faster so you can test everything all at once instead of having a bunch of sound, networking and platform engineers waiting around for the rendering team to get their part working.
Dunno about Apple's version but with Wine you can linnk native code against winelib, allowing you to test what you have already ported before you got everything up and running.
Of course if Vulkan was a suppoted API on macOS, developers could just port to Vulkan on Windows and then implement the rest on macOS.
I think that’s true today but it could change. I imagine Apple wants to encourage developers to build native games but I could see them loosening restrictions down the road. Maybe they eventually position this tech as the Bootcamp alternative for Apple Silicon. Time will tell.
If they do that, that’s basically giving up on Metal. It would become an implementation detail.
Also, whenever the Direct3D API changes, they would have to follow. That makes them dependent on Microsoft and means they’d always lag them.
Because of that, I don’t see them open this up.
Gaming on Apple is going to depend on how well optimized the drivers and shaders for the GPU are going to be. You'll also need some serious upscaling because most Macs come with super high res screens, a GPU that won't be able to drive modern games at those resolutions and an utterly lack of graphics card support, even in the new Pro.
Another factor is that major GPU companies put efforts into rewriting some games' shaders to make them run better on their hardware. I doubt Apple is going to do that so you'll probably end up with games performing better on other platforms soon after release.
There's more to getting games to run smoothly on a platform than compatibility software. So far, the GPU has been lacking despite Apple's attempts to hype up gaming for mac. With the rate things are going, the year of gaming on Mac may be the same as the mythical year of the Linux desktop: inching ever closer but never really arriving.
There's no need to run games at those high resolutions natively. Modern games now render only stuff like UI at the monitor's native resolution while the 3D viewport is rendered at a lower resolution and then potentially upscaled using DLSS or FSR.
Apple has MetalFX upscaling: https://developer.apple.com/documentation/metalfx
Linux is so much better for gaming, including in hardware options. Apple just doesn't compare.
Not sure why you're downvoted, it's a fact that Linux is way better for gaming and powerful desktop hardware.
> Not sure why you're downvoted
Butthurt mac users that don't like to think their toy is worse somehow, obviously.
So in the end... the easiest way to develop cross-platform PC games is just target Windows and Direct3D 12, and let Wine/other D3D12 emulators handle the heavy lifting.
As a user... Tell me why I shouldn't just run games directly on Windows, the native platform?
As a user... Tell me why I shouldn't just run games directly on Windows, the native platform?
If you’re fine with using Windows then knock yourself out! I just came from another thread where people were complaining bitterly about the nonsense and dark patterns Microsoft is pumping into Windows to monetize users to the hilt. Frankly, I’d rather just avoid all of that!
If you're ok with everything else that comes with windows, that's fine. I'd rather not. I don't want to deal with its shell, update schedule, ad pushing, etc. for example so the emulator is a better approach for me.
I'd like to have my cake and eat it too.
Playing the same game on Linux, an OS that doesn't disrespect me as a user, is awesome!
And +10 years ago nobody thought to play on Mac. But now with the market share they have… Hard to ignore as a business and if Apple do all the heavy lifting for us games are going to come on Mac.
> . But now with the market share they have… Hard to ignore as a busines
That is not true at all. Ignoring Mac as a gamedev is one of the easiest decisions we've ever made at every studio I worked at. Even the studio where the boss used a Mac! The market share is minuscule and lacks even the Steamdeck and proton pushing linux support into Steam games.
That Apple saw fit to half-effort this tooling then lock it behind a license which prevents gamedevs shipping with it, and steam from packaging it, means Apple has yet again demonstrated their time tested poor support for games.
How are you defining miniscule market share? Per statcounter macOS is 19% globally now and 34% in the US. It's much higher than in the past.
Statcounter is websites, games are not websites and you need to use an appropriate data source. Steam reports 1-2% for Mac users. My own game's wishlist stats are showing Mac is less popular than linux!
> My own game's wishlist stats are showing Mac is less popular than linux!
If you're talking about Railgrade (from your bio), couldn't that simply be because your game only shows as supporting Windows? Why would a Mac user wishlist a game they can't play? Linux users have had Proton for a few years now and the discussed Mac toolkit was only announced a couple days ago.
The platform wishlist breakdown occurs when players make a specific choice. Players use it as a "vote" for their platform. Thus Linux users are voting for Linux trying to convince us as devs to support them, Mac users are doing likewise.
If the Linux users were vastly out of line, I'd question them. Instead they are inline with the Steam survey. Anyway, the idea that Mac users are not big games is about as controversial as the color of the sky.
That makes sense. I was just a bit confused. I wasn't aware that's how the wishlist was used by some. With that said, I imagine Linux users are probably more familiar with that use than Mac users (i.e., power user vs. casual user). But, if it's representative of the Steam survey, then I suppose it's as good a metric as any.
Regardless, I definitely didn't mean to imply that Mac users are big gamers. Most Macs are MacBooks and most people don't buy a laptop primarily for gaming. It'd be a secondary concern. There's also a chicken and egg situation in which Mac users may not be big gamers because there's not many games for Macs (not to mention that Steam runs terribly and is buggy on M-series Macs). Any Mac users that are big gamers probably have a console and/or PC (like myself) due to this situation, so any wishlisting is done on the device I play games on, despite the desire to be able to play on the go on my MacBook. Any Mac users that aren't big gamers may be due to having limited games. My wife who isn't a big gamer, but does like to play games occasionally, is relegated to using Bootcamp on her iMac.
Of course, that’s assuming that Steam is where all Mac users go to get games. Some of the bigger Mac titles like World of Warcraft aren’t on Steam, so it’s not hard to imagine a Mac user who more casually games not bothering to download Steam because their needs are met elsewhere.
Lag time in port availability also probably factors in too. If you open Steam on a Mac you’re shown a bunch of brand new games without Mac ports… if you don’t dig a little deeper it gives one the impression that they don’t have many Mac games and isn’t worth bothering with.
It does not sound like you have a better data source and are working backwards to explain the discrepancy.
Instead it sounds like you are reaching for excuses to ignore what you wish to be not-true. You clearly care a lot about gaming on Mac. Sadly Apple does not care. Hence how a rather decent US PC market share translates to trivial games market share.
When Apple starts caring they have the money to buy ports. There is no need for excuses.
I would say I care more about games being multiplatform by default (as most other software is now) than I do specifically Mac gaming. For playing games I have a custom built Windows tower, but would rather that not be necessary. While the situation has improved dramatically on Linux in the past few years it still has notable gaps (practically all of VR for example), and so the Windows partition persists.
A lot of games on Steam, GOG, HumbleBundle were Linux and Mac as well
Didn't a bunch of old ones get their compatibility tossed when Apple went 64-bit?
If you are fine with Windows, then do it.
Windows isn't my primary operating system because gaming isn't the primary thing I use my computer for.
I code, and in a similar way doing software development on Mac and Windows appears to be "just run Linux in a VM and pretend to use the primary operating system".
As a user... I prefer to use Linux for everything else. Until not long ago, I was restricted to Windows due to my gaming habits.
Now I can run Linux as my daily driver, since I can run games properly.
Because the experience of gaming on Steam Deck's SteamOS is better. Because I already have a MacBook and occassionally want to play a round of Civilization or Victoria 3 on it.
Removing OS silos for gaming is amazing, Valve really opened the floodgates with Proton. Windows, Linux and now macOS all being able to run same games is just great.
Because I work on MacOS and I will certainly not reboot my computer just to play a f*cking game?
What's the point of censoring only one character from the word "fucking"? Both you and everyone that reads your comment know exactly what you are saying, so it's not like you are shielding anyone from anything. And neither is there anyone who is going to punish you for saying a naughty word on the internet. What are you afraid is going to happen if you write "fucking"?
I genuinely want to know the real answer, because this kind of behaviour confuses me. And every time I ask someone about it they don't answer, or give a non-answer.
If HN blocked comments with certain words, I'd understand.
If you genuinely find fuck an offensive word, and instead chose to use some other word instead, I would understand.
But this makes no sense. Please be so kind as to explain.
It is a stylistic device that serves as a sort of emphasis. Rhetorically censoring all or part calls attention to it as profanity.
You hear an analogous effect used a lot in spoken speech (definitely in the UK, not sure about USA), for example, "ff-<beat>-in' thing". This stresses it in a way, similar to varying tone or volume, that would be missed in a flat reading.
That's an interesting theory, but I don't believe any of it.
There are many better ways of calling attention, or adding emphasis to profanity without having to resort to making it look less profane.
And in the specific case of the comment I replied to it does not look like they were particularly angry or frustrated enough to apply this technique of yours to just one word, while the rest of the sentence is fairly innocuous. And I further doubt that if any (neutral) literary analysis were to be applied to that comment, that people would think that stormking was so angry that they were actually trying to apply any kind of emphasis the profanity.
Emphasis not just in the narrow sense of showing intense emotion, but rather the general concept of giving a sentence rhythm and prosody, often to highlight a wry or ironic situation. Your analysis is correct that GP likely did not do it entirely to invite readers to get annoyed on their behalf, but rather to humourously focus on the contrast between the arduity of setting up and waiting for a dual-boot on one hand, and playing a "f*cking game" on the other.
> There are many better ways of calling attention
Written expression is a form of art, not a formula with a correct answer.
I do it sometimes to weaken the word.
Their u key is broken
With M1 CPU and above, you can't even reboot into windows anymore
I think you’re looking at it the wrong way. If you’re happy using Windows there’s no reason to stop using it. But a computer is capable of many more things than playing games and many of us prefer doing those things on macOS. This allows us to have the best of both worlds. If you don’t want it you’re under no obligation to take it.
Because you don't want to use Windows? I use Linux for gaming becasue I use Linux in general. Wine / dxvk / vkd3d-proton do a great job of helping to run games, but native games on Linux would be still better.
Because you don't have Windows?
Yes, that's the way.
Some developers noticed this when Valve released the Steam Deck and Proton. Some had Linux ports but they were slow and didn't work perfectly. They just removed those and let the SD run the windows version through Proton. Boom, Linux version :D
The GPU in the M series chips is pretty good and if your software is optimized, it can run great. They also have great battery life even when playing games. Unfortunately, Apple has ignored game developers for a long time and even now they don't permit redistribution of the game porting toolkit
Because Windows is absolutely horrible and I'd rather not use Windows?
People get older and might want to play sometimes a game.
Having it as an option when I travel business would be great.
And I don't play every week anymore but I will play certain games.
It solves the itch without needing a ps5 or a PC.
I prefer Linux to Windows 10/11 because Windows has telemetry and uncontrolled updates. Windows 7 is fine, though.
> why I shouldn't just run games directly on Windows, the native platform?
Because DXVK is cool, and in many cases better.
because windows is a frustrating brittle operating system that doesn't do what i want it to do
I haven't gotten a clear answer on what exactly this is. Is it a developer tool? Or is it like Wine? Can I just run an unmodified DX12 game from a Windows .exe on my Mac? If not, what's the process to port it? What portion of development work of porting a game does this cover?
Edit: More information here: https://www.digitaltrends.com/computing/apple-enabled-thousa...
It is a developer tool, and it is Wine. It sure seems like you can just run an unmodified DX12 game from a Windows .exe on your Mac, provided you're running the latest beta OS.
Latest beta OS isn’t necessary. It works on macOS Ventura.
The latest Beta of macOS? Does it have wine built in??
Yes, but the goal is developers to use that to come up with rough estimates for performance if they did optimizations. Users aren’t meant to directly use it - it’s a launching point for developers.
Also it’s more special than Proton for Mac because Proton does DirectX to Vulkan (needing a second round for Vulkan to Metal through MoltenVK), this is DirectX to Metal.
Right. The real reason appears to be helping developers figure out “is it worth the time to try and port my game to the Mac, or am I going to go through it all and end up at five frames per second?“
You can checkout r/macgaming on reddit, people are already experimenting running windows games.
To be 100% crystal clear, this is a Wine distro. https://www.osnews.com/story/136223/apples-game-porting-tool...
This isn’t quite true or at least doesn’t tell the whole story. This tool can do things that Wine can’t today. Namely supporting DX12 games. That support was added by Apple.
Wine generally doesn't really bother with any recent DirectX API's. However, vkd3d has been available as a means to play DirectX 12 games on Linux for a while now.
Of course Apple has split off their graphics API so they had to do the translation work for Metal themselves, but playing DX12 games on Wine isn't all that special.
So at this point we got the following rendering paths for DX12 on wine:
- Mainline D3D12 implementation on stock Wine;
- Proton (Which in theory should be just the "unstable" channel of the wine reference implementation plus some Gallium/VKDX/Valve specific stuff) plus a bunch of branches floating around (proton-ge, lutris custom builds, etc) ;
- Crossover (on the other side, this should lean on the safer side compared to reference wine, with just a bunch of explicitly whitelisted games);
- And now, the Game Porting Toolkit by Apple.
I wonder if there's some serendipity between those projects or we're gonna end up with some games running on some specific branch of Proton DX12, others stuck on mainline wine, and others for a reason or another working correctly just on Metal.
The PC gaming market is expected to be worth something north of $200bn in 2023, and (despite ongoing insanity among graphics cards manufacturers) is expected to keep growing in the coming years.
Apple has been doing their usual thing, with slowly moving pieces into place, but it's been pretty clear that they're ultimately going to go for a slice of that cake. Aside for mobile gaming, it's essentially an untapped market for them, given the footprint they now have with their devices. Also, they're going to want to shift the VR game development efforts to the Vision, in time for the release of the non-Pro version.
It'd be smart of them to partner, or at least cooperate with, Valve around this, but I'm not so sure about that one. Apple _might_ have enough hubris that they'd try to supplant Steam rather than work with it. This would be a mistake in my opinion.
Can you imagine anyone inside apple being passionate about supporting Steam? The app even after decades of work is so insanely janky even on its primary platform.
Honestly feels like a fractal of hacks upon hacks. Makes something like Slack feel native.
I know people are passionate about it because their games are locked into the service but the UI is godawful.
> Apple hid something AMAZING for Mac gaming at WWDC: a full Windows DirectX 12 gaming emulator.
Windows ... emulator? Does this mean we can now play old Windows EXE games? E.g. can I now run Fallout 2 and 3 like I did on an old Intel Mac with Crossover?
Can it also run Windows apps which don't use DirectX? I need some for work and have to use Parallels now.
Does it support Windows crypto APIs (certificates etc)?
It's Wine with some special sauce (Apple couldn't reuse VKD3D because they chose to invent Metal rather than stick with OpenGL/Vulkan so they had to build their graphics translation themselves). Crossover is built on the same technology. In fact, Apple's brew script literally links to Crossover's sources: https://raw.githubusercontent.com/apple/homebrew-apple/main/...
Things like the crypto API should be implemented if you can find the reference for your specific API calls here: https://github.com/wine-mirror/wine/tree/master/dlls/crypt32
Apple's version of Wine is aimed at developers, though. It shouldn't take too long for someone to make an app or script to easily set up environments with the developer runtime, but I doubt they'll support it as well as Valve supports Proton. If your application of choice doesn't need any fancy graphics, there's a decent chance Wine/Crossover can already run it anyway, no need to mess with Apple's SDK.
With the M2 Max outputting 28fps at 1080p (screenshot linked), I wouldn't expect too much from the gaming performance of this thing, though.
OpenGL was a technological dead-end and Vulkan came 2 years after Metal, which as stated, came about because OpenGL was a technological dead-end. Besides, mobile gaming with Metal has been reasonably successful, whichever way you slice it.
Vulkan born out of Mantle which was released before Metal. Of course, Mantle wasn't openly developed in the beginning, but AMD and Apple were still partners in the GPU space back then. I don't see why Apple and AMD wouldn't cooperate in this space. Mantle would've been a much bigger success outside of the console market if iOS also used it, and Apple could have helped shape Mantle if they got in at the ground floor.
I know Apple isn't exactly a company that's open to adopting other people's standard when they might as well develop their own, but the split from the other API standards was still a choice they made.
What's the problem with OpenGL? It always did its job great, didn't it?
Have you ever written something that uses it?
> It shouldn't take too long for someone to make an app or script to easily set up environments with the developer runtime
There you go: https://github.com/IsaacMarovitz/Whisky
Here is a bit more promising sample about the performance on M2 Max: https://www.reddit.com/r/macgaming/comments/1435ukq/cyberpun...
I never thought Wine/Crossover can work on M2. Isn't the M2 CPU totally different from what ordinary Windows apps are meant to be ran on? I know there there is an Arm Windows version and apps built for it but there aren't many.
macOS runs x64 executables just fine through Rosetta so I don't see why Wine couldn't make use of that hardware acceleration.
It's also possible to only simulate the entrypoints through Rosetta and then execute native aarch64 code from there. On Linux https://github.com/ptitSeb/box64 does exactly that, for example. However, with the performance Apple has been able to squeeze out of Rosetta, I'm not sure of that workaround is even necessary.
> like I did on an old Intel Mac with Crossover?
I _think_ you can run crossover with rosetta and still do this, that is basically what this is plus a DX12 -> Metal translation module
I recommend having a look at Fallout 2 CE. It's reverse engineered Fallout 2 with improvements, should compile for most platforms sdl2 runs on.
https://github.com/apple/homebrew-apple/tree/main
This isn't the DX12 emulator itself, right? It's just a patch to crossover which makes it use the emulator which is proprietary and bundled with the OS (or Xcode)?
From a quick look, the patch doesn't seem to contain references to Metal, but just a lot of random updates—backports from upstream Wine to the CrossOver thing?—including an AMD ADL implementation that is clearly for Linux (using /sys/class/… stuff). Maybe the whole toolkit is… literally just CrossOver?
Nope. The Game Porting Toolkit itself contains a large `D3DMetal` framework that directly translates Direct3D calls into Metal. The Homebrew repo is only part of the toolkit. To actually use it, you have to move the Direct3D -> Metal translation layer into installed Homebrew prefix. From Apple's README:
The graphics bridge libraries need to be placed inside your Wine prefix in order to finalize your game evaluation environment. These instructions assume you have mounted the Game Porting Toolkit at /Volumes/Game Porting Toolkit-1.0. • Copy the Game Porting Toolkit library directory into Wine’s library directory.
They literally made a new Direct3D implementation on top of Metal.The actual interesting bit is at the end of the patch, in `static void init_non_native_support` where they dlopen a proprietary MetalD3D dylib.
I play civ 5 from time to time, and it is a cross-platform (Linux, Mac, Windows). Why don't other gaming companies do what civ devs do to make it cross-platform? I understand why companies would make games on Windows exclusively if it was 10 years ago, but AFAIK, there already exist many cross-platform development tools you can leverage.
Porting your existing stack to new platforms is hard. The much, much harder part is getting your stack running on the new platform at a similar level of stability to the existing platforms. Corner cases and subtle incompatibilities all combine to make 'workaround soup'. It takes a lot of engineering work to support these platforms. The first 90% is bring up, the next 90% is stability.
Hell, something as basic as shipping a working binary for a non-trivial executable on Linux is a bit of a sick joke. Let alone having to support several windowing systems, and a whole bunch of new platform specific bugs in sound systems, graphics drivers, desktop environments, controller APIs.
Mac and Linux have just never been worth the tiny market for large studios. Many games using Unity and Unreal, which can target MacOS and Linux, don't bother providing Linux and MacOS builds because the development and support burden is too high for the number of users they'd gain.
It mostly boils down to the used game engine: Civ 5 is written in a custom engine (LORE), where you can choose which platforms to support. Other engines might make it easy (Unity), hard (Unreal), or impossible (Frostbite) to support Linux and Mac natively.
Platform support is of course an argument when choosing an engine.
I play Civ 6 and it's also "cross platform". Except when it's not.
The PC and (M1/2) Mac versions were out of sync for a few months, making multiplayer games between those impossible.
Worked perfectly with PC + Steam Deck though.
Civ 6 used to not feature cross play between Linux and Windows, because of platform differences with SQLite.
SQLite is known for compatibility. I'm curious what platform difference was
This was circa 2016-2017, so it's gonna take some digging. I'll see what I can do.
Y'all are going to have a fun time when you realize the sad state of most D3D12 renderers, or the fact that there are still relatively very few D3D12 compatible games. Stutters, PSOs created mid frames, shader compilation happening at all times...
Here's someone running Diablo IV on their MacBook Pro at over 60 FPS: https://www.reddit.com/r/macgaming/comments/14307be/diablo_i...
The market has suddenly (and conveniniently) been opened up to users of the second largest computer manufacturer. It would be foolish for any developer to neglect the opportunity to capitalise on this market, and they should be scrambling to port their products across in a fit state.
Remember that this isn't a toolkit aimed at users and hackers, it's a developer toolkit.
Don't let perfect be the enemy of good - things are only going to get better.
Nope, the market is still closed. Firstly, it's against terms and conditions to release your game with that tool and they still want to force you to port it to Metal. It's a developer toolkit to help migrate.
Also, game developers have been burned time and time again by Apple's inability to have a stable API + forced updates to the new crappy API, so no, they still won't port.
The market has always been open. It's just Apple is trying to move the needle on the porting cost. Time will tell how significant that will be in actually convincing studios to invest.
If only they would also add support for writing on NTFS drives they would probably kill all the competition - who needs a Windows PC when you can have a Mac which can do everything you needed Windows for?
Anyone who needs top of the line gpu performance.
M series is great but once you’re on desktops it gets left in the dust by Nvidia for 3D and ML.
Can't you just plug a latest nVidia card to you MacBook with Thunderbolt when you need it? Also doesn't M2 have some sort of an accelerator built-in specifically for ML?
> Can't you just plug a latest nVidia card to you MacBook with Thunderbolt when you need it?
No, even when they shipped that support initially it barely worked and then support ended one OS release. Nvidia stopped shipping drivers so it hasn't been possible for around 6+ years now?
Looked into it extensively at the time and price and support wise I ended up having to build a PC to use Nvidia for 3D work (Octane Render).
> Also doesn't M2 have some sort of an accelerator built-in specifically for ML?
Yes, and it's good for a laptop but to put it in perspective M1 Max takes around 45-50 seconds to generate a Stable Diffusion image, 3090 takes around 5 seconds.
Very very sad news. I hoped to switch from a PC laptop to MacBookAir someday and use a GPU and other PCIe things over Thunderbolt whenever I would need them.
Apple used to support external GPUs on Intel-based Macs but they killed that when they switched over to ARM. It seems the new Mac Pro won't support internal PCIe GPUs either. You're just stuck with whatever GPU is built into the SOC now.
No PCIe even in non-laptop, non-monoblock Macs? Sounds madness.
Anyone who needs an OS that is not a toy, that is relatively open (or rather, allows you to shoot yourself in the foot easily should you want to), that is not dependent on one "benevolent" dictator to not restrict what you can do.
For example, what useful things does Windows let you do which MacOS doesn't? The only thing I can name when comparing Windows to Linux, besides being able to run full-blown VisualStudio and Adobe, is app-level firewall, but Mac has LittleSnitch.
WSL for Unix compatible applications and not having to rely on brew, which is basically curl | sh for hipsters. Thirty years of backwards compatible apps. Thirty years of backwards compatible APIs. Doesn't ban you from their stores on a whim. Doesn't need a store even. Has a more sensible filesystem and organisation than MacOS (which is pretty damning considering how bad NTFS is). Actively, technically superior on every front then it comes to kernel or APIs, more hardened than anything Apple has ever put out.
MacOS is a toy.
Gaming. Running every application made with CUDA. Professional application that needs GPU performance more than M2 Ultra, or needs over 192GB of RAM.
Better late than never, I guess. Probably only doing this to make porting games easier since Bootcamp no longer works on the apple silicon devices.
I wonder if they made similar contributions to MoltenVK as well to bring it up to the same quality standard.
Is it limited to DX12 only or other versions are supported also?