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.
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.
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.
It's pretty easy to check what's supported by the driver and decide whether to use some optional feature.
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.
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.
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.
Not according to pjmlp apparently, who tried to claim lock-in doesn't even exist, except in the mind of FOSS developers.
