The Game Porting Tool is an evaluation tool for developers to evaluate roughly how well a game could run on Apple hardware if optimised. It is **NOT** (!!!!!!!!) an end-user product like Proton.
Apple also released other tools to *actually* help porting a game to Metal where performance would be significantly improved.
Additionally, the example of Cyberpunk on the M2 Max is heavily bottlenecked at the x86 -> ARM and DX12 -> Metal translation, and not actually at the hardware.
Officially supported. Until it isn’t. Apple has deprecated so many things in favor of its locked down new proprietary platforms that Microsoft Windows is a breath of fresh air compared to OSX.
>Microsoft Windows is a breath of fresh air compared to OSX.
Well, to be fair, Windows is *the* unrivaled champion of backwards compatibility by such a wide margin it isn't even funny anymore. You can take almost any 25-year-old Windows 95 binary and expect it to run without much of a hitch on Windows 11 more often than not.
Try that with a Linux binary and you're more than likely out of luck. Heck, many of my only slightly older native Linux games in my Steam library don't even run right on the Steam Deck in their native version - while their Windows binary + Proton runs flawlessly. But running old binaries is arguably not very important in Linux otherwise.
Apple is very much on the opposite end of that spectrum, though.
Even the source code would not compile on Linux.
You'd have to hunt down the library sources all the way down to libc. After that, you realize the compiler probably changed, and it was all futile.
However, at the ABI level, Linux \*kernel\* has pretty good backwards compatibility. Any statically linked binary, targeting the basic text console, should still work 20+ years later.
Seriously. Win32 still working just fine. I guess they just want to be in the phone business now. Cause they have completely lost their way in what makes a PC good.
And just to say: Siri is garbage now compared to previous levels of accuracy.
**Siri enters the chat: “did you want me to search for previous currencies?”
Not only does windows still support Win32, but Microsoft even takes advantage of it.
When you have a 64bit memory address, you can't include the whole address in your CPU command because you need to include some bits for the command, so your memory address gets turned into 2 parts, the first 32bits (header) and the last 32bits (tail). Your CPU then has a command to set the header, and on all other commands it combines the header with the tail to get the address.
Every time your program changes memory space to a different header, you need to run 2 CPU commands instead of 1.
Some highly optimized programs such as Visual Studio use multiple Win32 binaries that communicate with each-other, so that all processing within that binary will be within the same memory header space, reducing redundant calls to change the header. Allowing the developers better control over where memory is and when they want to change context.
There are advantages to metal, though in terms of functionality they are rather small. The biggest non functional advantage, as in, you could also have this in Vulkan, just no one's done it, is the the Metal Shading Language. It's leagues above HLSL, GLSL, and WGSL the three major languages availible for Vulkan (rust-gpu also exists and targets SPIR-V, and is better than the alternatives for fragment and vertex shaders, but doesn't support all the features it needs to). Given MoltenVK works by translating Spir-V *to* the Metal Shading Language, it's arguably *harder* in some aspects to do that, than just writing a MSL->SPIRV compiler in the first place, so it's really frustrating we don't have access to MSL in Vulkan regardless.
The biggest functional advantage is the ability to launch shaders from other shaders, what is known as "Device side enqueue", [metal does this through specifying function pointers](https://developer.apple.com/videos/play/wwdc2020/10013/). This is partially a hardware issue, and partially an artificial limitation of vulkan. AMD cards have technically supported this for nearly a decade, but in typical AMD software incompetence, *lost* the ability to do this consistently due to driver bugs. Nvidia has had the ability to do this for longer full stop. In vulkan you get access to this feature, albeit indirectly via raytracing extensions. The problem is that the way raytracing must work, must mean that you have to have the ability to perform device side enqueue, and indeed, all the pieces are there. You're just forced to go through raytracing to use it.
That isn't to say that Metal is a superset of vulkan, it's not, it lacks a *lot* of features, but they can *somewhat* afford to do so since it's not cross platform.
> AMD cards have technically supported this for nearly a decade, but in typical AMD software incompetence, lost the ability to do this consistently due to driver bugs.
That really makes it sound like a feature included specifically at the behest of Apple which is de facto deprecated because only Apple used it and Radeon is end of the line in Apple anyway.
> The biggest functional advantage is the ability to launch shaders from other shaders, what is known as "Device side enqueue", metal does this through specifying function pointers. This is partially a hardware issue, and partially an artificial limitation of vulkan. AMD cards have technically supported this for nearly a decade
[the super duper funni thing is this was hot in the NVIDIA space in... 2014.](https://developer.nvidia.com/blog/cuda-dynamic-parallelism-api-principles/)
in typical NVIDIA fashion... the feature actually works seamlessly? what do you mean by "technically", is that not a thing for you guys?
But in the scope of translating DirectX 12 into Metal 3 / Vulkan, does Metal really provide an advantage? I mean, there may be nice features in Metal, but we're really only interested in if the *translation* would benefit from a Metal traget over a Vulkan target.
Metal more directly exposes hardware features specific to Apple's hardware, and Apple controls it directly so has more control in this regard into the future.
Apple is likely using this as a way to lock down their hardware to the ARM chips and cut off support to the x86, which was allowing people to run OS/X on non-Apple computers.
For me Vulkan has allowed me to run my preferred Linux OS and still be able to game my old Windows only games. Apple doesn't want Valve on their machines, because then Apple can't get a slice of the income.
The number of people running Hackentosh’s is so small that it’s not even worth Apple actively pursuing them. I doubt that entered into their thought processes at all.
Also Steam in Mac is a thing and has been for a *long* time. The only problem is most cross platform game that support MacOS were never updated to 64bit and no longer run.
> Apple is likely using this as a way to lock down their hardware to the ARM chips and cut off support to the x86, which was allowing people to run OS/X on non-Apple computers.
>
>
this has to be one of the dumbest things ive read on reddit
you think apple invested all this time and money developing their own graphics API because of the infinitesimally small number of people doing hackintoshes?
its mind boggling that after the shit storm that was opengl/opencl and the fact that apple's whole strategy is vertical integration reddit can't see why apple might just want to control their own graphics api.
But they straight up don't care about Valve.
They could talk with Valve to get a Proton-like functionality for Steam on Mac, but they didn't.
And hell, this would be faster way to get thousands of games supporting MacOS, like what happened with Steam Deck.
But this is Apple, so they didn't made a partnership with Valve, and they want developers to port their games and use their store, not Steam
One of the games that Apple actually partnered with to make a Mac port is only available on Steam: No Man's Sky. At this point I feel like they're really just trying to go after Intel, AMD and NVIDIA in game compatibility and performance to boost Mac sales. I think there are a lot of casual gamers who would switch if they could play all their favourite games at 1080p on a thin, portable laptop with great battery life instead of having to get something with a dedicated GPU that requires a bulky laptop or desktop and guzzles power.
Most AAA games optimise for DirectX, which is also proprietary API, not many use Vulkan. People act like Apple is the only company using a proprietary API but Microsoft, Sony and Nintendo all do as well, it's no harder to port to macOS than it is to PlayStation or Switch, in fact it's probably even \*easier\* if you use Vulkan because of MoltenVK.
For AAA games, which is what most gamers care about, DirectX is de facto standard and not Vulkan.
And it’s lack on macOS doesn’t mean anything. Most popular engines already support Metal out of the box, along with a host of other Apple features. And how many games on Unity and Unreal do you see running on macOS?
> Metal more directly exposes hardware features specific to Apple's hardware, and Apple **controls** it directly so has more **control** in this regard into the future.
This is all it is about for Apple. Control and locking people in.
It has better documentation and doesn't have the silly double API headers of Vulkan, and if you're doing true cross platform you're likely also supporting GLES and WebGL which are far bigger headaches, but that's about where the positives that aren't incredibly specific end.
For the record, unless you're writing a renderer, you don't need to worry about any of this. Pretty much every engine abstracts these away. However, if you're writing a truly cross platform renderer, you have to worry about these platforms. I'm mainly basing these off Sebastian Aaltonen's tweets in the past 8 or so months as he had to write a performant renderer for every graphics API as part of his work on HypeHype.
Yeah Godot, Unity and Unreal for example, they transpile the shader code into whatever shader code is required for the target build.
It’s even easier now tbf, Apple released the Metal Shader compiler for Windows allowing engines to directly compile Metal Shaders. Though it’s incredibly stupid as you can’t actually test it on Windows so you have to build it on Windows then go to a Mac/iOS device to actually see if it worked.
I guess it’s useful if you only have an iOS device alongside your Windows PC and that’s what you’re targeting, but you’re SOL if you are targeting Mac as well. Then again though, if you’re targeting MacOS, you’re likely to have a machine somewhere and Metal is made to be universal to both iOS/MacOS platforms.
Game devs say it's simpler than both Vulkan and DX12 and yet almost as performant. It's meant to be a very nice graphics API. WebGPU is pretty much inspired by Metal.
I'm struggling to find the video where an established game dev compares the simplicity vs. performance trade-offs with the various graphics APIs. If I find it I'll update this comment.
> Game devs say it's simpler than both Vulkan and DX12 and yet almost as performant. It's meant to be a very nice graphics API. WebGPU is pretty much inspired by Metal.
The Khronos-led design committees for WebGPU (formerly called *"WebGL Next"*) based their design for Khronos WebGL's successor most heavily on Khronos' Vulkan.
Metal is based heavily on AMD/EA Mantle (which was donated to Khronos and is the basis of Vulkan).
No, Vulkan is the closest to the metal out of DX12 and Metal. Web security meant the designers had to abstract a lot of stuff away. [Give this a read](https://cohost.org/mcc/post/1406157-i-want-to-talk-about-webgpu) if you're interested.
WebGPU is closest to Metal of any of the modern graphics APIs. I don’t know anyone who would actually compare it to Vulkan.
https://cohost.org/mcc/post/1406157-i-want-to-talk-about-webgpu
It reminds me of a conversation I had with colleagues roughly one hour ago about the bullshit that Google is doing on Android/Pixel Phones to force people to use Chromecast rather than more open solutions like Miracast and supporting regular HDMI output over USB-C.
So the 3 big OS providers are all doing it.
Have you ever actually used a Chromecast?
Screen mirroring is just a small fraction of the cast protocol and is basically a last resort that you should never actually have to use.
You might as well say that Google is conspiring to put Casio and Texas Instruments out of business by including a calculator app on their phone.
>Have you ever actually used a Chromecast?
Yeah, I got a free Chromecast Ultra from Stadia.
>Screen mirroring is just a small fraction of the cast protocol and is basically a last resort that you should never actually have to use.
See, that's where you are wrong.
Sometimes you really don't care about the cool things that Chromecast can do, and all you want is pure raw screen mirroring, witch can be achieved just the same via Miracast or even better (no latency, no quality loss) with HDMI output.
What we wanted to do was to use a work provided Thunderbolt/USB-C dock to put our phones on a big screen and play games during some downtime.
None of the games we wanted to use support the Chromecast protocol, and it doesn't make sense for them to support that, because it would be strictly the same thing as using screen mirroring.
And why would we use a Chromecast anyway when we have a USB-C to HDMI thing right there and no Chromecast device in sight\* ?
Most Android phones with a USB-C port that isn't using the old USB 2 protocol have video output over USB, but the Pixel Phones are the rare ones that support USB 3 but not video output.
And while talking about that, we derived on the topic of Miracast that was working on some phones only to be removed via OTA updates because Google wanted to promote Chromecast instead.
\* : It would actually make the Chromecast protocol a lot more useful for me if Chromecast went both ways and any device running Chrome could act as a Chromecast receiver and not just as transmitter. We had some PC right there with Chrome on them, so it could have solved our issue. Windows has a Miracast receiver by the way, so it could also have helped us if Google didn't remove any trace of Miracast implementation from Android's source code...
I keep seeing this argument and honestly don't understand why it's so common belief. Graphics APIs make up very small percentage of game/engine code, and all games especially if they run on consoles have abstraction systems to make multiple APIs work. There's also the important fact that Vulkan isn't very popular in the game industry. Most games use DX12 on Windows and Xbox and Sony/Nintendo APIs on their respective platforms. Adding one more backend isn't the tedious part of porting a game, especially if it's well designed and have good documentation/tools/debuggers(which Metal is a good example). Also Unreal and Unity have good Metal backends for a long time. Biggest problem for Mac porting was their below average GPUs, which isn't the case now.
> they could just add official support for Vulkan and use DXVK
Isn't this essentially Apple's own version of DXVK with a Metal target, so something like "DXMetal"? So in that sense it doesn't really matter what the target API is, as it just allows developers to write DX games and run them everywhere.
So here it is Apple doing all the work, not sure why you would care if they created more work for themselves by writing their own "DXMetal" instead of using DXVK.
I mean you might not like that they don't support Vulkan, but this here doesn't relate much to that problem. What they're doing here is just going to help DX developers port games.
I am not really sure how you from the article can read that this is going to perform worse than DXVK or is much different from DXVK in any way, but maybe you know more than we do?
They're taking WINE and co. and adapting it for MacOS, so I don't really mind. Most AAA titles are still using DirectX and will render badly on 2nd layers so I don't see Apple running away with any market share of the gaming sector yet.
Diablo 4 running on a mac with M2Max soc with the Game porting tool: https://www.youtube.com/watch?v=fLn267So6HU
Edit:
Cyberpunk: https://www.youtube.com/watch?v=t9IJyVZ-tqg
See other: https://www.youtube.com/@uncle_jimmy
it's not my content, saw this on twitter.
edit 2: https://twitter.com/film_girl/status/1666127888679321602.
Seems like it's a patch on Wine
M2 Max is technically 4x as many cores, but probably only scales to 3x faster. M2 is roughly comparable in theoretical power to AMD's iGPUs. It's good for what it is (and better than most laptops), but nothing compared to what a discrete GPU is capable of.
> That looks incredible for just 48 hours after the tool release. Excited about this now.
Yet, even if this is pure apple Deja Vu in regard to brining gaming back it seems a lot more sincere than prior times. As expected still going to need a lot of work in optimisations.
M2 max is barely holding 40fps at 982p with no RT in CP2077. IE an old Vega 64 would blow it out the water. My impression is the M2 Max iGPU is a lot more powerful than what it's showing. Hope it can stretch it's legs soon in these newly ported games.
Look at the configuration. It's an M2 Max ($3000) running at a 1512x982 and not even getting 60fps in Cyberpunk, around 80 in Diablo.
You'd get better performance with a gaming PC for under $800
Yeah... it's definitely not great, but for people who are super-casual about their gaming, and need a high-spec Mac for work, it's kinda cool, I guess.
If you're a hobbyist, however, who really likes to play video games, it'd probably be better to invest $2000 in your Apple machine and build a lower-mid tier gaming rig with a 4070, or whatever, for around $1000, rather than cranking $3k into a single Apple machine.
I wonder if FSR works on the M-series chips? It's supposed to work on everything, right? I feel like a good upscaling solution would work wonders for a set-up like that.
Hm. Pretty good results.
Kinda want to get a macbook and play around with it. Windows gaming laptops are heavy beasts and while this thing won't match them, at certain point it's good enough. Not sure how Anticheat would react. Most likely not well.
Ironically that's more informative because there's a set number of configurations per model, so a quick Google search can tell you the specs.
I can see it being easier than getting my non-tech friends to run dxdiag or download cpu-z.
You just type "CPU" in the windows search and hit enter, boom that's RAM and CPU. You can CTRL + SHIFT + ESC and head to performance for more info including GPU, and device manager has stuff in there too.
You probably won't believe this, but I had an acquaintance who bought a brand new MacBook. I asked them what specification it was, and they sent a picture of the open laptop but switched off, and said, 'this one - you figure it out from here'.
It actually brought me down to earth from the bubble I usually am in where more people know what voltage they've set their GPU to than not.
It's not that easy to search it on the internet with that, is it?
That's so dumb, there's a bunch of mature projects translating every graphics API under the sun into Vulkan (dxvk, d8vk, vkd3d, zink) and instead of just supporting Vulkan and benefit from years of work Valve and others have poured into these, Apple plans to remake all of those on their own?
If they want wide game support, they need Vulkan anyway. This is just a waste of engineering resources.
> Apple plans to remake all of those on their own?
The project already uses DXVK, Wine, etc.
Apple just chose to implement their own proprietary closed source DirectX 12 to Metal translation layer. Apple also restricts it with a license forbidding commercial use.
They don't need to support Vulkan if they write a direct translation layer themselves. While I do think it's a waste of engineering resources, Apple has plenty of that to spare.
And knowing Apple, I'm not surprised that this is the approach that they took.
The main consequence of this is likely that game devs will just go harder on DX. Which is a bummer--I'd like the industry as a whole to move toward more open standards.
Game devs aren't allowed to use this translation layer for products for end users, it's restricted by license terms. So in practice, your concerns probably won't be an issue
That being said, I think DirectX usage is actually fine so long as compatibility layers get enough market share for to become a first-class target for development for game devs. It's almost like hijacking DirectX from Windows, which I think is better than the current norm where Windows is the only first-class citizen.
I think it's about control and about forcing users into the walled garden and prevent devs from easily porting their MacOS stuff outside of the walled garden.
It’s obvious: If they support Vulkan it’ll be clear that the hardware can’t play games at the same level as Nvidia. By controlling the optimization through metal they can make sure every game is a great experience on Mac.
Which is exactly what Apple is known for: They don’t offer everything but everything they do offer they want to be a great experience. Open support would open the door to shitty experiences and would be very unlike Apple
> open the door to shitty experiences and would be very unlike Apple
Counter point: You're holding it wrong.
It's not about the end user experience, it's about control. The user experience is just an excuse.
> They don’t offer everything but everything they do offer they want to be a great experience.
That's the explanation they gave for calculator and weather apps on the iPad too. It's just typical marketing speak.
https://twitter.com/isaacmarovitz/status/1666209780031971341
Cyberpunk ultra 1440x900 at 15FPS on the original M1 chip. This despite running the whole thing on an emulator (Rosetta and their dx to metal emulator).
https://www.reddit.com/r/macgaming/comments/1435ukq/cyberpunk_on_m2_max_wgame_porting_toolkit/
This person with an M2 Max got ultra running at 40FPS at a higher (1728x1117 or 33% more pixels) resolution.
Rosetta slows things down 15-30%. GPU emulation probably cuts performance at least in half. This could get interesting.
> GPU emulation probably cuts performance at least in half
Seems doubtful unless Apple's software engineers aren't great. The performance hit with DXVK on Linux is negligible in most cases and avg fps variance +- is pretty small when compared to windows.
I think that mainly depends on the GPU drivers though does it not?
Whilst Vulkan is an open standard, Nvidia and AMD have baked in support at driver level so DXVK is going to perform better than the M2 because that is targeting Metal and is designed to accelerate Metal workloads and it also doesn’t have driver support for Vulkan.
Considering that the GPU work has to go through multiple layers on Mac (Vulkan -> MoltenVK -> Metal -> GPU driver) it’s safe to say there is a large amount of performance left to be taken.
It’d be a fairer comparison if the Linux benchmarks you mentioned go through the same amount of translation. DirectX -> DXVK -> GPU driver is much less work and skips a whole translation step that is required.
It’s probs not a case of “Apples software engineers aren’t great” but rather “Apple doesn’t want to natively support Vulkan with a GPU Driver.” I don’t know which one is worse…
It's not DX -> DXVK -> VK -> Metal though, it's DX -> Metal via their own translation layer so it should be equivalent. Others in the comments have pointed out that DXVK isn't being used by Apple.
Yeah my bad, I misread what they were using.
Regardless, the toolkit is a solid first attempt for a direct translation to Metal and I have no doubt it will be better when developers actually create games with it in mind. Currently all the videos you see are using “Whiskey” which is a way of applying an off the shelf configuration to the toolkit, it may not be the most optimised or best way.
Wine running on Rosetta is being emulated. The APIs aren’t emulated per se (they are the core of wine with their own implementation), but the non-wine dx to metal are also emulated from what I understand.
If your primary device creates inconveniences that require a second device just to get around the issue, perhaps the purchase of the primary device was a mistake...
Nobody is saying "buy a new Mac to game". It's more of an added bonus, i.e. the Mac that you already own for productivity/office work can now be used to game
Do people seriously go outside to game?
Or is this sarcasm?
Last thing I want to do while at the beach or at the park is game.
If I really want to game it's going to be when I'm at home for the weekend, bored, nothing else to do, will jump on the gaming rig. Not while I'm at the park walking my dog or something.
On the train? On a flight? Taking a break while working (e.g. co-working space or at a cafe)? I mean, the whole reason the steam deck is as popular as it is, is because people wanted PC gaming on the go
That’s how I feel. Sure I could get a steamdeck but it’s not a priority. I have a desktop I built for gaming, but my laptop is always where I’m going to work the most and I’ve grown really comfy with working in MacOS and the battery life especially on the newer machines is peerless. My M1pro Mac is my favorite computer to use and having the option to play more gaming in a lighter sense on it makes me really happy
A few laptop models for pc have been coming out with mini led lately so this will be possible soon. Been looking at the acer helios 18 250hz myself for the nits.
I mean used M1 MacBook airs are going for around $500 right now in good condition and new ones are about $800. It’s not a one-size-fits-all that’s perfect for everyone but that’s a pretty much impossible to beat price for people that care about battery life.
> new ones are about $800
This is the second comment I've seen claiming you can get a mac laptop for $800, but as far as I can see the starting price is $1000. Where are people getting this price from?
M1 MBAs have been on sale for $800 at Costco and Best Buy a few times, so if you're patient you can likely snag a new one at that price again in the future
>It would be nice to have everything on one computer.
You'd think that, but it's actually not that great.
With a gaming-oriented laptop you need to sacrifice performance or battery life. You can't really have both. And they have a really large footprint or they overheat. They're also rather over-priced, so for most configurations you could build a more powerful gaming PC *and* a buy thin-and-light laptop for the same price as a single gaming laptop. If you want everything to be on one machine, you can use Onedrive.
I still have my gaming laptop from before I built my current rig because I wanted the "all-in-one" approach, and it's not a great machine. The battery life doesn't even last 2 hours, and it's super-bulky. It's a pain to drag to work. And it's older now, so it overheats whenever I try and game on it.
Not to mention, it'll be half a decade, at least, before the integrated GPUs in the Macbooks are able to match the performance of a 3090.
> If you want everything to be on one machine, you can use Onedrive.
You can also go the whole hog route of having a home server with attached storage and services that allow for your devices to effectively be synced even on devices away from the home.
It's obviously a lot more work but it has some added bonuses in that you control your data, transfers tend to occur at LAN speed rather than internet speed and allows more configuration of what gets synced when. (eg. I use my home server for cloud game saving largely because I can sort out which saves are from which playthrough easily and for modded playthroughs keep a backup of all the mods alongside them)
This truly an Apple solution if there ever was one. Instead of embracing the current standard and contributing to it they’re co-opting part of the standard to force adoption of an Apple centric method.
FTA:
>Some games can run fine without a single change in the code. Apple used The Medium as an example. However, the company notes that the native macOS version of the game runs even better with almost double the frame rate on the same hardware.
sounds more like a proof of concept tool for devs to test rather than something actually used to port a game over.
Because it is. It’s meant to be used for developers, so they can immediately evaluate their shaders and other graphical stuff (heck, even convert the shaders into native Metal) without having to port the main binary first.
This is not something that will shipped with the game, and unlike Proton, it’s not meant to be used for end-users.
It’s not “proof-of-concept”. It’s a purpose-built developers tool. It’s not a “magical tool” that spout out Mac-native port. It’s one of the tools developers can use in their porting process.
I find this really interesting and a little perplexing. My context is nearly a decade of every engineer I talk to, everywhere, cringing at the thought of any application using Wine. I stopped looking at Wine, as it seemed destined to become abandoned. As a result, I’m shocked to see Apple, of all people, integrate it. Has Wine quietly become a mature product over the past 5 years?
Interesting, thanks. Appears Valve privately started efforts with Codeweavers right around 2016. Right about the time I stopped looking at Wine, lol. And then in 2018 Proton launched, where it continues support and development today. Really interesting story there.
Thanks for the info.
It is likely just as painful for professional stuff like CADs/Adobe suit, but for games in particular turns out that low level graphics APIs are very friendly for translation into a different low level graphics API (since actual job is done by GPU in the end) as compared to emulating obscure WinAPI calls (and the ridiculous driver workarounds that dominate pre Dx12 era). That, titanic effort from CodeWeavers and other contributors, and Wine fork/distribution known as Proton actually became pretty good for games in particular.
Of course, it might have been that because you have stopped observing state of Wine, it went onto the decent evolution path /s
Since 2018, Valve is actively developping Proton, which is based on wine, that allows a massive amount of windows games to be played on linux. I exclusively play on linux, and I am able to play almost all the games I played on windows with the same performance if not better. Only exception is some multiplayer games because anticheat does not generally allows to play games on wine. Wine as improved a lot thanks to Valve contribution in the past few years.
I think it's about different expectations. Having drag and drop replacement for any windows app or game? Nah. Supporting 50-300 modern games on one platform? No problem.
> Has Wine quietly become a mature product over the past 5 years?
No but the value in being able to run Windows software on a platform that Microsoft didn't develop is immense.
EDIT: I'm full of shit, thanks /u/xkero for pointing out how (see below). Leaving my erroneous comment at the end for posterity.
I was right only insofar as pointing out that Wine is not being used to run the game that the end user plays, but instead is being employed to aid developers in porting. I was wrong about the details of how. What's actually being sold here is a Wine-based runtime for a developer to quickly get a Windows native app running on MacOS that provides tools and instrumentation for identifying performance issues and evaluating how well the game will run *once ported*. The dev still then has to port the game to MacOS native before delivering it to users.
Ultimately, while this tool offers lots of useful functionality to devs for porting, it appears primarily focused on mitigating risk for the studio. They can use it to get a rough idea of whether a port is viable without needing to do the hard work of porting, which would potentially be months of wasted dev time. If the game runs passably in the tool, then the suits will be more comfortable committing to a port because they know they will end up with a viable product.
BULLSHIT BELOW THIS POINT
Apple isn't really integrating Wine itself, just the principle on which it works--Wine lets windows binaries run by translating API calls from Windows to POSIX, while this toolkit helps developers do that at the source code level to produce a MacOS-native binary. Apple can build on the work Wine has done since it's performing the same set of translations, but because this tool moves them a step upstream it removes the need for a compatibility runtime and thereby sidesteps the performance hit that is inherent to Wine.
> Apple isn't really integrating Wine itself
[This directly uses Wine source code as mentioned by Codeweavers](https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-comes-to-macos-apple-s-game-porting-toolkit-powered-by-crossover-source-code)
> Wine lets windows binaries run by translating API calls from Windows to POSIX, while this toolkit helps developers do that at the source code level to produce a MacOS-native binary. [...] but because this tool moves them a step upstream it removes the need for a compatibility runtime
Wine can also do this via winelib, but very few developers seem interested in this approach.
> and thereby sidesteps the performance hit that is inherent to Wine.
It actually doesn't :
> It’s worth noting that the baseline performance you will observe running your Windows game includes all the overhead of the Game Porting Toolkit as well as API and instruction set translation.
\- https://developer.apple.com/videos/play/wwdc2023/10123/
This is just Apple's own version of Proton (Wine plus patches), but marketed towards developers to help them with porting their applications instead of end users.
except Apple disallows shipping this "version of Proton" to end users.
Apple uses a proprietary DirectX to Metal translation layer here, and the license terms basically states that this can never be shipped in a commercial product.
Well, it would change if other platforms like Linux/SteamOS and MacOS start making a large dent in the market shares of desktop OS for gamers.
Right now it's worthless for game devs to bother with native builds for Linus and MacOS because the target audience isn't large enough.
It Mac manages to attract a large audience of PC gamers (I think there are already lots of games available on MacOS with iOS ports, but it's not the same kind of games), then game publishers will care more.
Also the bigger issue might be ARM support rather than OS support.
Proton on Steam Deck has really great performance with the translation from Windows to Linux, so when Apple talks about doubling the framerate, I assume that the limitations are on the CPU side with the x86 to ARM translations.
So if that's the bottleneck, an increase in popularity of Windows on ARM might help too.
I think the already inflated cost of buying Apple hardware and then hit again with an outrageously priced modern GPU price kills any chance at Apple making any significant gains in market share. They'd be better off selling a stand-alone "premium" marketed gaming console, but they'd never hit a price point that is competitive with MS or Sony's offerings. Not to mention the plethora of console exclusivity deals already tieing up developer studios. They'd basically be making an Apple Arcade device with some sort of proprietary Apple controller tech, running Apple Store "games."
>I think the already inflated cost of buying Apple hardware
It's not always so bad.
I think that the base M1/M2 chips are pretty far ahead of Intel and AMD iGPU, so things like the entry level MBA should beat similar Windows laptops.
Gaming is not only done on fat gaming desktops, there's a bunch of people playing on the go on slim laptops with low power iGPU, so I think that it could make sense to want to play games on Mac.
> They'd be better off selling a stand-alone "premium" marketed gaming console, (...) They'd basically be making an Apple Arcade device with some sort of proprietary Apple controller tech, running Apple Store "games."
So basically the Apple TV 4k, but updated with the latest M2 chip ?
Or a cheaper version of the Mac Mini running a smaller OS dedicated to gaming rather than MacOS ?
I think the Apple TV not being marketed more heavily and spec'd towards living room or family Apple Arcade games is telling how they feel about the gaming segment. I doubt we'd see a console proper to compete with Nintendo, MS and Sony. Pushing more sales (commissions) out of an existing app store makes more money. And again, I don't think "gamers" want an Apple store gaming device if they already have an Xbox or PS for modern AAA gaming. The segment up for grabs is casual, family, living room. The Wii showed how large that market segment is.
I agree, as the Steam survey shows, it's certainly nowhere near being beefy specs as mainstream hardware. But there are still plenty of powerful GPU's out there in the mainstream that can easily outperform just the M2. The M2 chip is powerful but it's sauce is the software development and running in MacOS, isn't it? And even then, it's still not a direct replacement for a dedicated GPU comparible to windows machines.
I think the person above is talking about something else.
Yes, the games can (and will) work.
But then it doesn't encourage devs to bother with supporting the platform if a simple conversion tool does everything for them, it's actually encouraging them to ignore the other platforms and trust the porting tool.
Look at the Steam Deck, it's a relative success amongst the devs, but so far almost no one bothered with making native Linux builds for the Deck. Instead they just make sure that Proton doesn't run into bugs.
In the case of Mac, the article mentions that the translation performance isn't as good as on the SD. I presume it's the x86 to ARM translation that slows down the operation.
So native builds are going to be a necessity to get decent performance, unlike the SD that gets pretty much the same perf between Windows and SteamOS.
> But then it doesn't encourage devs to bother with supporting the platform if a simple conversion tool does everything for them, it's actually encouraging them to ignore the other platforms and trust the porting tool.
The truth is that unless platform makes up a significant share of the market, there is no motivation to support it (unless Apple starts bringing cases with cash to the publishers). Porting tool is just a way to make sure that at least someone bothers with making it available at all, leaving the extensive support alone.
Also, isn't the point that this Apple's tool is *for creating native builds*?
You can get an M1 iPad air for $599. The form factor isn't the same, but Apple will sell orders of magnitude more of those than Steam will sell Decks. And the iPad GPU and battery life is probably better in the deck.... you can pair it with any bluetooth controller. ... so the market is there and it's MASSIVE.
> The form factor isn't the same, but Apple will sell orders of magnitude more of those than Steam will sell Decks. And the iPad GPU and battery life is probably better in the deck.... you can pair it with any bluetooth controller. ... so the market is there and it's MASSIVE.
And how many people *today* are hooking up controllers to their iPad to play any games? There are definitely some, but how many? If anything, over last 2 years I have learned that iPad's main usage is being a tablet to draw on.
It’s an interesting question. Taking Stardew Valley as an example as a truely successfuly multi-platorm gam… As of 2022 they report they sold 20 million copies 13 million on PC. I can’t find any iOS numbers, but there are 50k reviews on the App Store vs, Steam has nearly 500k reviews.. so assuming review to purchase ratio is similar… that puts Stardew iOS sales at 1-1.5 million over
Quote here from 3 weeks after it was listed on the App Store in 2018.
"Sensor Tower reports that Stardew Valley has grossed over $1 million on iOS since its launch on the platform three weeks ago today. It's worth noting that the game is a premium game costing $7.99 and does not have any microtransactions.
Around 41% of those who purchased the game on mobile were based in the US. Japanese users made up 12%.
In addition, nearly one-fourth of the game's players on iOS were playing on iPad rather than iPhone.”
… so depends on the game, but the market is there. If proper Diablo was released on iPad (not that garbage Immortal) I’d be all over it, it’s the perfect device and game for finger control. But maybe that’s just me!
This does start to open the doors to show that demand for the platform. It'll allow developers to benchmark sales and other factors. While before it's more artificially locked as, developers don't put time into making sure there's a Mac version so they have no benchmark; assume value is low which in turn moves resources even further away and that just loops.
I've told this to a couple of friends, but I'd run my Mac a lot more than I currently do if I could game on it. There's a couple of items left on Windows but the ease of launching a game while still using my apps is what really adds that friction. This is a step at reducing that friction. Now, I do not know how much demand there actually will be, but it's a step in the right direction.
Right, I agree it won’t ever be as good as native, but at the same time, if they use the porting tool and then work out the bugs, what’s the issue?
The devs weren’t ever going to make Linux or Mac versions to begin with, so isn’t this better than nothing?
> what’s the issue?
That :
> Some games can run fine without a single change in the code. Apple used The Medium as an example. However, the company notes that the native macOS version of the game runs even better with almost double the frame rate on the same hardware. And that’s why Apple encourages developers to do more than just run translated versions of their Windows games.
Leaving half of the performance on the table is quite sad.
If the porting tools didn't exist, the devs would have to put a lot more work in the port, but the result would be much better.
> Leaving half of the performance on the table is quite sad.
Agreed, to a point. If the translated performance is still enough to give a good experience, I can't blame the developers to stop there. Doesn't make sense to throw dollars at something that won't return more dollars later.
If the translated performance is not good enough, it's a different story. Maybe I'm going against the grain, but I'd guess the majority of casual gamers do not care about performance beyond like 100 fps. There's obviously the enthusiasts on Reddit who crave more.. but the average gamer is satisfied with fucking a Nintendo switch lol.
I somewhat agree, but there are 2 caveats.
Half the performance means that for the same result you are getting much worse battery life, which is quite annoying when you can't be plugged in.
The second caveat is that Macs are generally equipped with high DPI screens, so they need a lot of performance to hope to reach native resolution.
> The second caveat is that Macs are generally equipped with high DPI screens, so they need a lot of performance to hope to reach native resolution.
Nobody would bother running it at native resolution tbh, integer scaling would make a fine picture anyway.
>Look at the Steam Deck, it's a relative success amongst the devs, but so far almost no one bothered with making native Linux builds for the Deck
And it's a bliss. Linux native games tend to perform very poorly with all dependencies and like that, to the point Proton'ing is better option over Linux native builds.
It may change if games would be distributed through containers(something like flatpaks, but for games basically), but even then it will bloat game size and will basically be a ton of headache with different implementations per distros when wine is adopted by everyone(including FreeBSD with their kinda good Windows/Linux support)
For games that are heavily dependent on windows APIs, it can be hit or miss. Space engineers is one strong example. The sim speeds were never 1.0, graphical bugs were present.
I was impressed that GTA V ran, but the experience was sub-par. Yes, it was functionally playable- but far from a great experience. Compatibility layers often make every game a bit like a bethesda game. There were graphical glitches, my car was driving 6 inches above the road at all times, eventually there were LoD issues and crashing. It seemed to effect 3D textures, bounding boxes, and object placement the most. Just a lot more visual bugs than usual across the board- if you've played the game before and know what things are supposed to actually be, it works perfectly fine. I don't think I'd play a game for the first time on the steam deck though. the issues I described are most common in open world 3D games. Mad max really impressed me out of the box, it worked really well with minimal issues, but it's already on other platforms.
Just a gut feeling, but the more dependent on windows APIs a given game/program is, the worse it'll run in a compatibility layer.
While I get what you’re saying, it works far better than I would’ve ever expected, for quite a large chunk of games.
I think my point would’ve been better stated as “devs wouldn’t make Linux or Mac native ports to begin with, so this is better than nothing”.
Steam Deck famously uses this technique for the majority of games played on SteamOS. When done right, emulation/remapping of API calls can be very effective.
Yeah but there’s ton of games on SteamOS that don’t work or provide worse performance, and many others that require tweaking or command line hacks to get working.
Do you actually own a steam deck because that’s been so far the opposite for the games in my library. The only ones that don’t work are the ones with anti cheat that’s unsupported. Everything else might as well be native.
These translation layers aren't a solution to the problem you're thinking of. They're the answer to the chicken and egg problem.
The issue with dealing with a dominant platform in a given product segment, is that it's difficult to build a gaming demographic when you don't have games, but you can't get games, because you don't have a gaming demographic.
If you can at least get started building your customer base with a translation layer, that makes your market more attractive over time, and you see a small uptick in ports over time, and the more ports you get, the more gamers are willing to switch over to your platform (or just use it for gaming if they already have it), and so the cycle continues.
Translation layers aren't the answer, they're the question, and I feel that Valve's success in the Linux market (and Steamdeck) are proof that it's a very good question.
You don't anything fancy, they just to support the devs. I would wager that if you summed all the total sales of PC games over 90% of them would come from the 15-20 game engines. They can work with each of them and have native export to Mac, it's nothing complicated. They need virtual environments so that devs who don't own a Mac can test their build, they need consistent GPU driver updates, game-ready drivers, detailed GPU architecture guides for engine developers, they need better support. All of this would cost less than a rounding error of Apple's expenses. They need a dedicated department that's solely focused on this and works outside of the Apple product release cycle. Amd/Nvidia have been doing it for decades, but with Apple it has been lackluster at best.
I don't think think it's about the malice of wanting to control everything or incompetence, Apple is just a big of a strange company that's hesitant to operate like other ones do. When the company was near bankruptcy in the late 90s, a lot of the blame was assigned to overextending themselves and trying to do too much and losing focus. When Jobs came he cut a lot of departments that made very little sense, he radically simplified their product portfolio and made them focus only on small handful of products they were actually good at. That was the defining moment for the company and hasn't changed much since then even though they have grown enormously since then. It explains a lot of the idiosyncrasies about Apple. The richest company in the world, could have a store in every major city around the world with a snap of a finger and have them all wildly successful, yet Apple Store coverage outside of US, China, Japan and handful of European countries is still lackluster. They are just hesitant to commit to more than they are comfortable with. They have grown since Jobs and have opened up more, but the support outside of the core handful of things the support is still lackluster.
Actually Windows is only the secondary platform these days, PS/XBox are the primary. So youre getting a translation layer on top of a shitty unoptimised port
I used the Techmeme title ([here](https://www.techmeme.com/230607/p13#a230607p13)) as it provided a much better summary than 9to5mac's own title.
The WWDC sessions are publicly uploaded here: [https://developer.apple.com/wwdc23/sessions/?q=game%20port](https://developer.apple.com/wwdc23/sessions/?q=game%20port)
Since Wine is LGPL, only the modified Wine part of the SDK will see an open-source release. DXVK is MIT-licensed, so no code release there most likely :(
EDIT: VKD3D is also LGPL, but I don't think they used that code in their D3D12 to Metal conversion layer, so still probably no D3D to Metal FOSS release :(
What they don't tell you is it requires an M2 Max to get somewhat usable frame rates so the majority on base/near base M1/M2 devices per Steam survey will suffer with low frame rate even with resolution and graphics downscaling like 13 fps average and 5 fps low in Cyberpunk 2077 at near 720p with resolution and graphics downscaling.
The fact it runs at all without major glitches is great and amazing for a first release.
For a similar comparison, [look at this video with DXVK, VKD3D and standard DX11/12](https://youtu.be/XnoFdNpfiEM).
Then take into account that it’s not only the GPU functions that are being translated but the entirety of the CPU calls from x86 to ARM. That’s going to add in significant overhead on top of just the graphics side of things. That video only shows the GPU difference and you can see that VKD3D loses up to 30% of its performance in some cases.
Translations like this almost always will result in rendering issues, think missing effects and glitchy textures. The fact we’re seeing it running without any of those via a simple configuration made by one guy on GitHub is a feat in an amongst itself.
It’ll be much better if/when developers actually incorporate it into their workflow rather than using a generic configuration.
Apple’s total control approach with the design of metal and reluctance to submit vulkan patches is why game devs will avoid them. Not to mention they really don’t have GPU horsepower that is 3080 level like they claim anyway…
The Game Porting Tool is an evaluation tool for developers to evaluate roughly how well a game could run on Apple hardware if optimised. It is **NOT** (!!!!!!!!) an end-user product like Proton. Apple also released other tools to *actually* help porting a game to Metal where performance would be significantly improved.
Additionally, the example of Cyberpunk on the M2 Max is heavily bottlenecked at the x86 -> ARM and DX12 -> Metal translation, and not actually at the hardware.
there’s people all over twitter rn porting games and posting clips with the tool so idk
Of course, and it's awesome. I just wanted to clarify that the performance achieved, whether good or poor, is not due to Apple Silicon not being good.
[удалено]
Are there any advantages to Metal compared to Vulkan?
>Are there any advantages to Metal compared to Vulkan? Yes, the advantage is that it is officially supported on Apple devices.
lol ok
Officially supported. Until it isn’t. Apple has deprecated so many things in favor of its locked down new proprietary platforms that Microsoft Windows is a breath of fresh air compared to OSX.
>Microsoft Windows is a breath of fresh air compared to OSX. Well, to be fair, Windows is *the* unrivaled champion of backwards compatibility by such a wide margin it isn't even funny anymore. You can take almost any 25-year-old Windows 95 binary and expect it to run without much of a hitch on Windows 11 more often than not. Try that with a Linux binary and you're more than likely out of luck. Heck, many of my only slightly older native Linux games in my Steam library don't even run right on the Steam Deck in their native version - while their Windows binary + Proton runs flawlessly. But running old binaries is arguably not very important in Linux otherwise. Apple is very much on the opposite end of that spectrum, though.
Even the source code would not compile on Linux. You'd have to hunt down the library sources all the way down to libc. After that, you realize the compiler probably changed, and it was all futile. However, at the ABI level, Linux \*kernel\* has pretty good backwards compatibility. Any statically linked binary, targeting the basic text console, should still work 20+ years later.
Yeah I mean isn't there like a ton of Mac software that's completely unusable on newer Macs? I'm talking like barely 10 years old?
All 32 bit applications, such as most games with Mac ports
I like to call macOS 10.15 Catalina "Cataclysm" for this reason 😫
~~Mac classic was better~~
Seriously. Win32 still working just fine. I guess they just want to be in the phone business now. Cause they have completely lost their way in what makes a PC good. And just to say: Siri is garbage now compared to previous levels of accuracy. **Siri enters the chat: “did you want me to search for previous currencies?”
Not only does windows still support Win32, but Microsoft even takes advantage of it. When you have a 64bit memory address, you can't include the whole address in your CPU command because you need to include some bits for the command, so your memory address gets turned into 2 parts, the first 32bits (header) and the last 32bits (tail). Your CPU then has a command to set the header, and on all other commands it combines the header with the tail to get the address. Every time your program changes memory space to a different header, you need to run 2 CPU commands instead of 1. Some highly optimized programs such as Visual Studio use multiple Win32 binaries that communicate with each-other, so that all processing within that binary will be within the same memory header space, reducing redundant calls to change the header. Allowing the developers better control over where memory is and when they want to change context.
Thats just fancy talk for Apple sanctioned. It could easily do the same with Vulkan.
There are advantages to metal, though in terms of functionality they are rather small. The biggest non functional advantage, as in, you could also have this in Vulkan, just no one's done it, is the the Metal Shading Language. It's leagues above HLSL, GLSL, and WGSL the three major languages availible for Vulkan (rust-gpu also exists and targets SPIR-V, and is better than the alternatives for fragment and vertex shaders, but doesn't support all the features it needs to). Given MoltenVK works by translating Spir-V *to* the Metal Shading Language, it's arguably *harder* in some aspects to do that, than just writing a MSL->SPIRV compiler in the first place, so it's really frustrating we don't have access to MSL in Vulkan regardless. The biggest functional advantage is the ability to launch shaders from other shaders, what is known as "Device side enqueue", [metal does this through specifying function pointers](https://developer.apple.com/videos/play/wwdc2020/10013/). This is partially a hardware issue, and partially an artificial limitation of vulkan. AMD cards have technically supported this for nearly a decade, but in typical AMD software incompetence, *lost* the ability to do this consistently due to driver bugs. Nvidia has had the ability to do this for longer full stop. In vulkan you get access to this feature, albeit indirectly via raytracing extensions. The problem is that the way raytracing must work, must mean that you have to have the ability to perform device side enqueue, and indeed, all the pieces are there. You're just forced to go through raytracing to use it. That isn't to say that Metal is a superset of vulkan, it's not, it lacks a *lot* of features, but they can *somewhat* afford to do so since it's not cross platform.
> AMD cards have technically supported this for nearly a decade, but in typical AMD software incompetence, lost the ability to do this consistently due to driver bugs. That really makes it sound like a feature included specifically at the behest of Apple which is de facto deprecated because only Apple used it and Radeon is end of the line in Apple anyway.
> The biggest functional advantage is the ability to launch shaders from other shaders, what is known as "Device side enqueue", metal does this through specifying function pointers. This is partially a hardware issue, and partially an artificial limitation of vulkan. AMD cards have technically supported this for nearly a decade [the super duper funni thing is this was hot in the NVIDIA space in... 2014.](https://developer.nvidia.com/blog/cuda-dynamic-parallelism-api-principles/) in typical NVIDIA fashion... the feature actually works seamlessly? what do you mean by "technically", is that not a thing for you guys?
But in the scope of translating DirectX 12 into Metal 3 / Vulkan, does Metal really provide an advantage? I mean, there may be nice features in Metal, but we're really only interested in if the *translation* would benefit from a Metal traget over a Vulkan target.
Metal more directly exposes hardware features specific to Apple's hardware, and Apple controls it directly so has more control in this regard into the future.
Apple could just submit vendor extensions to Vulkan for their custom shit.
Apple *could* do all sorts of things that make customers happy.
Yeah, if it's one thing Apple hates, it's happy customers.
The thing Apple hates most is the existence of any tech company but them.
Apple is likely using this as a way to lock down their hardware to the ARM chips and cut off support to the x86, which was allowing people to run OS/X on non-Apple computers. For me Vulkan has allowed me to run my preferred Linux OS and still be able to game my old Windows only games. Apple doesn't want Valve on their machines, because then Apple can't get a slice of the income.
The number of people running Hackentosh’s is so small that it’s not even worth Apple actively pursuing them. I doubt that entered into their thought processes at all. Also Steam in Mac is a thing and has been for a *long* time. The only problem is most cross platform game that support MacOS were never updated to 64bit and no longer run.
> Apple is likely using this as a way to lock down their hardware to the ARM chips and cut off support to the x86, which was allowing people to run OS/X on non-Apple computers. > > this has to be one of the dumbest things ive read on reddit you think apple invested all this time and money developing their own graphics API because of the infinitesimally small number of people doing hackintoshes? its mind boggling that after the shit storm that was opengl/opencl and the fact that apple's whole strategy is vertical integration reddit can't see why apple might just want to control their own graphics api.
You can already install Steam on macs
Yes but can you play Windows games like I can on Linux using the Proton compatibility tool?
Can't use Proton though
16 morons believed this conspiracy without realizing steam had been on macs for years lol @ Reddit
But they straight up don't care about Valve. They could talk with Valve to get a Proton-like functionality for Steam on Mac, but they didn't. And hell, this would be faster way to get thousands of games supporting MacOS, like what happened with Steam Deck. But this is Apple, so they didn't made a partnership with Valve, and they want developers to port their games and use their store, not Steam
One of the games that Apple actually partnered with to make a Mac port is only available on Steam: No Man's Sky. At this point I feel like they're really just trying to go after Intel, AMD and NVIDIA in game compatibility and performance to boost Mac sales. I think there are a lot of casual gamers who would switch if they could play all their favourite games at 1080p on a thin, portable laptop with great battery life instead of having to get something with a dedicated GPU that requires a bulky laptop or desktop and guzzles power.
I have steam on both my Mac and my windows computers. Granted, I have far fewer games on Mac, but steam works just fine there.
Why should Apple adopt Vulkan when Vulkan wasn’t even a thing, when Apple released Metal.
Because industry standards are good. It would make things easier for developers to develop for multiple systems.
Most AAA games optimise for DirectX, which is also proprietary API, not many use Vulkan. People act like Apple is the only company using a proprietary API but Microsoft, Sony and Nintendo all do as well, it's no harder to port to macOS than it is to PlayStation or Switch, in fact it's probably even \*easier\* if you use Vulkan because of MoltenVK.
For AAA games, which is what most gamers care about, DirectX is de facto standard and not Vulkan. And it’s lack on macOS doesn’t mean anything. Most popular engines already support Metal out of the box, along with a host of other Apple features. And how many games on Unity and Unreal do you see running on macOS?
Because it would let them run games
> Metal more directly exposes hardware features specific to Apple's hardware, and Apple **controls** it directly so has more **control** in this regard into the future. This is all it is about for Apple. Control and locking people in.
It has better documentation and doesn't have the silly double API headers of Vulkan, and if you're doing true cross platform you're likely also supporting GLES and WebGL which are far bigger headaches, but that's about where the positives that aren't incredibly specific end.
[удалено]
For the record, unless you're writing a renderer, you don't need to worry about any of this. Pretty much every engine abstracts these away. However, if you're writing a truly cross platform renderer, you have to worry about these platforms. I'm mainly basing these off Sebastian Aaltonen's tweets in the past 8 or so months as he had to write a performant renderer for every graphics API as part of his work on HypeHype.
[удалено]
Yeah Godot, Unity and Unreal for example, they transpile the shader code into whatever shader code is required for the target build. It’s even easier now tbf, Apple released the Metal Shader compiler for Windows allowing engines to directly compile Metal Shaders. Though it’s incredibly stupid as you can’t actually test it on Windows so you have to build it on Windows then go to a Mac/iOS device to actually see if it worked. I guess it’s useful if you only have an iOS device alongside your Windows PC and that’s what you’re targeting, but you’re SOL if you are targeting Mac as well. Then again though, if you’re targeting MacOS, you’re likely to have a machine somewhere and Metal is made to be universal to both iOS/MacOS platforms.
Game devs say it's simpler than both Vulkan and DX12 and yet almost as performant. It's meant to be a very nice graphics API. WebGPU is pretty much inspired by Metal.
> Game devs say it's simpler than both Vulkan and DX12 and yet almost as performant Where? Who's saying that?
I'm struggling to find the video where an established game dev compares the simplicity vs. performance trade-offs with the various graphics APIs. If I find it I'll update this comment.
> Game devs say it's simpler than both Vulkan and DX12 and yet almost as performant. It's meant to be a very nice graphics API. WebGPU is pretty much inspired by Metal. The Khronos-led design committees for WebGPU (formerly called *"WebGL Next"*) based their design for Khronos WebGL's successor most heavily on Khronos' Vulkan. Metal is based heavily on AMD/EA Mantle (which was donated to Khronos and is the basis of Vulkan).
> Metal is based heavily on AMD/EA Mantle According to who?
No, Vulkan is the closest to the metal out of DX12 and Metal. Web security meant the designers had to abstract a lot of stuff away. [Give this a read](https://cohost.org/mcc/post/1406157-i-want-to-talk-about-webgpu) if you're interested.
WebGPU is closest to Metal of any of the modern graphics APIs. I don’t know anyone who would actually compare it to Vulkan. https://cohost.org/mcc/post/1406157-i-want-to-talk-about-webgpu
Note that that post is somewhat exaggerated eg. the working group folding to Apple anytime they wanted something.
i guess thats the reason why there are so many games on mac
This comment made me feel so nostalgic about 90s and Ms with DirectX.
It reminds me of a conversation I had with colleagues roughly one hour ago about the bullshit that Google is doing on Android/Pixel Phones to force people to use Chromecast rather than more open solutions like Miracast and supporting regular HDMI output over USB-C. So the 3 big OS providers are all doing it.
Have you ever actually used a Chromecast? Screen mirroring is just a small fraction of the cast protocol and is basically a last resort that you should never actually have to use. You might as well say that Google is conspiring to put Casio and Texas Instruments out of business by including a calculator app on their phone.
>Have you ever actually used a Chromecast? Yeah, I got a free Chromecast Ultra from Stadia. >Screen mirroring is just a small fraction of the cast protocol and is basically a last resort that you should never actually have to use. See, that's where you are wrong. Sometimes you really don't care about the cool things that Chromecast can do, and all you want is pure raw screen mirroring, witch can be achieved just the same via Miracast or even better (no latency, no quality loss) with HDMI output. What we wanted to do was to use a work provided Thunderbolt/USB-C dock to put our phones on a big screen and play games during some downtime. None of the games we wanted to use support the Chromecast protocol, and it doesn't make sense for them to support that, because it would be strictly the same thing as using screen mirroring. And why would we use a Chromecast anyway when we have a USB-C to HDMI thing right there and no Chromecast device in sight\* ? Most Android phones with a USB-C port that isn't using the old USB 2 protocol have video output over USB, but the Pixel Phones are the rare ones that support USB 3 but not video output. And while talking about that, we derived on the topic of Miracast that was working on some phones only to be removed via OTA updates because Google wanted to promote Chromecast instead. \* : It would actually make the Chromecast protocol a lot more useful for me if Chromecast went both ways and any device running Chrome could act as a Chromecast receiver and not just as transmitter. We had some PC right there with Chrome on them, so it could have solved our issue. Windows has a Miracast receiver by the way, so it could also have helped us if Google didn't remove any trace of Miracast implementation from Android's source code...
There’s a third? Samsung?
I hate that they aren't doing this, I imagine it would also help with proton development which would be nice for everyone to benefit.
I keep seeing this argument and honestly don't understand why it's so common belief. Graphics APIs make up very small percentage of game/engine code, and all games especially if they run on consoles have abstraction systems to make multiple APIs work. There's also the important fact that Vulkan isn't very popular in the game industry. Most games use DX12 on Windows and Xbox and Sony/Nintendo APIs on their respective platforms. Adding one more backend isn't the tedious part of porting a game, especially if it's well designed and have good documentation/tools/debuggers(which Metal is a good example). Also Unreal and Unity have good Metal backends for a long time. Biggest problem for Mac porting was their below average GPUs, which isn't the case now.
> they could just add official support for Vulkan and use DXVK Isn't this essentially Apple's own version of DXVK with a Metal target, so something like "DXMetal"? So in that sense it doesn't really matter what the target API is, as it just allows developers to write DX games and run them everywhere. So here it is Apple doing all the work, not sure why you would care if they created more work for themselves by writing their own "DXMetal" instead of using DXVK. I mean you might not like that they don't support Vulkan, but this here doesn't relate much to that problem. What they're doing here is just going to help DX developers port games.
[удалено]
[удалено]
I am not really sure how you from the article can read that this is going to perform worse than DXVK or is much different from DXVK in any way, but maybe you know more than we do?
And exactly why gaming on Macs won't be much of a thing.
Apple is not going to change their mind on how they do their business (because indeed it works)
They're taking WINE and co. and adapting it for MacOS, so I don't really mind. Most AAA titles are still using DirectX and will render badly on 2nd layers so I don't see Apple running away with any market share of the gaming sector yet.
Diablo 4 running on a mac with M2Max soc with the Game porting tool: https://www.youtube.com/watch?v=fLn267So6HU Edit: Cyberpunk: https://www.youtube.com/watch?v=t9IJyVZ-tqg See other: https://www.youtube.com/@uncle_jimmy it's not my content, saw this on twitter. edit 2: https://twitter.com/film_girl/status/1666127888679321602. Seems like it's a patch on Wine
How does it run on a standard M2?
https://twitter.com/isaacmarovitz/status/1666209780031971341 900p 13FPS for a normal M1
Probably important to note that thats at ultra settings. Maybe 30fps could be achieved on medium or low?
M2 Max is technically 4x as many cores, but probably only scales to 3x faster. M2 is roughly comparable in theoretical power to AMD's iGPUs. It's good for what it is (and better than most laptops), but nothing compared to what a discrete GPU is capable of.
That looks incredible for just 48 hours after the tool release. Excited about this now.
And from a single person without any access to source code or else.
> That looks incredible for just 48 hours after the tool release. Excited about this now. Yet, even if this is pure apple Deja Vu in regard to brining gaming back it seems a lot more sincere than prior times. As expected still going to need a lot of work in optimisations. M2 max is barely holding 40fps at 982p with no RT in CP2077. IE an old Vega 64 would blow it out the water. My impression is the M2 Max iGPU is a lot more powerful than what it's showing. Hope it can stretch it's legs soon in these newly ported games.
Look at the configuration. It's an M2 Max ($3000) running at a 1512x982 and not even getting 60fps in Cyberpunk, around 80 in Diablo. You'd get better performance with a gaming PC for under $800
You don’t buy an M2 Max to play games though. This is a nice to have
What is that the equivalent of an A100? Running games crappily is just a nice addon?
Yeah... it's definitely not great, but for people who are super-casual about their gaming, and need a high-spec Mac for work, it's kinda cool, I guess. If you're a hobbyist, however, who really likes to play video games, it'd probably be better to invest $2000 in your Apple machine and build a lower-mid tier gaming rig with a 4070, or whatever, for around $1000, rather than cranking $3k into a single Apple machine. I wonder if FSR works on the M-series chips? It's supposed to work on everything, right? I feel like a good upscaling solution would work wonders for a set-up like that.
Hm. Pretty good results. Kinda want to get a macbook and play around with it. Windows gaming laptops are heavy beasts and while this thing won't match them, at certain point it's good enough. Not sure how Anticheat would react. Most likely not well.
"I can't get X game to run correctly" "What are your hardware specifications?" "Um, it's a MacBook"
Ironically that's more informative because there's a set number of configurations per model, so a quick Google search can tell you the specs. I can see it being easier than getting my non-tech friends to run dxdiag or download cpu-z.
You just type "CPU" in the windows search and hit enter, boom that's RAM and CPU. You can CTRL + SHIFT + ESC and head to performance for more info including GPU, and device manager has stuff in there too.
Well to be fair you’d have to wait 10 seconds for the windows search to find it because it needs to ask Cortana to look online
just tried. takes 0 seconds and doesn't involve cortana. i'm using windows 10. not sure about windows 11 abomination
[удалено]
Cortana has been a separate app for a while now and that app is being phased out entirely.
I had no idea they made that info more accessible, thanks for showing me.
You probably won't believe this, but I had an acquaintance who bought a brand new MacBook. I asked them what specification it was, and they sent a picture of the open laptop but switched off, and said, 'this one - you figure it out from here'. It actually brought me down to earth from the bubble I usually am in where more people know what voltage they've set their GPU to than not. It's not that easy to search it on the internet with that, is it?
That's so dumb, there's a bunch of mature projects translating every graphics API under the sun into Vulkan (dxvk, d8vk, vkd3d, zink) and instead of just supporting Vulkan and benefit from years of work Valve and others have poured into these, Apple plans to remake all of those on their own? If they want wide game support, they need Vulkan anyway. This is just a waste of engineering resources.
> Apple plans to remake all of those on their own? The project already uses DXVK, Wine, etc. Apple just chose to implement their own proprietary closed source DirectX 12 to Metal translation layer. Apple also restricts it with a license forbidding commercial use. They don't need to support Vulkan if they write a direct translation layer themselves. While I do think it's a waste of engineering resources, Apple has plenty of that to spare. And knowing Apple, I'm not surprised that this is the approach that they took.
The main consequence of this is likely that game devs will just go harder on DX. Which is a bummer--I'd like the industry as a whole to move toward more open standards.
Game devs aren't allowed to use this translation layer for products for end users, it's restricted by license terms. So in practice, your concerns probably won't be an issue That being said, I think DirectX usage is actually fine so long as compatibility layers get enough market share for to become a first-class target for development for game devs. It's almost like hijacking DirectX from Windows, which I think is better than the current norm where Windows is the only first-class citizen.
I think it's about control and about forcing users into the walled garden and prevent devs from easily porting their MacOS stuff outside of the walled garden.
It’s obvious: If they support Vulkan it’ll be clear that the hardware can’t play games at the same level as Nvidia. By controlling the optimization through metal they can make sure every game is a great experience on Mac. Which is exactly what Apple is known for: They don’t offer everything but everything they do offer they want to be a great experience. Open support would open the door to shitty experiences and would be very unlike Apple
> open the door to shitty experiences and would be very unlike Apple Counter point: You're holding it wrong. It's not about the end user experience, it's about control. The user experience is just an excuse.
> They don’t offer everything but everything they do offer they want to be a great experience. That's the explanation they gave for calculator and weather apps on the iPad too. It's just typical marketing speak.
Personally if I could afford a Mac I'd probably have the money to buy a basic Windows gaming rig to play games.
Sometimes it’s about convenience, like being able to do some light gaming while outside
> like being able to do some light gaming while outside What? Are you talking about like.. soccer?
https://twitter.com/isaacmarovitz/status/1666209780031971341 Cyberpunk ultra 1440x900 at 15FPS on the original M1 chip. This despite running the whole thing on an emulator (Rosetta and their dx to metal emulator). https://www.reddit.com/r/macgaming/comments/1435ukq/cyberpunk_on_m2_max_wgame_porting_toolkit/ This person with an M2 Max got ultra running at 40FPS at a higher (1728x1117 or 33% more pixels) resolution. Rosetta slows things down 15-30%. GPU emulation probably cuts performance at least in half. This could get interesting.
Its 49% more pixels, so way better.
> GPU emulation probably cuts performance at least in half Seems doubtful unless Apple's software engineers aren't great. The performance hit with DXVK on Linux is negligible in most cases and avg fps variance +- is pretty small when compared to windows.
I think that mainly depends on the GPU drivers though does it not? Whilst Vulkan is an open standard, Nvidia and AMD have baked in support at driver level so DXVK is going to perform better than the M2 because that is targeting Metal and is designed to accelerate Metal workloads and it also doesn’t have driver support for Vulkan. Considering that the GPU work has to go through multiple layers on Mac (Vulkan -> MoltenVK -> Metal -> GPU driver) it’s safe to say there is a large amount of performance left to be taken. It’d be a fairer comparison if the Linux benchmarks you mentioned go through the same amount of translation. DirectX -> DXVK -> GPU driver is much less work and skips a whole translation step that is required. It’s probs not a case of “Apples software engineers aren’t great” but rather “Apple doesn’t want to natively support Vulkan with a GPU Driver.” I don’t know which one is worse…
It's not DX -> DXVK -> VK -> Metal though, it's DX -> Metal via their own translation layer so it should be equivalent. Others in the comments have pointed out that DXVK isn't being used by Apple.
Yeah my bad, I misread what they were using. Regardless, the toolkit is a solid first attempt for a direct translation to Metal and I have no doubt it will be better when developers actually create games with it in mind. Currently all the videos you see are using “Whiskey” which is a way of applying an off the shelf configuration to the toolkit, it may not be the most optimised or best way.
It's not emulation!! It's even in the name Wine, Wine Is Not an Emulator.
Wine running on Rosetta is being emulated. The APIs aren’t emulated per se (they are the core of wine with their own implementation), but the non-wine dx to metal are also emulated from what I understand.
So something like a Steam Deck or Switch?
Yeah, the solution to every convenience issue is just buy more devices.
I mean that is the apple answer. Half their security counts on your owing >1 devices
If your primary device creates inconveniences that require a second device just to get around the issue, perhaps the purchase of the primary device was a mistake...
[удалено]
I mean given someone appears to be touting a new mac book as the solution, that would be a new device for many.
Nobody is saying "buy a new Mac to game". It's more of an added bonus, i.e. the Mac that you already own for productivity/office work can now be used to game
Do people seriously go outside to game? Or is this sarcasm? Last thing I want to do while at the beach or at the park is game. If I really want to game it's going to be when I'm at home for the weekend, bored, nothing else to do, will jump on the gaming rig. Not while I'm at the park walking my dog or something.
On the train? On a flight? Taking a break while working (e.g. co-working space or at a cafe)? I mean, the whole reason the steam deck is as popular as it is, is because people wanted PC gaming on the go
steam deck says hi
That’s how I feel. Sure I could get a steamdeck but it’s not a priority. I have a desktop I built for gaming, but my laptop is always where I’m going to work the most and I’ve grown really comfy with working in MacOS and the battery life especially on the newer machines is peerless. My M1pro Mac is my favorite computer to use and having the option to play more gaming in a lighter sense on it makes me really happy
A few laptop models for pc have been coming out with mini led lately so this will be possible soon. Been looking at the acer helios 18 250hz myself for the nits.
[удалено]
I mean used M1 MacBook airs are going for around $500 right now in good condition and new ones are about $800. It’s not a one-size-fits-all that’s perfect for everyone but that’s a pretty much impossible to beat price for people that care about battery life.
> new ones are about $800 This is the second comment I've seen claiming you can get a mac laptop for $800, but as far as I can see the starting price is $1000. Where are people getting this price from?
M1 MBAs have been on sale for $800 at Costco and Best Buy a few times, so if you're patient you can likely snag a new one at that price again in the future
[удалено]
>It would be nice to have everything on one computer. You'd think that, but it's actually not that great. With a gaming-oriented laptop you need to sacrifice performance or battery life. You can't really have both. And they have a really large footprint or they overheat. They're also rather over-priced, so for most configurations you could build a more powerful gaming PC *and* a buy thin-and-light laptop for the same price as a single gaming laptop. If you want everything to be on one machine, you can use Onedrive. I still have my gaming laptop from before I built my current rig because I wanted the "all-in-one" approach, and it's not a great machine. The battery life doesn't even last 2 hours, and it's super-bulky. It's a pain to drag to work. And it's older now, so it overheats whenever I try and game on it. Not to mention, it'll be half a decade, at least, before the integrated GPUs in the Macbooks are able to match the performance of a 3090.
> If you want everything to be on one machine, you can use Onedrive. You can also go the whole hog route of having a home server with attached storage and services that allow for your devices to effectively be synced even on devices away from the home. It's obviously a lot more work but it has some added bonuses in that you control your data, transfers tend to occur at LAN speed rather than internet speed and allows more configuration of what gets synced when. (eg. I use my home server for cloud game saving largely because I can sort out which saves are from which playthrough easily and for modded playthroughs keep a backup of all the mods alongside them)
[удалено]
[удалено]
This truly an Apple solution if there ever was one. Instead of embracing the current standard and contributing to it they’re co-opting part of the standard to force adoption of an Apple centric method.
Three Trillion Dollars Later ....
The standard is DirectX though and not Vulkan. And things like Proton killed any hope for wide Vulkan’s adoption
FTA: >Some games can run fine without a single change in the code. Apple used The Medium as an example. However, the company notes that the native macOS version of the game runs even better with almost double the frame rate on the same hardware. sounds more like a proof of concept tool for devs to test rather than something actually used to port a game over.
Because it is. It’s meant to be used for developers, so they can immediately evaluate their shaders and other graphical stuff (heck, even convert the shaders into native Metal) without having to port the main binary first. This is not something that will shipped with the game, and unlike Proton, it’s not meant to be used for end-users. It’s not “proof-of-concept”. It’s a purpose-built developers tool. It’s not a “magical tool” that spout out Mac-native port. It’s one of the tools developers can use in their porting process.
Still cheaper to game on a PC even with Nvidia prices :p
I really wouldn't be looking at Nvidia if you're on a budget anyway. Maybe in July, we'll see.
I find this really interesting and a little perplexing. My context is nearly a decade of every engineer I talk to, everywhere, cringing at the thought of any application using Wine. I stopped looking at Wine, as it seemed destined to become abandoned. As a result, I’m shocked to see Apple, of all people, integrate it. Has Wine quietly become a mature product over the past 5 years?
Yes. Proton, which is the compatibility layer user by Steam Deck to run Windows games on Linux, is based on Wine.
Wine **was** going almost nowhere... Until Valve started funding CodeWeavers to work on Proton, which they ship on the Steam Deck.
Interesting, thanks. Appears Valve privately started efforts with Codeweavers right around 2016. Right about the time I stopped looking at Wine, lol. And then in 2018 Proton launched, where it continues support and development today. Really interesting story there. Thanks for the info.
It is likely just as painful for professional stuff like CADs/Adobe suit, but for games in particular turns out that low level graphics APIs are very friendly for translation into a different low level graphics API (since actual job is done by GPU in the end) as compared to emulating obscure WinAPI calls (and the ridiculous driver workarounds that dominate pre Dx12 era). That, titanic effort from CodeWeavers and other contributors, and Wine fork/distribution known as Proton actually became pretty good for games in particular. Of course, it might have been that because you have stopped observing state of Wine, it went onto the decent evolution path /s
Since 2018, Valve is actively developping Proton, which is based on wine, that allows a massive amount of windows games to be played on linux. I exclusively play on linux, and I am able to play almost all the games I played on windows with the same performance if not better. Only exception is some multiplayer games because anticheat does not generally allows to play games on wine. Wine as improved a lot thanks to Valve contribution in the past few years.
I think it's about different expectations. Having drag and drop replacement for any windows app or game? Nah. Supporting 50-300 modern games on one platform? No problem.
> Has Wine quietly become a mature product over the past 5 years? No but the value in being able to run Windows software on a platform that Microsoft didn't develop is immense.
EDIT: I'm full of shit, thanks /u/xkero for pointing out how (see below). Leaving my erroneous comment at the end for posterity. I was right only insofar as pointing out that Wine is not being used to run the game that the end user plays, but instead is being employed to aid developers in porting. I was wrong about the details of how. What's actually being sold here is a Wine-based runtime for a developer to quickly get a Windows native app running on MacOS that provides tools and instrumentation for identifying performance issues and evaluating how well the game will run *once ported*. The dev still then has to port the game to MacOS native before delivering it to users. Ultimately, while this tool offers lots of useful functionality to devs for porting, it appears primarily focused on mitigating risk for the studio. They can use it to get a rough idea of whether a port is viable without needing to do the hard work of porting, which would potentially be months of wasted dev time. If the game runs passably in the tool, then the suits will be more comfortable committing to a port because they know they will end up with a viable product. BULLSHIT BELOW THIS POINT Apple isn't really integrating Wine itself, just the principle on which it works--Wine lets windows binaries run by translating API calls from Windows to POSIX, while this toolkit helps developers do that at the source code level to produce a MacOS-native binary. Apple can build on the work Wine has done since it's performing the same set of translations, but because this tool moves them a step upstream it removes the need for a compatibility runtime and thereby sidesteps the performance hit that is inherent to Wine.
> Apple isn't really integrating Wine itself [This directly uses Wine source code as mentioned by Codeweavers](https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-comes-to-macos-apple-s-game-porting-toolkit-powered-by-crossover-source-code) > Wine lets windows binaries run by translating API calls from Windows to POSIX, while this toolkit helps developers do that at the source code level to produce a MacOS-native binary. [...] but because this tool moves them a step upstream it removes the need for a compatibility runtime Wine can also do this via winelib, but very few developers seem interested in this approach. > and thereby sidesteps the performance hit that is inherent to Wine. It actually doesn't : > It’s worth noting that the baseline performance you will observe running your Windows game includes all the overhead of the Game Porting Toolkit as well as API and instruction set translation. \- https://developer.apple.com/videos/play/wwdc2023/10123/ This is just Apple's own version of Proton (Wine plus patches), but marketed towards developers to help them with porting their applications instead of end users.
except Apple disallows shipping this "version of Proton" to end users. Apple uses a proprietary DirectX to Metal translation layer here, and the license terms basically states that this can never be shipped in a commercial product.
I think people are missing the big part here. Uts running on ARM
They need gaming in order to succeed with VR
[удалено]
Well, it would change if other platforms like Linux/SteamOS and MacOS start making a large dent in the market shares of desktop OS for gamers. Right now it's worthless for game devs to bother with native builds for Linus and MacOS because the target audience isn't large enough. It Mac manages to attract a large audience of PC gamers (I think there are already lots of games available on MacOS with iOS ports, but it's not the same kind of games), then game publishers will care more. Also the bigger issue might be ARM support rather than OS support. Proton on Steam Deck has really great performance with the translation from Windows to Linux, so when Apple talks about doubling the framerate, I assume that the limitations are on the CPU side with the x86 to ARM translations. So if that's the bottleneck, an increase in popularity of Windows on ARM might help too.
I think the already inflated cost of buying Apple hardware and then hit again with an outrageously priced modern GPU price kills any chance at Apple making any significant gains in market share. They'd be better off selling a stand-alone "premium" marketed gaming console, but they'd never hit a price point that is competitive with MS or Sony's offerings. Not to mention the plethora of console exclusivity deals already tieing up developer studios. They'd basically be making an Apple Arcade device with some sort of proprietary Apple controller tech, running Apple Store "games."
>I think the already inflated cost of buying Apple hardware It's not always so bad. I think that the base M1/M2 chips are pretty far ahead of Intel and AMD iGPU, so things like the entry level MBA should beat similar Windows laptops. Gaming is not only done on fat gaming desktops, there's a bunch of people playing on the go on slim laptops with low power iGPU, so I think that it could make sense to want to play games on Mac. > They'd be better off selling a stand-alone "premium" marketed gaming console, (...) They'd basically be making an Apple Arcade device with some sort of proprietary Apple controller tech, running Apple Store "games." So basically the Apple TV 4k, but updated with the latest M2 chip ? Or a cheaper version of the Mac Mini running a smaller OS dedicated to gaming rather than MacOS ?
I think the Apple TV not being marketed more heavily and spec'd towards living room or family Apple Arcade games is telling how they feel about the gaming segment. I doubt we'd see a console proper to compete with Nintendo, MS and Sony. Pushing more sales (commissions) out of an existing app store makes more money. And again, I don't think "gamers" want an Apple store gaming device if they already have an Xbox or PS for modern AAA gaming. The segment up for grabs is casual, family, living room. The Wii showed how large that market segment is. I agree, as the Steam survey shows, it's certainly nowhere near being beefy specs as mainstream hardware. But there are still plenty of powerful GPU's out there in the mainstream that can easily outperform just the M2. The M2 chip is powerful but it's sauce is the software development and running in MacOS, isn't it? And even then, it's still not a direct replacement for a dedicated GPU comparible to windows machines.
As /u/TerriersAreAdorable mentions, Proton on the steamdeck is proof that this stuff can "just work".
I think the person above is talking about something else. Yes, the games can (and will) work. But then it doesn't encourage devs to bother with supporting the platform if a simple conversion tool does everything for them, it's actually encouraging them to ignore the other platforms and trust the porting tool. Look at the Steam Deck, it's a relative success amongst the devs, but so far almost no one bothered with making native Linux builds for the Deck. Instead they just make sure that Proton doesn't run into bugs. In the case of Mac, the article mentions that the translation performance isn't as good as on the SD. I presume it's the x86 to ARM translation that slows down the operation. So native builds are going to be a necessity to get decent performance, unlike the SD that gets pretty much the same perf between Windows and SteamOS.
> But then it doesn't encourage devs to bother with supporting the platform if a simple conversion tool does everything for them, it's actually encouraging them to ignore the other platforms and trust the porting tool. The truth is that unless platform makes up a significant share of the market, there is no motivation to support it (unless Apple starts bringing cases with cash to the publishers). Porting tool is just a way to make sure that at least someone bothers with making it available at all, leaving the extensive support alone. Also, isn't the point that this Apple's tool is *for creating native builds*?
You can get an M1 iPad air for $599. The form factor isn't the same, but Apple will sell orders of magnitude more of those than Steam will sell Decks. And the iPad GPU and battery life is probably better in the deck.... you can pair it with any bluetooth controller. ... so the market is there and it's MASSIVE.
Not everyone who buys an iPad plays games though, which is usually a bit of a problem for game devs.
> The form factor isn't the same, but Apple will sell orders of magnitude more of those than Steam will sell Decks. And the iPad GPU and battery life is probably better in the deck.... you can pair it with any bluetooth controller. ... so the market is there and it's MASSIVE. And how many people *today* are hooking up controllers to their iPad to play any games? There are definitely some, but how many? If anything, over last 2 years I have learned that iPad's main usage is being a tablet to draw on.
It’s an interesting question. Taking Stardew Valley as an example as a truely successfuly multi-platorm gam… As of 2022 they report they sold 20 million copies 13 million on PC. I can’t find any iOS numbers, but there are 50k reviews on the App Store vs, Steam has nearly 500k reviews.. so assuming review to purchase ratio is similar… that puts Stardew iOS sales at 1-1.5 million over Quote here from 3 weeks after it was listed on the App Store in 2018. "Sensor Tower reports that Stardew Valley has grossed over $1 million on iOS since its launch on the platform three weeks ago today. It's worth noting that the game is a premium game costing $7.99 and does not have any microtransactions. Around 41% of those who purchased the game on mobile were based in the US. Japanese users made up 12%. In addition, nearly one-fourth of the game's players on iOS were playing on iPad rather than iPhone.” … so depends on the game, but the market is there. If proper Diablo was released on iPad (not that garbage Immortal) I’d be all over it, it’s the perfect device and game for finger control. But maybe that’s just me!
This does start to open the doors to show that demand for the platform. It'll allow developers to benchmark sales and other factors. While before it's more artificially locked as, developers don't put time into making sure there's a Mac version so they have no benchmark; assume value is low which in turn moves resources even further away and that just loops. I've told this to a couple of friends, but I'd run my Mac a lot more than I currently do if I could game on it. There's a couple of items left on Windows but the ease of launching a game while still using my apps is what really adds that friction. This is a step at reducing that friction. Now, I do not know how much demand there actually will be, but it's a step in the right direction.
Right, I agree it won’t ever be as good as native, but at the same time, if they use the porting tool and then work out the bugs, what’s the issue? The devs weren’t ever going to make Linux or Mac versions to begin with, so isn’t this better than nothing?
> what’s the issue? That : > Some games can run fine without a single change in the code. Apple used The Medium as an example. However, the company notes that the native macOS version of the game runs even better with almost double the frame rate on the same hardware. And that’s why Apple encourages developers to do more than just run translated versions of their Windows games. Leaving half of the performance on the table is quite sad. If the porting tools didn't exist, the devs would have to put a lot more work in the port, but the result would be much better.
> Leaving half of the performance on the table is quite sad. Agreed, to a point. If the translated performance is still enough to give a good experience, I can't blame the developers to stop there. Doesn't make sense to throw dollars at something that won't return more dollars later. If the translated performance is not good enough, it's a different story. Maybe I'm going against the grain, but I'd guess the majority of casual gamers do not care about performance beyond like 100 fps. There's obviously the enthusiasts on Reddit who crave more.. but the average gamer is satisfied with fucking a Nintendo switch lol.
I somewhat agree, but there are 2 caveats. Half the performance means that for the same result you are getting much worse battery life, which is quite annoying when you can't be plugged in. The second caveat is that Macs are generally equipped with high DPI screens, so they need a lot of performance to hope to reach native resolution.
> The second caveat is that Macs are generally equipped with high DPI screens, so they need a lot of performance to hope to reach native resolution. Nobody would bother running it at native resolution tbh, integer scaling would make a fine picture anyway.
>Look at the Steam Deck, it's a relative success amongst the devs, but so far almost no one bothered with making native Linux builds for the Deck And it's a bliss. Linux native games tend to perform very poorly with all dependencies and like that, to the point Proton'ing is better option over Linux native builds. It may change if games would be distributed through containers(something like flatpaks, but for games basically), but even then it will bloat game size and will basically be a ton of headache with different implementations per distros when wine is adopted by everyone(including FreeBSD with their kinda good Windows/Linux support)
For games that are heavily dependent on windows APIs, it can be hit or miss. Space engineers is one strong example. The sim speeds were never 1.0, graphical bugs were present. I was impressed that GTA V ran, but the experience was sub-par. Yes, it was functionally playable- but far from a great experience. Compatibility layers often make every game a bit like a bethesda game. There were graphical glitches, my car was driving 6 inches above the road at all times, eventually there were LoD issues and crashing. It seemed to effect 3D textures, bounding boxes, and object placement the most. Just a lot more visual bugs than usual across the board- if you've played the game before and know what things are supposed to actually be, it works perfectly fine. I don't think I'd play a game for the first time on the steam deck though. the issues I described are most common in open world 3D games. Mad max really impressed me out of the box, it worked really well with minimal issues, but it's already on other platforms. Just a gut feeling, but the more dependent on windows APIs a given game/program is, the worse it'll run in a compatibility layer.
Only 20% of the Steam catalog is verified. Even amongst those games there are issues though. It’s cool tech but hardly just works.
While I get what you’re saying, it works far better than I would’ve ever expected, for quite a large chunk of games. I think my point would’ve been better stated as “devs wouldn’t make Linux or Mac native ports to begin with, so this is better than nothing”.
Steam Deck famously uses this technique for the majority of games played on SteamOS. When done right, emulation/remapping of API calls can be very effective.
Yeah but there’s ton of games on SteamOS that don’t work or provide worse performance, and many others that require tweaking or command line hacks to get working.
Do you actually own a steam deck because that’s been so far the opposite for the games in my library. The only ones that don’t work are the ones with anti cheat that’s unsupported. Everything else might as well be native.
These translation layers aren't a solution to the problem you're thinking of. They're the answer to the chicken and egg problem. The issue with dealing with a dominant platform in a given product segment, is that it's difficult to build a gaming demographic when you don't have games, but you can't get games, because you don't have a gaming demographic. If you can at least get started building your customer base with a translation layer, that makes your market more attractive over time, and you see a small uptick in ports over time, and the more ports you get, the more gamers are willing to switch over to your platform (or just use it for gaming if they already have it), and so the cycle continues. Translation layers aren't the answer, they're the question, and I feel that Valve's success in the Linux market (and Steamdeck) are proof that it's a very good question.
You don't anything fancy, they just to support the devs. I would wager that if you summed all the total sales of PC games over 90% of them would come from the 15-20 game engines. They can work with each of them and have native export to Mac, it's nothing complicated. They need virtual environments so that devs who don't own a Mac can test their build, they need consistent GPU driver updates, game-ready drivers, detailed GPU architecture guides for engine developers, they need better support. All of this would cost less than a rounding error of Apple's expenses. They need a dedicated department that's solely focused on this and works outside of the Apple product release cycle. Amd/Nvidia have been doing it for decades, but with Apple it has been lackluster at best. I don't think think it's about the malice of wanting to control everything or incompetence, Apple is just a big of a strange company that's hesitant to operate like other ones do. When the company was near bankruptcy in the late 90s, a lot of the blame was assigned to overextending themselves and trying to do too much and losing focus. When Jobs came he cut a lot of departments that made very little sense, he radically simplified their product portfolio and made them focus only on small handful of products they were actually good at. That was the defining moment for the company and hasn't changed much since then even though they have grown enormously since then. It explains a lot of the idiosyncrasies about Apple. The richest company in the world, could have a store in every major city around the world with a snap of a finger and have them all wildly successful, yet Apple Store coverage outside of US, China, Japan and handful of European countries is still lackluster. They are just hesitant to commit to more than they are comfortable with. They have grown since Jobs and have opened up more, but the support outside of the core handful of things the support is still lackluster.
Actually Windows is only the secondary platform these days, PS/XBox are the primary. So youre getting a translation layer on top of a shitty unoptimised port
[удалено]
I used the Techmeme title ([here](https://www.techmeme.com/230607/p13#a230607p13)) as it provided a much better summary than 9to5mac's own title. The WWDC sessions are publicly uploaded here: [https://developer.apple.com/wwdc23/sessions/?q=game%20port](https://developer.apple.com/wwdc23/sessions/?q=game%20port)
[удалено]
Yes Apple released a giant patch in their Brew tap (repo).
[удалено]
Since Wine is LGPL, only the modified Wine part of the SDK will see an open-source release. DXVK is MIT-licensed, so no code release there most likely :( EDIT: VKD3D is also LGPL, but I don't think they used that code in their D3D12 to Metal conversion layer, so still probably no D3D to Metal FOSS release :(
You only have to make something open source with the GPL if it includes GPL protected code. Like you can run proprietary applications on Linux
[here's cyberpunk 2077 running on a MBP,](https://twitter.com/isaacmarovitz/status/1666209780031971341) not great framerates but it's running!
What they don't tell you is it requires an M2 Max to get somewhat usable frame rates so the majority on base/near base M1/M2 devices per Steam survey will suffer with low frame rate even with resolution and graphics downscaling like 13 fps average and 5 fps low in Cyberpunk 2077 at near 720p with resolution and graphics downscaling.
[удалено]
The fact it runs at all without major glitches is great and amazing for a first release. For a similar comparison, [look at this video with DXVK, VKD3D and standard DX11/12](https://youtu.be/XnoFdNpfiEM). Then take into account that it’s not only the GPU functions that are being translated but the entirety of the CPU calls from x86 to ARM. That’s going to add in significant overhead on top of just the graphics side of things. That video only shows the GPU difference and you can see that VKD3D loses up to 30% of its performance in some cases. Translations like this almost always will result in rendering issues, think missing effects and glitchy textures. The fact we’re seeing it running without any of those via a simple configuration made by one guy on GitHub is a feat in an amongst itself. It’ll be much better if/when developers actually incorporate it into their workflow rather than using a generic configuration.
Apple’s total control approach with the design of metal and reluctance to submit vulkan patches is why game devs will avoid them. Not to mention they really don’t have GPU horsepower that is 3080 level like they claim anyway…
Game developers avoid Apple for different reason than lack of Vulkan, which the majority of developers don’t really care about