3 ms·

Parent commenter is likely referring to MacOS's trash fire opengl support and zero Vulcan support. It's not about getting spectacular graphics on MacOS, it's a

Parent commenter is likely referring to MacOS's trash fire opengl support and zero Vulcan support. It's not about getting spectacular graphics on MacOS, it's about even getting your renderer to work.

cwyers 8y ago
This is really fighting the last war, though. Metal exists, and any game that is running on iOS (which it has to, to be in this) targets Metal. Who cares about anything else?
- rleigh 8y ago
  Everyone who doesn't develop exclusively for MacOS X, which is most of us. Am I going to rewrite my OpenGL application to use Metal. No. I might update it to use Vulkan, and see if it works with the MoltenVK shim for MacOS X. But I'm afraid that Metal itself is a complete non-starter.
- pcwalton 8y ago
  Android has much greater worldwide market share than iOS does (not to mention PCs, consoles, etc.) None of those support Metal. So yes, we graphics programmers do care about "anything else".
  - lilyball 8y ago
    If you're targeting multiple platforms you're likely using an engine rather than directly programming the GPU anyway. So you don't actually care about vulcan vs metal, you care about e.g. "Unity".
    - pcwalton 8y ago
      Some of us write the engines. :)
      - fsloth 8y ago
        Even then the graphical fidelity of the above games is approachable with a pretty simple set of "standard" shaders and rendering tricks that allow to limit the graphics api specific code to a manageable chunk. It's not nice, but it's not like one needs to port the entire engine. And then there are cross api interfaces like bgfx that allow more or less to share a common data interface with all of the API backends. I'm not saying that I like the fragmentation, but on the other hand I'll happily use win32 system calls when programming windows and posix stuff if programming unixen. So it's not entirely cut and dried what is the expected amount of platform specific customization one is expected to be able to deal with.
  - cwyers 8y ago
    Android doesn't support desktop OpenGL either (it supports OpenGL ES), and large parts of the Android install base don't support Vulkan either (anything before 7.x): https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards I would bet that there are many more commercially-viable games that support Metal than those that support Vulkan. More than anything else, I think what I was responding to was the desktop-centric nature of the post I was replying to. This is not Apple's competitor to Steam or Stadia, it's a different way for Apple to monetize App Store games without IAP. Even with the current worldwide market share of each OSes, there are very few commercial Android-only games and a great deal more iOS-but-not-Android games. That's the market segment this is targeting, and what graphics APIs macOS supports are a footnote to that.

Parent commenter is likely referring to MacOS's trash fire opengl support and zero Vulcan support. It's not about getting spectacular graphics on MacOS, it's about even getting your renderer to work.

cwyers 8y ago

This is really fighting the last war, though. Metal exists, and any game that is running on iOS (which it has to, to be in this) targets Metal. Who cares about anything else?

rleigh 8y ago
Everyone who doesn't develop exclusively for MacOS X, which is most of us. Am I going to rewrite my OpenGL application to use Metal. No. I might update it to use Vulkan, and see if it works with the MoltenVK shim for MacOS X. But I'm afraid that Metal itself is a complete non-starter.
pcwalton 8y ago
Android has much greater worldwide market share than iOS does (not to mention PCs, consoles, etc.) None of those support Metal. So yes, we graphics programmers do care about "anything else".
- lilyball 8y ago
  If you're targeting multiple platforms you're likely using an engine rather than directly programming the GPU anyway. So you don't actually care about vulcan vs metal, you care about e.g. "Unity".
  - pcwalton 8y ago
    Some of us write the engines. :)
    - fsloth 8y ago
      Even then the graphical fidelity of the above games is approachable with a pretty simple set of "standard" shaders and rendering tricks that allow to limit the graphics api specific code to a manageable chunk. It's not nice, but it's not like one needs to port the entire engine. And then there are cross api interfaces like bgfx that allow more or less to share a common data interface with all of the API backends. I'm not saying that I like the fragmentation, but on the other hand I'll happily use win32 system calls when programming windows and posix stuff if programming unixen. So it's not entirely cut and dried what is the expected amount of platform specific customization one is expected to be able to deal with.
- cwyers 8y ago
  Android doesn't support desktop OpenGL either (it supports OpenGL ES), and large parts of the Android install base don't support Vulkan either (anything before 7.x): https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards I would bet that there are many more commercially-viable games that support Metal than those that support Vulkan. More than anything else, I think what I was responding to was the desktop-centric nature of the post I was replying to. This is not Apple's competitor to Steam or Stadia, it's a different way for Apple to monetize App Store games without IAP. Even with the current worldwide market share of each OSes, there are very few commercial Android-only games and a great deal more iOS-but-not-Android games. That's the market segment this is targeting, and what graphics APIs macOS supports are a footnote to that.