Is OpenGL dead? Will there be a mid-level C-based framework to replace it?
>>55584278
innit being replaced with Vulkan?
>>55584278
you mean Vulcan?
>>55584288
>>55584290
Vulkan is a low-level alternative, not a direct replacement.
>>55584300
I mean, obviously it's not a drop-in replacement, but isn't it mean to supersede it?
Like if you want to use a free graphics API, you'd use Vulkan instead of OpenGL, right?
>>55584333
Vulkan is significantly lower-level than OpenGL; ergo, they have different use-cases. In other words, an OpenGL replacement would be a framework that works over Vulkan.
>>55584358
Oh, sorry, I didn't realize.
Doesn't look like it's going to have any replacement in that sense.
DX12 is also a low-level API, so I guess that's just the direction the market is heading.
>>55584333
Nope. OpenGL and OpenGL ES aren't dead or being killed off by Vulkan.
>>55584405
that's what they're leading you to believe. they'll cotnue 'supporting' opengl/es like nvidia continue to support fermi cards
>>55584278
I sure hope not. I've invested so much time into learning it.
>>55584405
The people who worked on OpenGL are moving on to Vulkan (likely most of them already have).
OpenGL 4.5 was 2 years ago.
Vulkan was previously named the "Next Generation OpenGL Initiative" (glNext).
It's pretty clear that's what's happening.
While I wouldn't say that OpenGL or ES are actually dead yet, I'd say they've got one foot in the grave.
>>55584414
>they'll cotnue 'supporting' opengl/es like nvidia continue to support fermi cards
Fuck nVidia tbqh for doing this. Fermi are still very capable cards able to play any game today on medium to high settings at 1080p. The 5xx series are the Sandy Bridge of graphics cards.
>>55584455
OpenGL support will continue for a long time. The standard probably won't advance (much) in that time, but legacy applications will need to work. I suspect that OpenGL will turn into a software implementation working above Vulkan in the future.
Beyond that, there is significant reason to want a mid-level framework, like something along the lines of OpenGL or SDL, with which to write applications. Some indie games and certainly a lot of non-game applications would desire a mid-level framework like that.
>>55584442
Your skills will translate to Vulkan. The main problem is level of effort; programming with Vulkan is simply more difficult and time-consuming than using OpenGL, unless you have a project so large that programming effort is not a concern.
>>55584474
They're still getting monthly game ready driver updates though
>>55584414
momentum. opengl will continue like a panamax cargo ship with power loss. it's used everywhere.
>>55584533
>The standard probably won't advance (much) in that time, but legacy applications will need to work
Well naturally, I'm not saying they're going to cut the cord, they're just going to dim the lights.
>Beyond that, there is significant reason to want a mid-level framework
I believe Vulkan devs plan for that gap to filled in by 3rd party libraries/tools/frameworks.
So eventually you will get your framework, it's just going to be from someone else.
>>55584533
They will somewhat translate but its time waste for me. I spent good amount of time mastering OpenGL. In fact, I was implementing a AZDO game engine using OpenGL 4.5 (DSA). Plus, I have a Fermi card so I got fuck in the ass by nVidia because they outright lied that they'd support Vulkan on them.
It's also interesting to note that AMD is much better at Vulkan than nVidia and reverse is true for OpenGL. nVidia has invested tons of money and R&D in OpenGL. If their poor Vulkan performance continues, maybe they'll try to subvert Vulkan in some way.
>>55584278
This is why 3D engines exist.
>>55584617
But then was the engine?
>>55584659
millions of lines of code and thousands of gallons of codemonkey sweat to act as glue
>>55584617
That's only useful for games (and even then, not all games) and certain types of applications (like visualization software). Suppose you're writing something in C or C++ and need to render something (like a model of the earth or a car or whatever); the most sensible solution is to link in a framework like SDL or write it in OpenGL, since the overall impact on the program architecture is small. That is absolutely not the case for graphics engines.
>>55584617
How do they just "exist"? Someone has to write them you idiot.
>>55584474
>The 5xx series are the Sandy Bridge of graphics cards.
That's the first gen of GCN cards
>>55584358
>an OpenGL replacement would be a framework that works over Vulkan.
Sometime in the future, OpenGL implementations will probably be on top of Vulkan anyway.
>>55584743
So? I don't give a shit who writes it, can't be bother to spend the next decade writing a physics engine for my 2d platformer, so fuck off.
>>55585799
>physics engine for 2d platformer
>decade
How fucking Pajeet are you?
>>55585799
What the point in making platformer if you don't make your own buggy physics?
>>55584574
and a 9700 pro gets drivers that doesnt mean amd is actively improving its perfomance...
same goes for nvidia since the whole gimping fiasco they decide to just move them into legacy and call the day
its their users fault that keep buying their cards each year
>>55584743
Empirically it is demonstrable that some people write engines and that they do, in fact, exist.
