I meant to say that it could be added to GLU.
The deprecated functions are mostly used by old software that is statically linked to glBegin etc. in OpenGL32.dll.
Most of this software is no longer being updated so there is no way to make it call a separate library.
People could still be using software that does this in 5 or 10 years, hence the drivers need to support old functionality so someones favorite old game or $1000 CAD program wont suddenly stop working.
You could create an OpenGL32 substitute that creates a VBO from the old functions before passing them on to the real OpenGL32, but it would have to be placed in the directory of every old application.
The only implimentation that would always work without manual intervention is if the GPU drivers call this common library.
ie. Old program calls glBegin in OpenGl32, which calls glBegin in the driver, which calls glBegin in the deprecated features DLL, which builds a VBO and calls driver functions to load it.
More than likely the vendors will simply do their own version and include it inside the driver.
Once they have a fully debugged fixed-function to modern VBO+shader library of code, then there is really no need for them to ever touch it again.
Hence the existance of fixed-function support should not effect the quality of future OpenGL3 code.
Actually it’s really not that big of a problem as it’s made out to be. The 3.0 spec, while it was a HUGE disappointment, being that is was basicly an addition to the 2.1 spec. It did bring with it the deprecated features, and it’s about time. Because they didn’t do this back when 2.0 was first released they already shot them selves in the foot. No one should have been using glVertex in 2.0 let alone 3.0.
And as far as drivers go… deprecation shouldn’t be an issue. It’s completely different than DirectX in drivers support. Microsoft makes the API and the drivers. OpenGL isn’t made by any one company but a group, and that group takes no responsability for the drivers. So nVidia and ATI are left to them selves to replace the OpengGL32.dll with there version. (In case you didn’t know the OpenGL32.dll that ships with Windows is actually a D3D wrapper.)
So basicly if Khronos release 3.1, dropped all the deprecated functions added objects, and said deal with it… (Well, we all would be worlds happier) and nVidia etc would be left doing what they’re already doing. Writting the OpenGL32.dll for their cards. All they really have to do for back wards compatability is make glBegin, glVertex, glEnd build a VBO and use that. (Along with a few other things…)
Really it’s not a big issue if key people would just step up a do it. If this API isn’t brought current fast, card manufacturers are going to let their support slack off even more. And it sucks already, performance tests between OpenGL and D3D almost hands down show D3D in the lead by signifigant margins.
*Edited to fix wording
It’s not so much the functions/features themselves but the tenuous scaffolding in the spec that underpins the maze of interactions and undermines efforts to move the API forward (in terms of both ease of implementation and presenting the user with a clear, singular path to speed).
It’s my belief that you will perceive progress in this area with GL 3.1.
yay for misinformation \o/
The NV and ATI/AMD drivers do NOT replace OpenGL32.dll; they instead install an ICD which the calls are directed to when you create a context which uses that perticular ICD.
OpenGL32.dll has only started being a wrapper around D3D since Vista in order to bring 1.4 compatibility as standard. Before that it was nothing more than an OpenGL1.1 software implimentation which has been around practically forever.