News for hackers. Stuff that matters.
Re:Vulkan Tutorial by pjmlp on Monday July 18, 2016 @11:38AM (#12115693)
No, indies will demand it.

AAA studios are doing quite fine with the current API that are even lower than Vulkan.

Indies with FOSS background seem to have a hard time to grasp how the games industry works in terms of IP, technology stacks and outsourcing for platform ports.

Re:Vulkan Tutorial by shmerl on Monday July 18, 2016 @11:42AM (#12115724)
That will change when pressure will grow. Same as ActiveX was driven out by standard Web technologies. Lock-in freaks will try to resist, but they can only delay it.

> No, indies will demand it.

> AAA studios are doing quite fine with the current API that are even lower than Vulkan.

Meaning of "AAA" is totally mixed up, so there is no point to use this term without explaining what you mean. Indie might mean independent indeed, but what AAA stands for is completely ambiguous. You might mean projects with big budgets, but they can be independent as well (Star Citizen), so you can't use it as some universal category. For the reference Star Citizen is going to use Vulkan.

Regardless of what "AAA" is supposed to mean, they will use whatever will cut their costs to do the job well enough. And cross platform options surely will, if they'll be available.

Re:Vulkan Tutorial by khedoros on Monday July 18, 2016 @06:20PM (#12118369)
> Meaning of "AAA" is totally mixed up

It makes me think of a big budget game made by a company that makes big budget games and primarily publishes them through mainstream channels. It makes me think "opposite of Indie". I don't think that there's an indisputable, unambiguous definition of either term.

[dead]
Re:Vulkan Tutorial by shmerl on Monday July 18, 2016 @01:00PM (#12116347)
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.
Re:Vulkan Tutorial by cobalt on Monday July 18, 2016 @01:31PM (#12116603)
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
Re:Vulkan Tutorial by shmerl on Monday July 18, 2016 @01:46PM (#12116743)
> 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.

Re:Vulkan Tutorial by dmytroi on Monday July 18, 2016 @06:42PM (#12118443)
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.

Re:Vulkan Tutorial by shmerl on Monday July 18, 2016 @08:45PM (#12118845)
> 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.

Re:Vulkan Tutorial by dmytroi on Tuesday July 19, 2016 @04:11AM (#12120502)
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.

Re:Vulkan Tutorial by shmerl on Tuesday July 19, 2016 @11:48AM (#12122415)
> 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

Re:Vulkan Tutorial by dmytroi on Tuesday July 19, 2016 @04:02PM (#12124414)
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 :)
Re:Vulkan Tutorial by shmerl on Tuesday July 19, 2016 @06:16PM (#12125369)
> 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.