I feel like we need to open a betting pool.

In the meantime, they could bother to add DSA to the much simpler ES API? That would be helpful.

I am making a game in OpenGL "for fun" right now. I have absolutely no need for this, as I'm already running at about 2000 fps when vsync is off.

I hope they don´t turn it into some AAA-game only api, but keep some higher level stuff for us who just want to draw stuff to the screen.

it sounds like your using the very deprecated fixed pipeline.

edit: if you want to just draw stuff to the screen, then you should be using an highlevel framework such as SDL/SFML/etc, or engine such as unity/UE4/etc, and let them manage the low-level stuff for you.

I am making a game in OpenGL "for fun" right now. I have absolutely no need for this, as I'm already running at about 2000 fps when vsync is off.

I hope they don´t turn it into some AAA-game only api, but keep some higher level stuff for us who just want to draw stuff to the screen.

it sounds like your using the very deprecated fixed pipeline.

edit: if you want to just draw stuff to the screen, then you should be using an highlevel framework such as SDL/SFML/etc, or engine such as unity/UE4/etc, and let them manage the low-level stuff for you.

Not correct, I started with the game partly because I wanted to learn what's new in OpenGL. Last time I tried it was about 10 years ago. At that time I was of course using the fixed function pipeline.

I am not done by any means, but I tried doing it the way "experts" recommend. Avoid draw calls, avoid texture switching, use texture atlases etc etc.... and I get .... 2000 FPS -which is way overkill, even if it will likely be lower by the time I add all the effects I want.

I do not want to use an engine because 1) It would defeat the point of using OpenGL for learning purposes and 2) I know exactly what the game will be like and prefer to just do it myself (more fun) rather than spending learning an engine someone wrote (booring) and trying to bend it to my will.

I do miss the fixed function pipeline for certain things, simple things like making lines in a GUI for example. It's feels clunky to do that now.

The thing is if you want to learn OpenGL for any professional reason (such as going into the games industry) then you'll need to learn the new API because, unless they screw up fantastically, it'll look very much like the existing APIs in terms of how it fits together.

To be honest, aside from data hazards, a Mantle style API should be simpler for people to learn and use; iirc the Mantle API is somewhere in the region of 50 functions, the 4.5 'quick reference card' for OpenGL is now (apparently) 13 pages, even allowing for some of that being GLSL stuff that's still pretty damned big.

End of the day all rendering boils down to is 'use these inputs and this set of programs to write to these outputs' - even if you strip away all the more diagnostic/query stuff GL as it stands is still massive in that regard, so a simpler API will be better.

I am making a game in OpenGL "for fun" right now. I have absolutely no need for this, as I'm already running at about 2000 fps when vsync is off.

I hope they don´t turn it into some AAA-game only api, but keep some higher level stuff for us who just want to draw stuff to the screen.

it sounds like your using the very deprecated fixed pipeline.

edit: if you want to just draw stuff to the screen, then you should be using an highlevel framework such as SDL/SFML/etc, or engine such as unity/UE4/etc, and let them manage the low-level stuff for you.

Not correct, I started with the game partly because I wanted to learn what's new in OpenGL. Last time I tried it was about 10 years ago. At that time I was of course using the fixed function pipeline.

well then, i stand corrected on my assumptions, i apologize. I'll simply defer back to Xycaleth's answer, that this does not mean openGL itself is going anywhere, and will likely be supported for many many years to come, so it's not like you need to redesign your game to use this potentially new api.

I am absolutely not learning OpenGL for any purpose other than brain exercise, so I guess I can't say I care really hard either way what happens with OpenGL at this time, as long as my programs still continue to work on GPUs in the future.

This is exciting... but they better damn not "longs peak" this again! This is their last chance to finally fix cross-platform gfx programming and regain equal quality with D3D...

To be honest, aside from data hazards, a Mantle style API should be simpler for people to learn and use; iirc the Mantle API is somewhere in the region of 50 functions, the 4.5 'quick reference card' for OpenGL is now (apparently) 13 pages, even allowing for some of that being GLSL stuff that's still pretty damned big.

The mantle documentation is also extremely readable, which in comparison makes the OpenGL specification document look like hieroglyphics...

You should never forget that Khronos is a committee of committees. As such, anything it produces is going to have all the hallmarks of something designed by committee. Mostly, it will never leave you without something to complain about.

Even AMD is on board...maybe they give up Mantle for OpenGL5 or at least make it easy to crossdevelop? The only missing is of course MS. But nowadays

this shouldn't bother anyone anymore.

Interesting, if it makes OpenGL apps faster and easier to develop, then bring it on. Well if they wouldn't, OpenGL would certainly lose ground against the other new

competitors.

Even AMD is on board...maybe they give up Mantle for OpenGL5 or at least make it easy to crossdevelop? The only missing is of course MS. But nowadays

this shouldn't bother anyone anymore.

Interesting, if it makes OpenGL apps faster and easier to develop, then bring it on. Well if they wouldn't, OpenGL would certainly lose ground against the other new

competitors.

Sorry to pop your idealism here, but there's every reason to have a very low level of confidence in Khronos actually delivering.