Middleware has already settled that question several years ago, only FOSS advocates without experience in the games industry keep wishing for a different outcome.
Nothing is settled, until the tax of supporting multiple APIs exist. Don't imagine it comes for free. The price is paid, whether it's in the middleware or not. You pay this tax in various ways, from slower progress of game engines, to more bugs in your games. And it clearly demonstrates the intent. Those who push this tax on developers don't want faster progress and higher quality. They want lock-in.
> 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.
> 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.
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.
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"?
> 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.
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.
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.
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.