[pjmlp]

> Again, please show me any talk which says, that developers benefit from the need to address vendor lock-in which forces them to support multiple APIs instead of having an option of good cross platform ones. I doubt you can show any such talk.

You know that even OpenGL requires multiple paths full with extensions for supporting properly various render targets, right?

So if there isn't a talk accessible in the Internet it didn't happen?!

Again, talk to professional game developers, which apparently it is something you don't do.

As for the rest, FOSS advocates see lock-in as an hindrance, professional game developers see lock-in as the right set of features to make their game outsell the others.

That was the magic of computer hardware like Commodore 64, Atari, Amiga.

It was the lock-in to their hardware, to their special processors that made these platforms special, and many of the ports just meh quality.

This is the culture of games industry, pushing an agenda without understanding how the industry works, is like D. Quixote fighting windmills.

> But I suppose you'll say that it's all imaginary. In such case further discussion is pointless.

Of course, because I have the game industry experience that you lack and are unwilling to accept how it actually works.

Which I might add, also caused me issues in the past, because I used to think like you, before having had the opportunity to see the industry from inside.

[shmerl]

It has nothing to do with FOSS specifically. Lock-in is a hindrance for pragmatic reasons. Time costs money, which you seem to blindly ignore. Trying to say that lock-in is something positive is beyond silly.

> Of course, because I have the game industry experience

Apparently your experience didn't demonstrate you the negative effects of lock-in. May be you can develop an engine for all APIs at once for the cost of one?

So far, I'm waiting for some more substantial sources from you about benefits of lock-in for the industry, and how it's not a tax that hinders development, instead of abstract "get it from GDC".

[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.

[wolfgke]

> It has nothing to do with FOSS specifically. Lock-in is a hindrance for pragmatic reasons. Time costs money, which you seem to blindly ignore. Trying to say that lock-in is something positive is beyond silly.

As a game development studio you can buy support if you get to a problem with the locked-in drivers (NVidia is even well-known to smarm over game development studios and "lend programmers out" to make the game fast/good-looking on NVidia GPUs (and perhaps worse on AMD ones? ;-) )). In most cases game developers don't have the time to track down deep bugs in the graphics drivers (even if the GPU source were available). I ask: Can you at least buy on-time support from the Linux GPU driver developers if you find a problem with their drivers and/or buy on-time support to make the game run well on GNU/Linux?

As soon as the available support of the GNU/Linux developers becomes much better the the support GPU vendors offer to game developers for their "lock-in drivers", I believe game studios could become interested in supporting the "open source GPU driver" agenda. But not before.