using jogl bindings sans redundant GL. prefix etc

checking out the java glxgears source… i see that all of the opengl functions and constants are prefixed with either gl. or GL.

for reasons such as portability and just personal esthetic preferences, i’m interested in means by which to use jogl as you would use opengl within your standard C type environment, or that is plane glFunction GL_CONSTANT syntax.

i’ve been informed that it should be possible to link to the jogl library “staticly” so that the constants should not require a GL. prefix or otherwise.

and i see that the gl. prefixes in the gears demo are really member selectors for the class responsible for ‘canvas’ type targets. that is “drawables” / contexts etc.

so it should be possible to use global wrapping functions to wrap the current rendering context so that functions can be used without the ever present virtually redundant prefix.

basicly i would prefer the opengl syntax look like native opengl as much as possible.

and my general query is… is there a better way to go about this?

and if not has anyone already produced a wrapper library for doing this for the functions?

my apologies if this suggestion offends anyone’s sensibilities.

sincerely,

michael

You can use the “import static” functionality to get rid of the “GL” prefixes in J2SE 1.5 and later.

JOGL doesn’t support a C-like binding in which the GL functions themselves like glVertex3f are static. This is a fiction on some platforms because the function pointers can be different between different OpenGL contexts.

thanks but, would something like:

glVoid glEnable(glEnum C){ gl.glEnable©; }

not suffice?

You could certainly write such a wrapper class, fetching the current GL instance each time via GLU.getCurrentGL(). However, we’re not going to add such a wrapper to the core API.

i certaintly wouldn’t expect you to add any such to the core api… just wondering if anyone has done it already?

is it really necesarry to “getCurrentGL” each time… the gears demo (i don’t have it in front of me) just declares a “gl” object (sorry forget the class name) …and uses that for the rest of the source.

couldn’t you just set the context to your own after which all wrapper calls would go through that context?

i’m new to java, but i’m assuming you are thinking along the lines that the wrapper would be a shared library, couldn’t it be static? or included into the .java sources? i don’t even know at this point if inline include preprocessor style is allowed by java… java doesn’t appear to have any sort of preprocessor. is it possible to break a java class definition up across files?

michael,

You must realise that Java is an object-oriented programming language, whereas C is a procedural language. Since Java does not have the notion of global constants, and each method invocation is a message sent to an object, you cannot expect the same syntax.

In C, if I invoke

foo()

I am simply calling the (global) function by name, which is also the reason for the function name madness (with prefixes etc) in C. In java, when I invoke

mygl.foo()

, I am sending a foo() message to the object, to which I have a reference called mygl (an instance of class GL). That object will decide how to react to my message, I as caller have no control over it. This is the very basis of OO.

Using OpenGL in it’s “natural” (state machine) form from within Java (using JOGL) is actually very unlike any typical Java API (which rather provides a “service provider” interface), but I can see it’s value.

The Java5-introduced import static (described at http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html) will also not help you, because the gl* methods are not services provided by the GL class, but by instances of it. So, the only way you could get away from the

gl.gl*

usage is by creating your own GL sub-class, and by severely hacking the JOGL API to make use of your class as the context, and then doing your rendering operations within your class… which would be a conceptual disaster. :frowning:

So, embrace Java for what it is, and don’t take JOGL as a typical example! For the most part, it’s a terrible-to-use, low-level state machine modeled directly on an ancient C API. But oh, the power… It impresses me every day to do these things in Java, which was once considered a “slow” language. If you need a more typical OO interface, use Java3D instead (which can use OpenGL under the hood in anyway). ;D