[pjmlp]

> May be you can develop an engine for all APIs at once for the cost of one?

Because as anyone in the industry knows, the portability of APIs like OpenGL only happens in theory.

To expose the hardware features that makes the game shine and stand out over others, one needs to make use OpenGL extensions.

A different set of calls for each card model, manufacturer and game consoles if they expose an OpenGL wrapper API.

Then there are the workarounds for the API calls that are supposed to be part of portable OpenGL, but then again behave differently across graphics hardware and drivers, leading to additional code paths.

The shading language features are also different across OpenGL versions and graphic drivers.

Finally OpenGL and OpenGL ES are common just in the name and a few overlapping APIs, leading to rewrites between desktop and mobile platforms.

In the end, the development effort of writing "portable" OpenGL, while taking advantage of vendor extensions and working around bugs is bigger than use exposing an common abstraction layer on the games engine that takes advantage of each native API without piles of workarounds.

[shmerl]

OpenGL wasn't portable enough to be performant at the same time, for several reasons. I'm talking about Vulkan, not about OpenGL and its troubles in the past. Vulkan addresses the issues which you mentioned.

[royjacobs]

Vulkan still has extensions. The whole reason game developers want to have lock-in is so that you can squeeze the maximum possible quality out of a known set of hardware.

Once you start abstracting that away you are falling behind other companies who may be able to draw slightly more particles at slightly higher frame rates at slightly higher resolutions.

The whole reason Nintendo is still saying "we have Vulkan" is because they are the only console manufacturer were raw graphical performance was never the system seller.

[vetinari]

DX has driver caps, feature levels and optional features within each feature level - so you have to branch on runtime anyway, just like with OpenGL or Vulcan extensions. Even Apple Metal has Feature Sets for exactly that reason.

If you want to evolve your API together with the hardware, you need some extension mechanism.

[tinus_hn]

Lock-in doesn't cause you to be able to 'squeeze performance' out of the hardware. It causes you to specialize your code to the platform so much you can't port it to another.

It's the other way around. Developers don't care much about portability. The care about APIs that allow them to build performant programs. For them, a bad side effect of such APIs is vendor lock-in.

Why would a game developer want to limit his audience?

[wolfgke]

> Lock-in doesn't cause you to be able to 'squeeze performance' out of the hardware.

Let's assume GPU X supports some feature that GPU Y does not. Then you either use an (say OpenGL or Vulkan) extension to use it to squeeze out performance (lock-in) or you eschew the lock-in, don't use the feature and ignore the performance advantage. Now multiply this with lots of features and also consider that the graphic APIs of consoles offer some rather unique features that don't map directly to, say, DirectX11 or OpenGL.