4 ms·

Being "another walled garden thing" will hardly be its death knell. Proprietary single-vendor APIs are already common on games consoles, and it hardly seems to

by to3m 12y ago

Being "another walled garden thing" will hardly be its death knell. Proprietary single-vendor APIs are already common on games consoles, and it hardly seems to have caused a problem. Look at DirectX, even; not quite single-GPU-vendor, but hardly renowned for its portability, and popular nonetheless. These things will succeed if the platform is popular, and other factors are pretty irrelevant. I suspect iOS is popular enough to make this work.

shmerl 12y ago
I don't mean it won't be used. You are right, for example PS4 uses its own PSSL. But it's still a failure, because it's bad for developers who have to support multiple APIs and bad for users who likely won't get some titles for their platform because developers have no resources to support multiple APIs.
- MBCook 12y ago
  > But it's still a failure, because it's bad for developers who have to support multiple APIs and bad for users who likely won't get some titles for their platform because developers have no resources to support multiple APIs. That doesn't make it a failure, that makes it something you don't like. This could easily be very big. If it helps developers make faster/better looking games on iOS they'll do it, especially if it's supported by middlware (since most devs probably don't make their own engine). It that happens to make it harder to port games to Android (or at least get them to look as good), so much the better for Apple.
  - shmerl 12y ago
    I don't like it for a reason that it multiplies exclusive titles. I consider it a failure. Normally authors should aim to reach the most audience, not to exclude users because they use a different OS. This API will proliferate the later.
    - MaxBarraclough 12y ago
      A failure is something which doesn't succeed in achieving its goals. We often approximate this by looking at how widely used something is. For an API, this measure seems reasonable. It has nothing to do with your views on vendor lock-in. Direct3D also causes lock-in. That doesn't make it a failure.
      - shmerl 12y ago
        Failure applies here to cross platform availability. Vendor lock is is a failure by default. > Direct3D also causes lock-in. It does indeed. That's why it also fails to be the proper portable graphics API.
        MaxBarraclough 12y ago
        https://news.ycombinator.com/item?id=7838196 https://news.ycombinator.com/item?id=7838196 I already spelled out for you what the word 'failure' refers to, but fine, I'll try again. "Failure" does not mean "failure to please shmerl". That simply isn't the way the term is commonly used. Direct3D fails to make me a coffee, too. So what? Portability to non-MS platforms was never a goal. Neither was my coffee. It is clear that you are being deliberate obtuse to avoid conceding the point.
        shmerl 12y ago
        Failure means failure to be a portable API. Whether it's pleasing me or not is irrelevant. I explained the context of what I was discussing above.
- interpol_p 12y ago
  It's not a failure. It's an option for developers who are constrained by the fundamental performance impact of a generic OpenGL layer when it sits between you and the hardware. The reason this is good is because it's platform specific, so it can make assumptions about hardware that Apple is in full control of. I'm sure the big engines will just support multiple code paths where needed. And any existing developer has the option to stick with GL.
- to3m 12y ago
  Three things I suppose, coming at it from having worked on medium-to-largeish game development efforts: 0. Graphics APIs come far down the list of things people think about when planning a project. Platform support (or lack thereof) is driven by other concerns. It's a business or political decision, based on platform popularity (hence my original comment), not a technical one. Options for handling a skill shortfall include hiring more people or paying somebody else to do it. 1. Going purely by revenue and ability to attract new fanboys to the system, the bulk of development resource supply is not actually terribly interested in cross-platform graphics APIs. People using graphics middleware will use graphics middleware. Developers writing their own technology (and the people writing the graphics middleware) would actually rather have N simpler APIs for N platforms than a single complicated one that tries to support everything. That is then pretty much everybody in this space covered. (OK, yes - Direct3D11 is not especially simple, though I think it's simpler than OpenGL. But Windows is kind of popular. See point 1.) 2. The bulk of your average game's code is non-graphical, and the vast majority of the graphics code is not API-oriented or is shaders. (So, more shader languages is not a good thing, but you have options. See, e.g., http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in-2014/ http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in... - it doesn't seem to have been a big issue on the multi-platform projects I've worked on.)

by to3m 12y ago

shmerl 12y ago

I don't mean it won't be used. You are right, for example PS4 uses its own PSSL. But it's still a failure, because it's bad for developers who have to support multiple APIs and bad for users who likely won't get some titles for their platform because developers have no resources to support multiple APIs.

MBCook 12y ago
> But it's still a failure, because it's bad for developers who have to support multiple APIs and bad for users who likely won't get some titles for their platform because developers have no resources to support multiple APIs. That doesn't make it a failure, that makes it something you don't like. This could easily be very big. If it helps developers make faster/better looking games on iOS they'll do it, especially if it's supported by middlware (since most devs probably don't make their own engine). It that happens to make it harder to port games to Android (or at least get them to look as good), so much the better for Apple.
- shmerl 12y ago
  I don't like it for a reason that it multiplies exclusive titles. I consider it a failure. Normally authors should aim to reach the most audience, not to exclude users because they use a different OS. This API will proliferate the later.
  - MaxBarraclough 12y ago
    A failure is something which doesn't succeed in achieving its goals. We often approximate this by looking at how widely used something is. For an API, this measure seems reasonable. It has nothing to do with your views on vendor lock-in. Direct3D also causes lock-in. That doesn't make it a failure.
    - shmerl 12y ago
      Failure applies here to cross platform availability. Vendor lock is is a failure by default. > Direct3D also causes lock-in. It does indeed. That's why it also fails to be the proper portable graphics API.
      - MaxBarraclough 12y ago
        https://news.ycombinator.com/item?id=7838196 https://news.ycombinator.com/item?id=7838196 I already spelled out for you what the word 'failure' refers to, but fine, I'll try again. "Failure" does not mean "failure to please shmerl". That simply isn't the way the term is commonly used. Direct3D fails to make me a coffee, too. So what? Portability to non-MS platforms was never a goal. Neither was my coffee. It is clear that you are being deliberate obtuse to avoid conceding the point.
        shmerl 12y ago
        Failure means failure to be a portable API. Whether it's pleasing me or not is irrelevant. I explained the context of what I was discussing above.
interpol_p 12y ago
It's not a failure. It's an option for developers who are constrained by the fundamental performance impact of a generic OpenGL layer when it sits between you and the hardware. The reason this is good is because it's platform specific, so it can make assumptions about hardware that Apple is in full control of. I'm sure the big engines will just support multiple code paths where needed. And any existing developer has the option to stick with GL.
to3m 12y ago
Three things I suppose, coming at it from having worked on medium-to-largeish game development efforts: 0. Graphics APIs come far down the list of things people think about when planning a project. Platform support (or lack thereof) is driven by other concerns. It's a business or political decision, based on platform popularity (hence my original comment), not a technical one. Options for handling a skill shortfall include hiring more people or paying somebody else to do it. 1. Going purely by revenue and ability to attract new fanboys to the system, the bulk of development resource supply is not actually terribly interested in cross-platform graphics APIs. People using graphics middleware will use graphics middleware. Developers writing their own technology (and the people writing the graphics middleware) would actually rather have N simpler APIs for N platforms than a single complicated one that tries to support everything. That is then pretty much everybody in this space covered. (OK, yes - Direct3D11 is not especially simple, though I think it's simpler than OpenGL. But Windows is kind of popular. See point 1.) 2. The bulk of your average game's code is non-graphical, and the vast majority of the graphics code is not API-oriented or is shaders. (So, more shader languages is not a good thing, but you have options. See, e.g., http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in-2014/ http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in... - it doesn't seem to have been a big issue on the multi-platform projects I've worked on.)