Oh, sorry..Originally Posted by Zengar
For the webmaster, can we have some updates on that topic please?
Oh, sorry..
For the webmaster, can we have some updates on that topic please?
You clearly need to actually read the last 4 newsletters. Coupled with the info from SIGGRAPH, this should bring you up to speed with the publicly available information, which answers 80% of your questions.That means the glGenTextures, glBindTexture,glTexImage2D and and all texture functions will be changed of current version of GL?
Did you really expect them to give you a draft of their GL 3.0 specification?I've asked for a draft to have a clue of how things will work and write preliminary implementation/design in existing code...
But nothing went.
I've also been interested in that. I prefer to work in C++, and language bindings are always depressingly incomplete. It would be even better if we had some sort of Khronos-sponsored binding, so that we didn't have to worry about its long-term suitability (or rather its lack thereof).
However, I've never heard of these .spec files you're talking about. Are they a solution for easing language bindings? Can you provide a link or something?
The details are trivial and useless;
The reasons, as always, purely human ones.
Huh?I prefer to work in C++, and language bindings are always depressingly incomplete.
Last I checked, both GLee and GLEW worked just fine and were quite complete. Or are you simply talking about using the bare .lib that only loads GL 1.1?
They're just the specification in a format that's reasonably parseable. That way, you could automate the generation of header files, and potentially loading code.However, I've never heard of these .spec files you're talking about.
Sorry, I guess I wasn't clear; I'm not talking about extensions at all. I'm talking about using C++ wrappers for OpenGL's C API. In one of the newsletters, they mention that they're going with a C API, even though it can be kind of verbose, for ease of implementation, and that they expect language bindings to pop up pretty quickly. However, unless the ARB plans for these bindings, I expect they'll be sub-par.
I was sort of hoping for an example of this being done successfully. It seems like there would be some pitfalls in making such language bindings automatically, but if it could be done, that would be great.They're just the specification in a format that's reasonably parseable. That way, you could automate the generation of header files, and potentially loading code.
However, we've already figured out that we're talking about different things. I could easily imagine how it could be successfully done for extensions. APIs are a bit more difficult.
The details are trivial and useless;
The reasons, as always, purely human ones.
... so?However, unless the ARB plans for these bindings, I expect they'll be sub-par.
I mean, worst case is that you use the C API directly, right? It's not like you're losing any functionality here.
Right now, the ARB is 1.5 months late on the spec, with no spec date looming in the immediate future. Wanting the ARB to write up a C++ wrapper over the C API at this point is a little too forward thinking.
Yes it was very optimistic of me to ask that the community get a -draft- of *Open*GL 3.0 since we didn't get the promised specifications.
At least we could plan/design with a fairly good idea of how things will work, because at this stage, I somewhat doubt there will be drastic changes.
(And anyway it would be a draft, so we would know it's subject to change.)
Also we (software developers) could discuss the draft on the forums to give Khronos some feedback about it...
-* So many things to do, so little time to spend. *-
The future version of OpenGL will be no specs after 3.0 or the GL3.0 will become the latest version of the Graphics API with standard specs?with no spec date looming in the immediate future.
The main difficulty is the age of the .spec files. There is a lot of stale cruft in there, plus a few genuine mistakes, but all in all they are pretty parseable, if you stick to a straight port of the C API. For more advanced functionality (actual enumerations, function overloads) things become more interesting, but the result is much more pleasing. A code snippet from the C# bindings included in OpenTK:
(yes, these are automatically generated, source code available)Code :GL.Clear(ClearBufferMask.ColorBufferBit | ClearBufferMask.DepthBufferBit); GL.MatrixMode(MatrixMode.Modelview); GL.LoadIdentity(); Glu.LookAt(0.0, 5.0, 5.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0); GL.BindBuffer(Version15.ArrayBuffer, vertex_buffer_object); GL.VertexPointer(3, VertexPointerType.Float, 0, IntPtr.Zero); GL.BindBuffer(Version15.ElementArrayBuffer, element_buffer_object); GL.DrawElements(BeginMode.Triangles, shape.Indices.Length, All.UnsignedInt, IntPtr.Zero);
Bindings like these are possible for almost all high-level languages, C++ included, but we do need the .spec files to generate them. This is why I was asking if the specs will be publicly available in their 'raw' form.
I think you misunderstood what I was saying.The future version of OpenGL will be no specs after 3.0 or the GL3.0 will become the latest version of the Graphics API with standard specs?
I was saying that the most recent info from the ARB did not give us even a semi-firm date for when to expect the GL 3.0 specification. We can guess by the end of the year, but that's only a guess.
There will be post 3.0 specifications as well; the ARB still has some post 3.0 plans.
Posting Permissions
