I know C++ API for OpenGL exists (GLT OpenGL C++ Toolkit download | SourceForge.net is one of them). I think OO API is easier to use than C.
You mean the api in C++ or in C just like it is but with OO modeling?
i doubt it if c++ will be used for an API like OGL. but if for some reason such a thing is done, it will be a major motivation for me to stop using OGL!
making OpenGL OO would break the backwards compatability and that is one of the main goals of OpenGL in general and the 2.0 release
OpenGL already is object oriented. glBindTexture. 'nuff said.
Not to mention that the way the C api is formed makes it possible to use other languages in a simple way (in windows the calls are stdcall declared and not even pure C standard), C++ makes this a bit harder since the internal structure of the classes must be the same between languages, which they arent. thats why microsoft used COM instead for DirectX. COM defines the interfaces on bytelevel and you are sure that different languages that supports COM have their calls arranged in the same way.
What i would like to see is a common wrapper for .net sooner or later. Now that bigger companies ( was it novell?) are putting effort into MONO ( the unix implementation of the CLR engine ) we might get executables working on both *nix and windows… but since directX arent ported ( and we dont want to use that 
) we should have the .net binding… and a common one on all .net runtimes.
come on guys!
i chose to use OGL and other APIs because they are “cleaner” than micro$~1.oft 's counterparts and because they are cross-platform APIs.
we all know that .net SUCKS and the whole idea behind it and other M$ crap is to force us to use it.
i like linux (don’t have experience in other *nix systems) because i am free to choose whatever i like as far as it concerns programming.
(god, i hate writing WinMain, i want int main(void) )
i agree with kawasakis. if OGL becomes like DirectCrapX i will certainly stop using it.
well, (i am going a little OT now) currently, OGL begins to look like DX (vertex buffers etc) in terms of functionality, which is something i am against with, but since HW guys decide to pledge allegiance to M$ crap, what can we do?
and why does M$ sneak its nose in everything? leave the world alone! go home! get out of the ARB!
sorry, i may be overeacting. these are my thoughts. i hope i am not mistaken for a troll or anything else.
finally, i hope SGI (and generally the ARB which controls OGL) will take into serious consideration the future of OGL and present something revolutionary (like it did in the past with IrisGL and OGL), without taking into account M$ or its java-bad-implemented-clone .net
-poutsoklis
Yes, you guys are right
OGL in C++ may look like DirectX and, we could loose performance and compatibility
I think we have’t anything else to say
[This message has been edited by XaL-S (edited 12-15-2003).]
I do not thing so it is the good point of view.
I think keeping the old and good structure of opengl interface is needed. But it does not prohibites the developing of a alternate OO interfaces. Why would it be a problem for you? YOU DO NOT HAVE TO USE IT!
And i think, you are mixing a mistique hate of Microsoft with this all - rather than thinking in facts (this is my perspective and sorry if this hurts).
I am using several different programming tools (Borland - Microsoft, etc.) and languages. Yes, Microsoft definitely ‘stole’ a lot of ideas from others, but: everyone do the same; and it makes VS .NET very PRODUCTIVE. It is possible that you do not agree with the ways they reach this, but they are efficient. The productive tools makes the business becoming faster and better and a healthy business provides us new softwares, hardwares, foods, beers… and money you CAN NOT live without.
On the other hand you do not have to use it too.
Finally about the OO.
The OO paradigm is very close to us - humans. It looks, we think in objects.
Using the paradigm’s abstraction level when planning and developing a project has unquestionable advantages.
The deep meaning of it all is touhgt in (i think) every university about computer science.
Well before reading this thread I sent
a new post in coding: Advanced
if there is a wraper for the API that
manipulates it as a C++ stream.
I think that it could be good alternative
to C calls, and It wouldn’t have much
performance impact, as iostream is not
much heaviear than FILE, and ofer some
abstraction…
well, (i am going a little OT now) currently, OGL begins to look like DX (vertex buffers etc) in terms of functionality, which is something i am against with, but since HW guys decide to pledge allegiance to M$ crap, what can we do?
Yeah. Convieniently forget the fact that VBO is vital to the long-term survival of the OpenGL API. Or the fact that, until VBO, there was no cross-platform solution to vertex transfer that would provide optimal, or even moderately close to optimal, support.
get out of the ARB!
They already did. Like, early this year or late last year.
I think keeping the old and good structure of opengl interface is needed. But it does not prohibites the developing of a alternate OO interfaces. Why would it be a problem for you? YOU DO NOT HAVE TO USE IT!
Having multiple interfaces for the same system is a nightmare, and is generally considered bad design.
In general, while I wouldn’t mind a total re-write of the OpenGL API, I doesn’t make sense to go to C++. As it has been pointed out before, C++ .lib’s aren’t cross-compiler portable, let alone cross-platform. And .dll’s aren’t either. You have to go to an abstraction like COM or .NET in order to get truely cross-platform object-oriented libraries. It just isn’t worth it for the relatively minimal gain.
huh?
COM cross-plateform??
You mean, because of it’s dependance on the Windows registry I suppose??
Having multiple interfaces for the same system is a nightmare, and is generally considered bad design.
The problem with the c++ .lib-s is true, unfortunatly.
You have right with the comment above. I tought of a parallel system - an other half-implementation based on OGL2. Half, because it could share the inner layers with the original implementation.
Of course, it can be a nonsense. Just an idea about things i can not discover in deeps.
(Sorry about possible grammar mistakes
But OpenGL already IS OO, as said above.
Nuff said 
You can easilly make your own opengl class and call each function from there aswell.
Like: gl.BindTexture2D(…)
What is the problem?
operator overloading?
-You can do it anyway.
Function overloading?
-As above.
I think this OGL is/isn’t already OO stuff really misses the point. Even in the worst case, OGL is one big stateful object. That doesn’t mean we can’t make better use of C++ compilers to improve coding efficiency.
The things that would make OGL better (IMO) through a more C++ish API are:
-
Use the compiler to catch type errors. Migrate #defines to typed range values or enums so no more putting the wrong value in the wrong paramater, plus a good dev environment can now start giving you hints and typing accelerators.
-
Add standard types for vectors, matrices, etc… We all do this anyway, but why not standardize so we can drop all the unsafe pointer casting with OGL calls? Makes for cleaner code.
-
Polymorphism is good, IMO. I don’t see what’s wrong with overloading glVertex as long sa it’s not virtual. Also reduces the number of parameters on certain calls where type/size must be supplied. Fewer parameters == faster, cleaner.
-
Handles do make more sense than raw pointers for this kind of architecture, but having handles exposed as uints requires extensive unnecessary validation. Rather, add “smart” pointers for things like texture objects (that may just wrap those handles, but at least add a notion of type) and VBOs and have the pointers self-validate.
-
Whether the syntax should be OOish smart_ptr->action or action(smart_ptr) is a matter of taste, but as long as the pointer is made safe, why not do both? Inlines make it virtually free either way.
-
This also gives us an easy route to derive our objects from OGL base types. How many times do we have to write the same texture wrapper class for different companies?
Now, things I don’t think we need from the OO world:
-
Use virtual functions only sparingly, if at all. Things like matrices are better off without it and we don’t want the extra pointer hanging off our nicely aligned structs. Virtual delete is only needed for classes that dynamically allocate resources.
-
Don’t need COM, CORBA, or any other delegated dispatch mechanism. Abstracted interfaces are fine, but only if they don’t change and DX drives me nuts with versioning.
-
Keep inheritance low. Avoid multiple inheritance at all costs. No need for base glObject class here. Keep it simple and clean.
Honestly, I think abuse of #3 is why most people who hate OO feel that way. But it can be done right.
Avi
You are aware that any discussion of actually using C++ is, basically, useless, correct?
The primary reason that C is used as the basis for so many libraries is because you can compile it on one compiler, and the binary library can be used by other compilers for the same architecture. C guarentees this; C++, thanks in part to name-mangling, cannot.
This is the primary reason why DirectX is COM-based; it is the only way to maintain compiler neutrality, since the actual COM interface .dll is straight C.
You can make all the arguments you want about how C++ would help make OpenGL better, but none of them are important enough to override the fundamental fact that C++ is not the way to go for a library that has to be delivered as a binary distribution (as opposed to source code, which can be made compiler neutral).
Originally posted by Korval:
You can make all the arguments you want about how C++ would help make OpenGL better, but none of them are important enough to override the fundamental fact that C++ is not the way to go for a library that has to be delivered as a binary distribution (as opposed to source code, which can be made compiler neutral).
Actually, some people this board have experience writing C++ cross-platform libraries. It’s not as dire as you say.
But if all else fails, all of the suggestions above could be supplied as inlines in a standard header, even if the hard DLL entry points are all c-style declarations. You do agree that the binary distribution contains compilable header files, don’t you?
Avi
But if all else fails, all of the suggestions above could be supplied as inlines in a standard header, even if the hard DLL entry points are all c-style declarations. You do agree that the binary distribution contains compilable header files, don’t you?
Header files, yes. But these header files should absolutely not be implementation dependent. That is, downloading a driver should not update headers. Doing so is a recipe for disaster on several fronts.
For one, it makes it virtually impossible to make cross that is OpenGL implementation neutral. Inlines are inlined in a compiled binary (hence the name), and are therefore fixed at the moment of compilation.
Now, you could keep the inlines and not allow them to be platform-specific. However, then you are, basically, recreating the fundamental problem with D3D. The thing about D3D is that the user has an interface, and the driver writer has an interface, but these are not the same interface. The driver runs in Ring0, and the user doesn’t. As such, you have to trust Microsoft’s code to perform certain optimizations. This problem leads to the reason why a good VBO implementation is faster than D3D can ever be at vertex T&L. D3D is limitted by the number of draw primitive calls; OpenGL is not.
If, for example, an implementation is not allowed to write how to handle glVertex3f vs. glVertex3i, if the overloaded functions are in a header somewhere, then, at the very least, this places additional overhead in calling these functions.
In short, it’s a bad idea any way you look at it.
Consider:
void glVertex(const GLVec3f& vertex) { glVertex3f(&vertex[0]); }
void glMultMatrix(const GLMat4f& matrix) { glMultMatrixf(&matrix[0][0]); }
void glBindTexture(const GLTexture& tex) { glBindTexture(tex.id); }
and/or
void GLTexture::bind() { glBindTexture(id); }
And so on…
If that’s inlined, it should be no more cost than calling glVertex3f… directly, but adds type checking. And this is the most basic scenario. It can be done much more elegantly than this.
The vector and matrix math libraries should be inlined anyway, IMO, since the code is small and speed does matter. However, it’s also not too hard to make headers that have optional inlines (i.e., to compile the code into your application once, rather than at each invokation).
The only controversey in my mind is whether to make wrappers that call more than one OGL call internally, like say a glLoadModelView(const &GLMat4f) or a glBindBuffer on a self-describing VBO or vanilla vertex array wrapper class that manages the individual offsets and strides for vertices, colors, etc… If we only stuck to a 1:1 C++ type-safe inline function for each existing C function call, we’d have a good standard base for people to build on.
Originally posted by Korval:
Inlines are inlined in a compiled binary (hence the name), and are therefore fixed at the moment of compilation.
…the moment of compilation of your application, not the OGL core. The resulting wrapper code becomes part of your code, using whatever compiler you used. There’s no more platform/compiler dependency than there is now.
If, for any reason, you need platform or compiler-specific inlines, these can also be selected via #defines, but I doubt it would be necessary at all. Even templates (possibly, but not necessarily used for the math classes) have a standard core that works on any compiler I’m aware of.
In fact, the only #define I’d definitely expect to see would be one to test if you’re compiling in C or C++.
Originally posted by Korval:
Now, you could keep the inlines and not allow them to be platform-specific. However, then you are, basically, recreating the fundamental problem with D3D. The thing about D3D is that the user has an interface, and the driver writer has an interface, but these are not the same interface. The driver runs in Ring0, and the user doesn’t. As such, you have to trust Microsoft’s code to perform certain optimizations. This problem leads to the reason why a good VBO implementation is faster than D3D can ever be at vertex T&L. D3D is limitted by the number of draw primitive calls; OpenGL is not.
I didn’t say anything about COM or interfaces. There’s no reason we’d need to see any delegated dispatch (except for the DLL binding itself, which is unavoidable). The wrapper method I’m advocating would be as fast as the direct C-style call. And there’s even a possibility for speedups since the proper ‘consting’ of arguments is now possible – this helps the C++ compiler manage registers and temporaries better. Current OGL doesn’t distinguish between ‘in’ and ‘out’ for pointers and the C++ wrappers would actually improve that situation, among other things.
Originally posted by Korval:
[b]If, for example, an implementation is not allowed to write how to handle glVertex3f vs. glVertex3i, if the overloaded functions are in a header somewhere, then, at the very least, this places additional overhead in calling these functions.
In short, it’s a bad idea any way you look at it.[/b]
No, Korval, it’s really not a bad idea. There’s no additional overhead, no D3D-style interface issue, no cross-platform issue I’m aware of, no problem with giving a brand new backwards-compatible header for OGL 2.0 (which is what we’re talking about), and there’s nothing wrong with the idea except that it hasn’t yet been done in any official way.
It’s been done by developers for years, but I’m tired of recreating the same wheel over and over again. This is a basic issue with easy solutions and it’s time we finally address it.
Avi
[This message has been edited by Cyranose (edited 01-06-2004).]
[This message has been edited by Cyranose (edited 01-06-2004).]
And so on…
Then it is little more than syntactical sugar, and therefore isn’t worth the time to bother with; indeed, it isn’t even worth the time to argue about it. Unless those headers actually do something more than type checking and sugar coating a C API, there is no point to them.
The vector and matrix math libraries should be inlined anyway, IMO, since the code is small and speed does matter.
What vector and matrix libraries? There are no OpenGL vector and matrix libraries. All of those functions feed directly into some part of the OpenGL pipeline. Getting data back from these functions is a bad idea, as it could be quite slow.
If we only stuck to a 1:1 C++ type-safe inline function for each existing C function call, we’d have a good standard base for people to build on.
If you do, then you haven’t really done anything significant. It is, functionally, no different from the C-base that it rests on.
If you want to build such a library yourself, go ahead. Just don’t try to pass it off as GL 2.0 or something official.
However, if you do try to make the headers do something significant, you fall into the D3D problem. COM is not D3D’s problem; indeed, it has nothing more than a v-table access for COM calls, in terms of performance penalties. The problem with D3D is where the client-code ends and where the implementation/driver code begins.
When you make an OpenGL call, your call goes straight to the actuall GL implementation. They can optimize the functionality from the beginning of the call to the end.
D3D doesn’t work that way. The implementation/driver begins much later. When you make a D3D call, it goes into the common D3D library. From there, the D3D library does various processing and so forth. The driver is simply a driver; the D3D library calls functions in that driver. However, because of where the driver begins, opportunities for optimization are lost.
An OpenGL implementation gets the opportunity to marshal calls as it sees fit. D3D handles all marshalling itself, and therefore can’t marshal in an implementation defined manor.
By creating a body of OpenGL code that the implementation cannot override (ie, your header inlines), you are creating a potential optimization problem.
the moment of compilation of your application, not the OGL core.
That’s what I meant. Just like when you link a D3D app, you are bound to the common D3D library. You create a layer between you and the implementation.
I didn’t say anything about COM or interfaces.
See above. COM isn’t D3D’s problem.
There’s no reason we’d need to see any delegated dispatch (except for the DLL binding itself, which is unavoidable).
As I said before, COM is pretty fast when run in-proc. Maybe you should read up a bit more on COM; it’s really an interesting and useful technology.
It’s been done by developers for years, but I’m tired of recreating the same wheel over and over again. This is a basic issue with easy solutions and it’s time we finally address it.
If there is a deficiency, address it yourself, and leave the rest of us alone. Make “Cyranose’s OpenGL C++ Wrapper”.
However, suggesting that some thin wrapper library should become part of OpenGL is just wrong. And a thick wrapper library has the potential of causing optimization problems.