Hacker News Reader

Comment by john_alan | Hacker News Reader

I disagree with that. macOS is basically BSD and it’s great for Dev. Most of the devs I work with use it.

You have to define what kind of developers you're talking about.

Do they work with graphics? OSX doesn't really have many native games running on it. So clearly there's a whole group of developers who aren't Mac first.

Like OSX is enjoyed by a lot of developers because it's similar to Linux.

However Apple deprecated openGL, aren't using Vulkan but have their own thing called Metal. So that makes it quite OSX specific.

Edit:

Looks like someone is working on it: https://github.com/PCSX2/pcsx2/issues/18

Apple ditched OpenGL and Vulkan for their own exclusive 3D graphics API. They're a terrible platform to develop for.

...if you're writing cross-platform games. FTFY

OP is literally asking why PCSX2 isn't cross-platform.

> if you're writing cross-platform games and not using one of the established game engines that wrap OpenGL/Metal/Vulkan

FTFY

Even if you're developing with a game engine, you'll soon have to write your own shaders or at least deal with their bugs. And for that, you'll need your users' hardware (there are no nVidia macs anymore), youre users' driver (which is predominantely Windows) and the ability to debug it.

Mac just doesn't make sense for this use-case beyond "I want an Apple logo!". Most people buy a tool to solve a problem, not hammer the problem to fit a brand.

Same applies even if using something like OpenGL, Vulkan, which is why browsers black list GPUs.

Apple ditched OpenGL for their own exclusive 3D graphics API that they had released in production before Vulkan was even announced.

That they don't bother with supporting Vulkan is incredibly frustrating for me personally, but not even remotely surprising given Apple's mode of business.

Does MoltenVK not do what you want?

For reference:

"MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on iOS and macOS." [1]

[0] https://moltengl.com/moltenvk/

[1] https://github.com/KhronosGroup/MoltenVK

All major middleware already does Metal, even non gaming stuff like Flutter.

Flutter only just did that the other day and it's because iOS is a huge part of their pitch as a cross platform framework.

Which doesn't invalidate the point that anyone that cares has already done the work.

Most emulators don't use middleware, because it doesn't afford them anywhere near enough flexibility or performance.

As anyone from Flipcode and Gamedevnet days knows, middleware can be as thin as couple of function pointers with shared libraries loaded on demand for the desired 3D API.

The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language.

When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.

If its so trivial, I'm guessing the developers would welcome patches.

Nowhere did I used the word trivial.

I wouldn't mind to contribute if paid accordingly.

The way some emulator use the gpu can be quite different from the way pc games use it.

You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ.

Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games.

edit: some clarification

That doesn't forbade loading shared libraries as function pointers though.

Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths.

3D libraries like OpenGL/Vulkan are only portable up to a certain extent.

When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions.

So, it is hardly different than having your own plugable abstraction layer.

Thats a strawman - the poster didnt say macOS is bad for development, just that no one in the PCSX2 project uses it.

Reply on news.ycombinator.com