You do all realise ‘deprecated’ doesn’t ‘removed’ it just means ‘expect this to vanish at some point’ a fact which has worked so well in the past and hasn’t at all lead to bloated APIs… like, say, with Java.
While something is in you HAVE to support it because while it exists, in any form, people WILL use it.
So how long til we DO get the stuff we were promised? I had a feeling of being let down 
I’ve been looking at the spec and as long as you use a full GL3 context it looks like you do get a very streamlined API, there is a hell of a lot of fixed-function stuff that you can’t use in favour of shaders.
OK, so there is no object based API, which I am gutted about, but is the spec really that bad? At least now they can deprecate and eventually remove stuff.
Every way I look at it, this is a massive improvement over 2. What I’m annoyed about is the way the ARB haven’t told us ANYTHING for a year and then don’t deliver the stuff they did tell us about. But I’m annoyed with the process, not the final spec.
From the spec: “it is possible to create an OpenGL 3.0 context which does not support deprecated features.” So if you want it to, it can remove the deprecated features.
Are the SM 4.0 features (NVidia GEForce 8+) standard in OpenGL3 or do I still have to write a million different render paths?
Any chance of a parallel specification document that has all the deprecated features removed, so we can see what is left over?
Even if you can create a context, that does not support the deprecated features, that doesn’t make drivers less complicated and therefore less error-prone. The very idea of the whole rewrite (which we didn’t get, of course, so the idea of less error-prone drivers was ditched too, i guess).
No, they are not.
It seems that they are “reserved” as usual GL_ARB_xx extensions: http://opengl.org/registry/
see items 47. GL_ARB_geometry_shader4 and down.
[censored] that is stupid.
Time to call Intel and see what they are planning with Larabee.
I knew the news would be bad. You don’t have someone cut off communication like they did and then get good news afterwards.
Time to call Intel and see what they are planning with Larabee.
You keep saying that, but Larrabee will still be using the standard APIs for graphics work.
They are implementing them but I think the idea is you can write your own as well. Otherwise there would be absolutely no point.
You seem to be misunderstanding that Khronos/ARB does not make implementations, but specifications. Putting OpenGL into seperate dlls is an implementation detail and beyond the scope of the ARB.
Why don’t you just run us over with a tank if our protestations are so unpalatable?
The ARB are looking more and more like a communist dictatorship today.
As for someone, who has been watching the progress of OpenGL for many years even thought I haven’t done any serious 3D graphics programming for some time now, OpenGL 3.0 is a bit dissapointing for me too.
Like it has been said in these threads before, OpenGL is in need of complete clean-up of the API. I was looking forward for the new object system and fixing a lot of ancient legacy like the plan seemed to be in the beginning, but alas, we did not get that. A hope is that the new upcoming versions will eventually fix these problems, but OpenGL is really lagging behind Direct3D now.
Why don’t you just run us over with a tank if our protestations are so unpalatable?
The ARB are looking more and more like a communist dictatorship today. [/QUOTE]
Replies like these are childish and unnecessary. Please try to master your emotions.
I guess the crux of all of this is that Khronos has no interest in providing an API for game graphics. I mean, they had John Carmack onboard at one point, and then I rememeber he moved his research to DirectX, at what must have been the time this new (mis)direction came to be. If they were interested in games they would have done whatever they could have to keep him interested. John has always been a fan of MS alternatives, and it’s not like lack of interest on his part kept him away; he would use OpenGL3 if it wasn’t detrimental to his company.
So they are saying “sure, you can use OpenGL for games, if you want” but their real interests lie elsewhere. If that is what they want to do, that’s fine, but what you must understand is all the real-time developers here do not mean anything to them. They have no aspirations of high-end realtime graphics, so we should not expect it.
i can remember that we were told the ARB members were meeting 5 times per week (face to face or on the phone).
so what were they talking about?
I guess the crux of all of this is that Khronos has no interest in providing an API for game graphics. I mean, they had John Carmack onboard at one point, and then I rememeber he moved his research to DirectX, at what must have been the time this new (mis)direction came to be. If they were interested in games they would have done whatever they could have to keep him interested. John has always been a fan of MS alternatives, and it’s not like lack of interest on his part kept him away; he would use OpenGL3 if it wasn’t detrimental to his company.
So they are saying “sure, you can use OpenGL for games, if you want” but their real interests lie elsewhere. If that is what they want to do, that’s fine, but what you must understand is all the real-time developers here do not mean anything to them. They have no aspirations of high-end realtime graphics, so we should not expect it.
Khronos OpenGL ARB is a community of member parties with different interests. Sometimes the interests may collide. This time we see that the outcome of these colliding interests was not to radically push the API forward, unlike the original plan was. From a game developer’s point of view, a pity.
My understanding is that Larrabee will have a software OpenGL implementation on top of their native interface, but you could program to the native interface or use a 3rd party library that is just as ‘to the metal’ as the OpenGL implementation.
even from a researchers point of view a pity… such a big pitty to lookout for the only valid alternative.