4 ms·

> and the open source community toils tirelessly making baby steps. FWIW, the Open Source community has had DXVK running >80% of the titles on Windows for year

> and the open source community toils tirelessly making baby steps. FWIW, the Open Source community has had DXVK running >80% of the titles on Windows for years now. The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion. Writing and maintaining Wine is a feat Apple is not legally well-poised to do - without the tireless toiling of Open Source contributors, this feature would not exist. So welcome back to gaming, Mac users. Let's hope this isn't a stopgap offering and more of a jumping-off point for DirectX9 coverage and the like.

gjsman-1000 3y ago
Worth noting that Apple is not just riding Proton/Wine’s coattails. As I wrote on another comment: Previously: DirectX -> Proton/WINE -> Vulkan -> MoltenVK -> Metal (yuck) Now: DirectX -> Apple GPT (groan at my pun, Game Porting Toolkit) -> Metal You could call it Proton with a Metal backend and more developer tools?
- smoldesu 3y ago
  Definitely not. It's just funny to see the Open Source contributions reduced to "baby steps" because Apple had to play catch-up with their graphics API. It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.
  - MBCook 3y ago
    Apple won’t be making an effort to support anything. This is a Developer tool to help developers figure out what it’s going to take to port their games to the Mac. End-users don’t get to use it. You can’t bundle it with your game. The license forbids it. It’s very interesting, and I’m sure the community will make the best use of it they can, but it isn’t designed to be the Mac Proton.
    - rched 3y ago
      I think that’s true today but it could change. I imagine Apple wants to encourage developers to build native games but I could see them loosening restrictions down the road. Maybe they eventually position this tech as the Bootcamp alternative for Apple Silicon. Time will tell.
      - Someone 3y ago
        If they do that, that’s basically giving up on Metal. It would become an implementation detail. Also, whenever the Direct3D API changes, they would have to follow. That makes them dependent on Microsoft and means they’d always lag them. Because of that, I don’t see them open this up.
    - poisonborz 3y ago
      "figure out what it’s going to take to port their games to the Mac" By running them on a DX12 translation layer that they can't utilise? What would be the use case then?
      - account42 3y ago
        Dunno about Apple's version but with Wine you can linnk native code against winelib, allowing you to test what you have already ported before you got everything up and running. Of course if Vulkan was a suppoted API on macOS, developers could just port to Vulkan on Windows and then implement the rest on macOS.
      - microtonal 3y ago
        Since they use their own Direct3D on top of Metal (D3DMetal), you can immediately start investigating performance while not much of the game is ported yet. Even while running the game in Wine, you can already analyze graphics performance with Instruments.app. At least this was the messaging in their talk about this: first you had to work months on a port to see how well a game would work on Mac hardware, now you can immediately run it, investigate bottlenecks and see where a port would land performance-wise before putting in any of the work. I wonder if they will make the D3DMetal usable from native code as well, I can imagine that would make porting much easier: - First you run on Wine + D3DMetal to get idea if your game would run well enough on Apple hardware at all. - Then you start building the game natively, still using D3DMetal, so that you don't have to immediately port the graphics stuff. - Once you have a running game on top of D3DMetal, you start porting it over to Metal with their shader converters, etc.
  - shmerl 3y ago
    Linux is so much better for gaming, including in hardware options. Apple just doesn't compare.
    - NayamAmarshe 3y ago
      Not sure why you're downvoted, it's a fact that Linux is way better for gaming and powerful desktop hardware.
      - surgical_fire 3y ago
        > Not sure why you're downvoted Butthurt mac users that don't like to think their toy is worse somehow, obviously.
  - jeroenhd 3y ago
    Gaming on Apple is going to depend on how well optimized the drivers and shaders for the GPU are going to be. You'll also need some serious upscaling because most Macs come with super high res screens, a GPU that won't be able to drive modern games at those resolutions and an utterly lack of graphics card support, even in the new Pro. Another factor is that major GPU companies put efforts into rewriting some games' shaders to make them run better on their hardware. I doubt Apple is going to do that so you'll probably end up with games performing better on other platforms soon after release. There's more to getting games to run smoothly on a platform than compatibility software. So far, the GPU has been lacking despite Apple's attempts to hype up gaming for mac. With the rate things are going, the year of gaming on Mac may be the same as the mythical year of the Linux desktop: inching ever closer but never really arriving.
    - zirgs 3y ago
      There's no need to run games at those high resolutions natively. Modern games now render only stuff like UI at the monitor's native resolution while the 3D viewport is rendered at a lower resolution and then potentially upscaled using DLSS or FSR.
      - nudgeee 3y ago
        Apple has MetalFX upscaling: https://developer.apple.com/documentation/metalfx https://developer.apple.com/documentation/metalfx
DaiPlusPlus 3y ago
> The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion Assuming this thing takes-off and suddenly the RGB LED-illuminated crowd switch to Apple hardware and macOS, then it's a very depressing thought because it means Apple will veritably make hundreds of millions (billions?) of dollars off Codeweaver's (and their extended community)'s work - and they'll get-away with it because their revenue can be classed as hardware sales, and not software licensing. I honestly don't know how to feel about this. I do feel a pang of smugness seeing the (post-iPhone) Apple having to stop pretending that copyleft doesn't exist[1] but also seeing them acknowledging that ecosystems other than their own do actually exist, but ultimately favourable smirks are in no way any kind of compensation to the unpaid effort put in by many of Wine-and-co's devs. I suppose Apple could do the decent thing and offer to acqui-hire Codeweavers et al., but that's more akin to a heavenly afterlife for Codeweavers' people (i.e. after acquisition Codeweavers would necessarily die along with their mission (beyond Apple's own self-serving uses) which might be a bigger disservice to everyone involved, especially the community. ---------- Unrelated-but-related: is any of Wine or Codeweavers' code under GPLv3? If so, that's might be the undoing of Apple's locked-down bootloaders: supposing that iOS, iPadOS or visionOS/xrOS includes DX12 compat via GPLv3-derived code: would Apple be legally obligated to explicitly allow users to install their own firmware contrary to their user-hostile, regressive, and (imo) indefensible policies so far? ----- [1]: Apple avoids the GPL, but so do all the large incumbents (though of course, like literally everyone, Apple is now fairly on-board with MIT/BSD licenses) - I do note that the KHTML-derived WebKit retains its GPL licensing, is a single, huge, exception, but I also note that Apple, internally, heavily firewalls-off their WebKit devs from anything else. (I've visited Apple's offices in-person and while the pizza place in the central cafeteria is nice, the fact that their SWEs can't casually walk down the hallway into another product team's office and exchange misc advice is just downright _weird_ to me, that's why I withdrew my only application to work there)
- sirwhinesalot 3y ago
  Apple is only providing this as a developer tool, to help simulate existing Windows games on macOS such that they can be ported more easily. Apple won't officially support a "Windows-Rosetta", this is not meant for users and won't ever be supported on iOS/iPadOS.

gjsman-1000 3y ago

Worth noting that Apple is not just riding Proton/Wine’s coattails. As I wrote on another comment: Previously: DirectX -> Proton/WINE -> Vulkan -> MoltenVK -> Metal (yuck) Now: DirectX -> Apple GPT (groan at my pun, Game Porting Toolkit) -> Metal You could call it Proton with a Metal backend and more developer tools?

smoldesu 3y ago
Definitely not. It's just funny to see the Open Source contributions reduced to "baby steps" because Apple had to play catch-up with their graphics API. It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.
- MBCook 3y ago
  Apple won’t be making an effort to support anything. This is a Developer tool to help developers figure out what it’s going to take to port their games to the Mac. End-users don’t get to use it. You can’t bundle it with your game. The license forbids it. It’s very interesting, and I’m sure the community will make the best use of it they can, but it isn’t designed to be the Mac Proton.
  - rched 3y ago
    I think that’s true today but it could change. I imagine Apple wants to encourage developers to build native games but I could see them loosening restrictions down the road. Maybe they eventually position this tech as the Bootcamp alternative for Apple Silicon. Time will tell.
    - Someone 3y ago
      If they do that, that’s basically giving up on Metal. It would become an implementation detail. Also, whenever the Direct3D API changes, they would have to follow. That makes them dependent on Microsoft and means they’d always lag them. Because of that, I don’t see them open this up.
  - poisonborz 3y ago
    "figure out what it’s going to take to port their games to the Mac" By running them on a DX12 translation layer that they can't utilise? What would be the use case then?
    - account42 3y ago
      Dunno about Apple's version but with Wine you can linnk native code against winelib, allowing you to test what you have already ported before you got everything up and running. Of course if Vulkan was a suppoted API on macOS, developers could just port to Vulkan on Windows and then implement the rest on macOS.
    - microtonal 3y ago
      Since they use their own Direct3D on top of Metal (D3DMetal), you can immediately start investigating performance while not much of the game is ported yet. Even while running the game in Wine, you can already analyze graphics performance with Instruments.app. At least this was the messaging in their talk about this: first you had to work months on a port to see how well a game would work on Mac hardware, now you can immediately run it, investigate bottlenecks and see where a port would land performance-wise before putting in any of the work. I wonder if they will make the D3DMetal usable from native code as well, I can imagine that would make porting much easier: - First you run on Wine + D3DMetal to get idea if your game would run well enough on Apple hardware at all. - Then you start building the game natively, still using D3DMetal, so that you don't have to immediately port the graphics stuff. - Once you have a running game on top of D3DMetal, you start porting it over to Metal with their shader converters, etc.
- shmerl 3y ago
  Linux is so much better for gaming, including in hardware options. Apple just doesn't compare.
  - NayamAmarshe 3y ago
    Not sure why you're downvoted, it's a fact that Linux is way better for gaming and powerful desktop hardware.
    - surgical_fire 3y ago
      > Not sure why you're downvoted Butthurt mac users that don't like to think their toy is worse somehow, obviously.
- jeroenhd 3y ago
  Gaming on Apple is going to depend on how well optimized the drivers and shaders for the GPU are going to be. You'll also need some serious upscaling because most Macs come with super high res screens, a GPU that won't be able to drive modern games at those resolutions and an utterly lack of graphics card support, even in the new Pro. Another factor is that major GPU companies put efforts into rewriting some games' shaders to make them run better on their hardware. I doubt Apple is going to do that so you'll probably end up with games performing better on other platforms soon after release. There's more to getting games to run smoothly on a platform than compatibility software. So far, the GPU has been lacking despite Apple's attempts to hype up gaming for mac. With the rate things are going, the year of gaming on Mac may be the same as the mythical year of the Linux desktop: inching ever closer but never really arriving.
  - zirgs 3y ago
    There's no need to run games at those high resolutions natively. Modern games now render only stuff like UI at the monitor's native resolution while the 3D viewport is rendered at a lower resolution and then potentially upscaled using DLSS or FSR.
    - nudgeee 3y ago
      Apple has MetalFX upscaling: https://developer.apple.com/documentation/metalfx https://developer.apple.com/documentation/metalfx

DaiPlusPlus 3y ago

> The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion Assuming this thing takes-off and suddenly the RGB LED-illuminated crowd switch to Apple hardware and macOS, then it's a very depressing thought because it means Apple will veritably make hundreds of millions (billions?) of dollars off Codeweaver's (and their extended community)'s work - and they'll get-away with it because their revenue can be classed as hardware sales, and not software licensing. I honestly don't know how to feel about this. I do feel a pang of smugness seeing the (post-iPhone) Apple having to stop pretending that copyleft doesn't exist[1] but also seeing them acknowledging that ecosystems other than their own do actually exist, but ultimately favourable smirks are in no way any kind of compensation to the unpaid effort put in by many of Wine-and-co's devs. I suppose Apple could do the decent thing and offer to acqui-hire Codeweavers et al., but that's more akin to a heavenly afterlife for Codeweavers' people (i.e. after acquisition Codeweavers would necessarily die along with their mission (beyond Apple's own self-serving uses) which might be a bigger disservice to everyone involved, especially the community. ---------- Unrelated-but-related: is any of Wine or Codeweavers' code under GPLv3? If so, that's might be the undoing of Apple's locked-down bootloaders: supposing that iOS, iPadOS or visionOS/xrOS includes DX12 compat via GPLv3-derived code: would Apple be legally obligated to explicitly allow users to install their own firmware contrary to their user-hostile, regressive, and (imo) indefensible policies so far? ----- [1]: Apple avoids the GPL, but so do all the large incumbents (though of course, like literally everyone, Apple is now fairly on-board with MIT/BSD licenses) - I do note that the KHTML-derived WebKit retains its GPL licensing, is a single, huge, exception, but I also note that Apple, internally, heavily firewalls-off their WebKit devs from anything else. (I've visited Apple's offices in-person and while the pizza place in the central cafeteria is nice, the fact that their SWEs can't casually walk down the hallway into another product team's office and exchange misc advice is just downright _weird_ to me, that's why I withdrew my only application to work there)

sirwhinesalot 3y ago
Apple is only providing this as a developer tool, to help simulate existing Windows games on macOS such that they can be ported more easily. Apple won't officially support a "Windows-Rosetta", this is not meant for users and won't ever be supported on iOS/iPadOS.