[pjmlp]

Like I said, without experience in the games industry.

That is not how professional game developers see it, attending a few GDC would help to understand this.

Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.

[BinaryIdiot]

> That is not how professional game developers see it, attending a few GDC would help to understand this.

Do you wish to enlighten the HN community with the perspective you keep teasing? Or should we assume it's simply a narrative you wish to support?

Many companies have invested a lot of money into building various types of middleware as far as I understand it. But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.

I'm not sure how you get around that but...

> Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.

This isn't helpful and does not add to the conversation.

[pjmlp]

> But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.

Because the portability of APIs like OpenGL only happens in theory when you restrain yourself to a specific set of hardware.

The combinatory explosion of vendor extensions, driver bugs, shading language differences across versions and drivers, differences between OpenGL and OpenGL ES, force any studio that wants to keep sanity in their code, to write an OpenGL adaption layer anyway.

So if one if forced to write an adaptation layer anyway, then better go for the API that properly exposes all hardware features with less bugs and better tooling support.

This is one reason that while there are third party OpenGL wrappers to game consoles, or even first party ones like on the PS3, no one bothers to use them.

Taking the PS3 as an example, OpenGL ES doesn't define how to take advantage of the SPUs, other than via extensions anyway, thus making the code PS3 specific even if OpenGL ES is being use.

While at the same time less performant than the PS3 native API due to the OpenGL ES driver semantics.

[shmerl]

All this assumes, you need to use non portable extensions every time. It could be reasonable in the past, it's way less reasonable today. And using a whole different API is surely more complex, than adapting usage of portable API to differences of potential targets, depending on features which they support.

It's pretty easy to check what's supported by the driver and decide whether to use some optional feature.

[shmerl]

Whose experience in the industry says that lock-in is good for development? Sources please. Or may be you have an example of GDC presentations titled "Lock-in - the ultimate driver of engines' progress" or "Drive development costs down by proliferating lock-in"?

[pjmlp]

> Whose experience in the industry says that lock-in is good for development?

Lock-in is only in the heads of FOSS advocates, not in the game developers that want to squeeze the hardware to the limits of what it can do, while selleing the game.

> Sources please.

Go to GDC, IGDA, PAX, Game Development university degrees events close to you and do some networking talking with actual professional game developers, what is their opinion about graphical APIs.

Attend their talks about graphic APIs.

Read articles on magazines like Gamasutra, EDGE, Game Connections, Making Games about graphic APIs and the industry view on them.

[shmerl]

> Attend their talks about graphic APIs.

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.

> Lock-in is only in the heads of FOSS advocates

Oh, now you are trying to deny that lock-in exists? Then read about it from those who actually push it on developers: https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...

But I suppose you'll say that it's all imaginary. In such case further discussion is pointless. Figure out, does it exist and you support it, or you think it doesn't exist and you actually don't.

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

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

[CJefferson]

It's because no-one would both to write such a talk.

Game developers have already tuned their engines for the PS4 and Xbox 1 separately, and in both cases apply substantial specializations, designed to take maximum advantage of exactly the chips, the number of shaders, etc. available.

Any cross-platform library has to make some simplifying assumptions, which will produce a small loss of performance. Now, that's an easy trade-off to make if you are developing for PCs, there are thousands of common CPU/memory/GPU triples you might come across, you obviously aren't going to optimise for each individually. On consoles you do.

There have been a number of consoles that supports OpenGL. No-one ever used it, because the performance wasn't good enough.

[shmerl]

> There have been a number of consoles that supports OpenGL. No-one ever used it, because the performance wasn't good enough.

That's why there is Vulkan. OpenGL doesn't offer enough control to address such cases and isn't even designed to be parallelized.

[wolfgke]

> That's why there is Vulkan. OpenGL doesn't offer enough control to address such cases and isn't even designed to be parallelized.

That's why there is libGCM (PS4) and NVN (Nintendo Switch; cf. http://www.neogaf.com/forum/showthread.php?t=1297662). Vulkan doesn't offer enough control to address such cases and isn't even designed to take full-advantage of the hardware that is available in the concoles.

[wolfgke]

> Again, please show me any talk which says, that developers benefit from the need to address vendor lock-in

I don't believe it is a benefit for game developers. pjmlp already hinted some points. I will describe it a little differently.

For OSS hackers it is very important to be able to debug the things on their own. Game developers probably simply don't have the time for this. They instead buy support from the hardware vendor (AMD, NVidia, Microsoft, Sony, Nintendo etc.) if they get into driver bugs that they can't trace down on their own. Even more: In many PC game development studios there sit programmers that are actually financed by NVidia ("NVidia mafia") whose job is to make the game run fast/good-looking on NVidia GPUs (and perhaps worse on AMD ones ;-) ). In particular gamers playing on AMD GPUs are of course critical of this fact for obvious reasons. Now I ask snakily: What service do OSS (including OSS GPU driver) developers offer/deliver to game development studios to make the game-in-production run well on GNU/Linux and/or on open source GPU drivers? This should perhaps answer your question why game developers often don't care about OSS drivers etc.

[ivanmilles]

No-one claims that gamedevs see lock-in as something positive; only that very few AAA gamedev shops care about lock-in - especially for a relatively small part of the production pipeline as a graphics API.

What you see as locked-in API, others see as a great feature set to build on, probably with access to driver developers to help reach even further, past publicly available APIs.

A game engine is not something you can switch out of easily anyway. Everything from game code, to years of asset libraries to decades of source control repositories - all of those are very rigid parts of the production pipeline.

[shmerl]

> No-one claims that gamedevs see lock-in as something positive

Not according to pjmlp apparently, who tried to claim lock-in doesn't even exist, except in the mind of FOSS developers.