Hacker News Reader

Comment by shmerl | Hacker News Reader

I see you still are a fan of lock-in. Calling it "fine" and saying that's how it's supposed to be is not helpful. "Industry" which thinks backwards doesn't need to be shown as an example. It's not the "industry", it's monopolistic participants who use lock-in to control the market. Progress is driven by competition, not by monopolistic lock-in stagnation.

View on HN

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

> 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.

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/ which is an awesome API agnostic rendering library.

> 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.

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.

> 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

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 and IIRC one place just used advanced macros magic to make HLSL and GLSL from the same source code :)

> 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.

Reply on news.ycombinator.com