3 ms·

most companies have and will just port it to different platforms, using the api that gives them the most performance. It's hardly lock-in

by cobalt 10y ago

shmerl 10y ago
> most companies have and will just port it to different platforms, using the api that gives them the most performance Yes, when they have a choice and resources. It's not even the case here. I.e. it's not like developers simply prefer lock-in when dealing with some of the walled garden platforms. They simply have no choice - the likes of MS, Sony and others don't leave them that choice. It's not a discussion on technical merits. You could use your logic if developers could actually choose.
- dmytroi 10y ago
  Of course they do, but under NDA, just ask. OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own if you REALLY need to (really is when your 1kk+$ budget game will fail just because there is an engineering problem). And if you don't have resources to ask/communicate than just use something like https://github.com/bkaradzic/bgfx/ https://github.com/bkaradzic/bgfx/ which is an awesome API agnostic rendering library.
  - shmerl 10y ago
    > OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own What would be the point for them to use the benefit of cross platform API, if they need to write their own? It won't be any cheaper than using the existing lock-in.
    - dmytroi 10y ago
      So first you develop your game for Windows on DirectX, and than you make a port to OSX/iOS/Android using OpenGL, and than if you're lucky you make a port to XBox and PS4, maybe WiiU. Graphics pipeline rendering code is really small and simple part of any game, usually in big games you do have different render code for different GPU series or/and platforms, but it's much smaller in comparison with everything else. What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages.
      - shmerl 10y ago
        > What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages. Those solutions aren't really ready yet: https://github.com/KhronosGroup/glslang/issues/200 https://github.com/KhronosGroup/glslang/issues/200
        dmytroi 10y ago
        I might be harsh to say it, but current vulkan/spir-v tooling is more like a toy than production ready. If one need to convert HLSL to GLSL then one probably will use something like https://github.com/James-Jones/HLSLCrossCompiler https://github.com/James-Jones/HLSLCrossCompiler and IIRC one place just used advanced macros magic to make HLSL and GLSL from the same source code :)
        shmerl 10y ago
        > but current vulkan/spir-v tooling is more like a toy than production ready. Yes, that's what I meant too. It's not ready (translation to SPIR-V from HLSL). GLSL → SPIR-V should be in better shape.

most companies have and will just port it to different platforms, using the api that gives them the most performance. It's hardly lock-in

by cobalt 10y ago

most companies have and will just port it to different platforms, using the api that gives them the most performance. It's hardly lock-in

shmerl 10y ago

> most companies have and will just port it to different platforms, using the api that gives them the most performance Yes, when they have a choice and resources. It's not even the case here. I.e. it's not like developers simply prefer lock-in when dealing with some of the walled garden platforms. They simply have no choice - the likes of MS, Sony and others don't leave them that choice. It's not a discussion on technical merits. You could use your logic if developers could actually choose.

dmytroi 10y ago
Of course they do, but under NDA, just ask. OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own if you REALLY need to (really is when your 1kk+$ budget game will fail just because there is an engineering problem). And if you don't have resources to ask/communicate than just use something like https://github.com/bkaradzic/bgfx/ https://github.com/bkaradzic/bgfx/ which is an awesome API agnostic rendering library.
- shmerl 10y ago
  > OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own What would be the point for them to use the benefit of cross platform API, if they need to write their own? It won't be any cheaper than using the existing lock-in.
  - dmytroi 10y ago
    So first you develop your game for Windows on DirectX, and than you make a port to OSX/iOS/Android using OpenGL, and than if you're lucky you make a port to XBox and PS4, maybe WiiU. Graphics pipeline rendering code is really small and simple part of any game, usually in big games you do have different render code for different GPU series or/and platforms, but it's much smaller in comparison with everything else. What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages.
    - shmerl 10y ago
      > What's big and bulky - shaders themselves, but there are solutions to translate them between different available languages. Those solutions aren't really ready yet: https://github.com/KhronosGroup/glslang/issues/200 https://github.com/KhronosGroup/glslang/issues/200
      - dmytroi 10y ago
        I might be harsh to say it, but current vulkan/spir-v tooling is more like a toy than production ready. If one need to convert HLSL to GLSL then one probably will use something like https://github.com/James-Jones/HLSLCrossCompiler https://github.com/James-Jones/HLSLCrossCompiler and IIRC one place just used advanced macros magic to make HLSL and GLSL from the same source code :)
        shmerl 10y ago
        > but current vulkan/spir-v tooling is more like a toy than production ready. Yes, that's what I meant too. It's not ready (translation to SPIR-V from HLSL). GLSL → SPIR-V should be in better shape.