|
|
|
|
|
|
by BinaryIdiot
3437 days ago
|
|
|
> 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. |
|
|
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.