Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  jogl API feedback requested for JSR 231  (Read 13336 times)
0 Members and 1 Guest are viewing this topic.
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #30 - Posted 2004-04-14 12:45:26 »

What about some testing time:
Wrapper classes for GL (the current one with prefixes like in C) and GLU (!) could be which contains only java-conforming names. Constants should be redefined as well.

Then let us use and evaluate this for some time and see whether it is nice or bad.

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline shawnkendall

Senior Member





« Reply #31 - Posted 2004-04-14 12:55:13 »

Quote
... The biggest issues doing OpenGL in Java are purely OpenGL issues and being able to communicate with the OpenGL world is a really handy feature of the current naming scheme.  I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.

That is a good thing.

If we want to encourage programmers in the C/C++ world to use Java, it is doubly a good thing to leave things the way they are.

This says it all.

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #32 - Posted 2004-04-15 00:42:19 »

Please forgive the somewhat OT post here, but I can't resist.

Quote


You cannot really answer this issue without defining the audience. . . .


In support of the above author and those with similar leanings, I propose a new JSR named "Break the standard in favor of fewer keys and obfuscated code for lazy programmers API".  Logically, the number would be JSR 7, since 7 is only one key and is easily reachable from my strong right index finger.  

The following rules apply:
1. Only use lowercase.  This prevents having to press two keys at once.
2. All common/popular functions should be reduced to only one character.  Popularity = precedence.
3. If the function has a common name in every other language binding, we must change it to be easy to type.  Standards and conformance are for losers.
4. All variables are implicitly typed (Ever heard of FORTRAN 77, young ones?).  IDEs don't always recognize primitive types, so we must get rid of them.  Besides, words like double, boolean, float, and String have letters and require me to use both hands when typing.  Arggh!  Too much work.  

Proposed changes include:
Math.random to Math.r
Math.cos to m.c
Math.sin to m.s
Math.tan to m.t
Math.atan2 to m.a2
gl.glEnable to gl.e
gl.glVertex[xx] to gl.v

With the release of Tiger, maybe we can even get rid of the m. and gl..

Seriously, OpenGL is a standard API and JOGL is a wrapper for this standard.  This being the case, we should make the function names the same as they are in every other language binding.  The fact that you have to call a member function from an object should not make you feel like we are in a whole 'nother world here.  You will be very glad for the conformance when you have to read source in another language that has the same function names.

OpenGL is a standard.  Let's keep it that way.

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #33 - Posted 2004-04-15 02:17:19 »

Quote


  • I think that the ability to create pbuffers should be available without the requirement to derive them from a viewable GLDrawable.  They should also not be lazily created.  AFAIK, I can create an offscreen RC in a C/C++ program without having to create an onscreen one.  Why not the ability to do the same in JOGL?



Actually the reason behind the current pbuffer API design in JOGL is because it appears to be necessary (in all of the C/C++ code I've seen) to have an onscreen OpenGL context before the pbuffer's offscreen context can be created. In the JOGL 1.1 source tree (what's currently in the repository), it turns out we always create an invisible onscreen window and associated OpenGL context for the purposes of calling wglChoosePixelFormatARB and a few other routines (for FSAA support), so we might be able to change and/or simplify JOGL's pbuffer API in the way you suggest.

Quote


  • There should definitely be a user controlled swapbuffer command in the form of gl.glSwapBuffers() or something like that.



This was just added to the public API in the final 1.0 release.

Quote


  • Make resources shareable across contexts.  You can do this on most other platforms via calls such as wglShareLists.  Of course, this would have to be abstracted away to something like joglShareLists.


This has been supported for a while. See the methods in the GLDrawableFactory which take a GLDrawable with which to share display lists and textures, and see the TestContextSharing demo in the jogl-demos workspace.
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #34 - Posted 2004-04-15 03:32:52 »

ken-
Thanks for the info on list sharing and other feedback.

BTW, anything I am suggesting as a "should" that has already been done means it should go into the "official" bindings, not that it should be implemented.  I think the vast majority of the changes to the JOGL bindings since their inception demonstrate good design and should stay pretty much the same when things go "official".

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline abies

Senior Member





« Reply #35 - Posted 2004-04-15 05:46:40 »

Quote

Proposed changes include:
Math.random to Math.r
Math.cos to m.c
Math.sin to m.s
Math.tan to m.t
Math.atan2 to m.a2
gl.glEnable to gl.e
gl.glVertex[xx] to gl.v


I understand your pun, but situation is a bit different. Mostly everybody here want to have methods like Math.mathRandom, Math.mathCos, Math.mathAtan2, while I and blah^3 are advocating going for just Math.random, Math.cos and Math.atan2.

IF similary to C is really such top priority, then why using object at all ? All methods should be static in GL class, then with static import you will be able to write
glStart(GL_TRIANGLE)
and _then_ I will agree that it is a really similar to C, which is a virtue in itself. But suddenly you are changing "opengl standard", by requiring another prefix (gl.) and making it almost object-oriented Huh For me, agreeing to gl. and then telling about having to be letter-for-letter same in C is a bit contradictory.

As for the 'binding in every other language' it just reduces to C. Everybody else was blindly copying C implementation, which _broke_ written opengl standard by adding prefixes to avoid namespace clash.. Looking this way, we should be using zero-delimited char[] arrays when passing/requesting string from opengl binding, don't we ?

Artur Biesiadowski
Offline overnhet

Junior Member




Java games rock!


« Reply #36 - Posted 2004-04-15 05:52:00 »

shaddam_IV : RTFM übern00b ! (sorry Grin I couldn't resist)

Quoted from OpenGL 1.5 specs (GL command syntax, page 7) :

"The declarations shown in this document apply to ANSI C. Languages such as C++ and Ada that allow passing of argument type information admit simpler declarations and fewer entry points."

I don't know how you read it, but it seems that GL API is not carved in stone. Depending on the language capabilities you can produce a simplified binding which ease developers work without breaking the specs. IMO the bloated aspect of the C version is mostly due to language shortcomings.

Now there are pros and cons, and an oversimplified API would achieve the opposite of the desired effect. When googling around for Java/OpenGL bindings I found YAJOGLB (http://home.earthlink.net/~rzeh/YAJOGLB/doc/YAJOGLB.html), which use gl.vertex syntax. Here is an excerpt from the PlainCube demo :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
  public void paint(GeometryViewer viewer, GL gl, GLU glu) {
    gl.pushMatrix();
    gl.rotate(30.0f, 1.0f, 1.0f, 1.0f);
    gl.material(FRONT_AND_BACK, AMBIENT_AND_DIFFUSE, material);
    gl.begin(QUADS);
    gl.normal( 0.0F, 0.0F, 1.0F);
    gl.vertex( 0.5F, 0.5F, 0.5F); gl.vertex(-0.5F, 0.5F, 0.5F);
    gl.vertex(-0.5F,-0.5F, 0.5F); gl.vertex( 0.5F,-0.5F, 0.5F);
   
    gl.normal( 0.0F, 0.0F,-1.0F);
    gl.vertex(-0.5F,-0.5F,-0.5F); gl.vertex(-0.5F, 0.5F,-0.5F);
    gl.vertex( 0.5F, 0.5F,-0.5F); gl.vertex( 0.5F,-0.5F,-0.5F);
   
    gl.normal( 0.0F, 1.0F, 0.0F);
    gl.vertex( 0.5F, 0.5F, 0.5F); gl.vertex( 0.5F, 0.5F,-0.5F);
    gl.vertex(-0.5F, 0.5F,-0.5F); gl.vertex(-0.5F, 0.5F, 0.5F);
   
    gl.normal( 0.0F,-1.0F, 0.0F);
    gl.vertex(-0.5F,-0.5F,-0.5F); gl.vertex( 0.5F,-0.5F,-0.5F);
    gl.vertex( 0.5F,-0.5F, 0.5F); gl.vertex(-0.5F,-0.5F, 0.5F);
   
    gl.normal( 1.0F, 0.0F, 0.0F);
    gl.vertex( 0.5F, 0.5F, 0.5F); gl.vertex( 0.5F,-0.5F, 0.5F);
    gl.vertex( 0.5F,-0.5F,-0.5F); gl.vertex( 0.5F, 0.5F,-0.5F);
   
    gl.normal(-1.0F, 0.0F, 0.0F);
    gl.vertex(-0.5F,-0.5F,-0.5F); gl.vertex(-0.5F,-0.5F, 0.5F);
    gl.vertex(-0.5F, 0.5F, 0.5F); gl.vertex(-0.5F, 0.5F,-0.5F);
    gl.end();
    gl.popMatrix();
  }


Is it that ugly ?

As far as I'm concerned, the main simplification I would like is redundant suffix removal (see my first post). The rest I don't really care, but I think we should aim at the best readability / efficiency balance.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #37 - Posted 2004-04-15 07:36:23 »

Quote
being able to communicate with the OpenGL world is a really handy feature of the current naming scheme.  I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.


Are you saying that programmers who understand

  gl.glVertex3f(...) == glVertex3f(...)

yet are too incredibly braindead to be able to understand that

  glVertex3f(...) ==  gl.Vertex

are somehow intelligent enough that they can help you with your OpenGL problems?

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #38 - Posted 2004-04-15 07:40:09 »

Quote
What about some testing time:

Then let us use and evaluate this for some time and see whether it is nice or bad.


Unless someone (e.g. the GTG?) has a firm description of the intended audience that answers the issue outright, then this sounds like an excellent idea; isn't it "just" a matter of adding some output options to automatic code-generator?

In response to: (crappy forums dont do recursive quoting)
Quote

You cannot really answer this issue without defining the audience.

Quote

In support of the above author and those with similar leanings, I propose a new JSR named "Break the standard in favor of fewer keys and obfuscated code for lazy programmers API".  Logically, the number would be JSR 7, since 7 is only one key and is easily reachable from my strong right index finger.  


Funny Smiley. But you also seem to have been serious...you are implying that you are able to decide what an API should be without considering who the users are. This is the stereotype of the useless geek programmer: someone who codes for other people but makes all decisions purely selfishly and hence ends up with software which no-one understnads, no-one can use, and only works on the author's computer.

Quote

This says it all.


Are the java programmers less relevant than the C++ programmers? Is this java library are being developed primarily for the benefit of the non-java programmers?

Shrug. I don't know; if the primary intent of JOGL is to ease migration for C++ programmers then sure - I'm all for being as identical to C-OGL as possible.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #39 - Posted 2004-04-15 07:47:26 »

We seem to have solved this problem in LWJGL and no-one's complaining. At least, no-one we're going to take any notice of Wink

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline hdevaan

Senior Newbie




Java games kick @ss!


« Reply #40 - Posted 2004-04-15 09:44:29 »

If we can agree that:
1) For any Java API, common practices and standards of the Java platform take precedence over compliancy and resemblance with other languages and technologies.
2) The OpenGL specifications do not prohibit or even discourage simplified bindings (as mentioned earlier by overnhet in reply #36 on page #3)
then it is very reasonable to choose for an API with methods such as:
gl.vertex(float,float,float)

Although I agree that C/C++ resemblance being important to JOGL is a fair point of view, I don't feel it is acceptable for libraries or modules that will become a standard part of the Java platform.
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2004-04-15 10:01:06 »

I hope JOGL does not become a standard part of the platform.

Cas Smiley

Offline hdevaan

Senior Newbie




Java games kick @ss!


« Reply #42 - Posted 2004-04-15 10:12:23 »

I didn't mean to imply that it would (in fact, I also think I didn't).

However, what we're discussing in this thread is JSR 231 - the Java bindings to OpenGL. This API will become part of the Java platform; probably as part of the Java Media Framework. Conformity with Java practices and standards is more important than C/C++ resemblance.
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #43 - Posted 2004-04-15 10:50:57 »

When the only tool you've got is a hammer every problem looks like a nail. The issue here is that Java programmers treat Java like a hammer and see OpenGL as just another nail to hit. The OpenGL API is not nail shaped at all. It's not an object-oriented API because it does not work with objects, it's a hardware context state machine API, and that really, really, doesn't sit well with the "widely perceived" view in Java that everything has to be an Object because Java Objects and Threads have absolutely no notion of the idea of a hardware context.

If this is grokked it's dead easy to design an API that makes everyone happy because it follows the original design of OpenGL - namely one designed with hardware context state machines in mind - and with JDK1.5 your namespace problems are solved neatly without a great deal of extra typing. (We went this route in our binding, and all is well).

But if you go the Magician route and have GL instances all over the place then you can't avoid a gl. prefix in the code* However this means you don't have a namespace problem; so you may as well ditch the gl function name prefix as it only exists to create a C namespace for the rather extensive GL command set. Likewise GL_ constant names. And then while you're at it you should get rid of the 3fs, 4fvs if you're going to fiddle with the well-known C naming implementation and properly javaify the API in this way.

Cas Smiley

[size=0]* this has the added caveat that people do not necessarily have to use "gl" as the variable name either; code can end up looking like
1  
2  
3  
debugGL.vertex3f(x,y,z);
debugGL.vertex3f(x,y,z);
debugGL.vertex3f(x,y,z);

which isn't nearly so readable any more, is it?
[/size]

Offline hdevaan

Senior Newbie




Java games kick @ss!


« Reply #44 - Posted 2004-04-15 12:39:46 »

The issue here is that OpenGL programmers are treating Java as a tool to program 3D graphics, instead of a platform that features a great many things, one of which is programming 3D graphics.

One of the key concepts of Java is to provide an object oriented abstraction of a domain or technology. Regardless of the fact that OpenGL is not an object oriented API, the Java platform is about objects. If that truly represents a show-stopping obstacle, then Java should not have direct access to the OpenGL state machine in the first place.

Having said that, I myself have written Java layers on top of C drivers for security equipment such as remote controlled cameras and intercoms. While the underlying system obviously has nothing to do with objects, that fact was completely hidden in the Java layer. Rather than having many instances degrading performance, there were a number of classes that separated the JNI-related internals from the rest of the Java world.

I'm not saying you need to go onehundred percent OO on the implementation level, but the interfacing to the outside world (ie: the Java platform) should be completely OO. Prefering classes over instances is both logical and perfectly acceptable in the Java universe, so I'm certainly not advocating an architecture that uses many instances.

PS: Getting rid of the 3fs and 4fvs is indeed a good idea from a Java perspective.
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #45 - Posted 2004-04-15 19:49:37 »

Quote


I understand your pun, but situation is a bit different. Mostly everybody here want to have methods like Math.mathRandom, Math.mathCos, Math.mathAtan2, while I and blah^3 are advocating going for just Math.random, Math.cos and Math.atan2.


Hmmmm.  What I said wasn't a pun and I don't think you got it.

What I am advocating is not changing function names in a common API.  If we are going to bind to a function named "foo" through JNI, we should call it "foo" to be consistent, not "f" because it is easier to type.  We shouldn't just change the name for convenience only.  If we were to write our own Java 3D API, then we could name functions whatever we felt like, but that isn't the case here.  We need to stick to the conventions established by the larger community.

One thing everybody has assumed is that the GLDrawable object is going to be named "gl".  There is no reason this needs to be the case.  I could call it "al."  In that case,

1  
gl.vertex() 


would become

1  
al.vertex() 


But wait, is al the Audio Library?

I have yet to hear any good reason why the function names should change from their C counterparts.  There is nothing about the gl functions that violates Java conventions.


There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #46 - Posted 2004-04-15 20:13:50 »

Quote


Are you saying that programmers who understand

  gl.glVertex3f(...) == glVertex3f(...)

yet are too incredibly braindead to be able to understand that

  glVertex3f(...) ==  gl.Vertex

are somehow intelligent enough that they can help you with your OpenGL problems?


I doubt that is what kaffeine meant.  I think kaffeine meant that by maintaining the common names we are better able to communicate with other GL developers who may not be Java programmers.

We certainly won't be able to communicate or collaborate if we call them "braindead" for not being familiar with a different set of function names.  

BTW, the case won't always be as simple as:
1  
glVertex3f(...) ==  gl.Vertex 

(shouldn't this be a lowercase v?)

I could just as easily type:
1  
myOnScreenRendererInstance.vertex(...)
 This statement has very little similarity to a "normal" OpenGL call.  Other things have vertices, too.

On the other hand, I could do this:
1  
myOffscreenRendererInstance.glVertex3f(...)

By reading it, I immediately see the function name is a GL function that I am familiar with, and that the calling object claims to be an offscreen renderer.  This leverages both the power of Java OOP and maintaining the common convention.

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline abies

Senior Member





« Reply #47 - Posted 2004-04-15 20:37:05 »

It is not just about being easier to type. This is about redundancy in code, poor IDEs having to cope with thousands of possible autocompletions, elegance and being able to see outside 'we are just making a wrapper around C library'. I thought it was supposed to be an opengl binding, not C-wrapper-binding.

Yes, you are right - if you want to bind JNI function directly, you probably should name it in same way. But why pretend and make it instance method ? Why not static method ? We are just wrapping C function, don't we ? Maybe, God forbid, somebody will create a wrapper implementing GL interface and glVertex3f will not call C function directly, but for example, perform extra logging ?

As for the rules of bigger community... I could agree here. But what bugs me, is that that rules are handpicked in  arbitrary way. gl prefix - yes. Functions instead of methods - no. Using raw ints for offsets into buffers - no. Using zero-delimited strings - no.

Back in 1.2 days, BigInteger was a wrapper around Colin Plumb C math library. Many methods were 1-to-1 equivalents of C lib. Still, we have bigInt.multiply, not bigInt.bnMul...

Look at java gtk binding. We have button.getLabel(), not button.gtk_button_get_label() nor button.gtkButtonGetLabel. <sarcasm>A lot bigger change, for sure confusing for C users. How could they dare to change method name, just to save typing gtkButton prefix ?? They could as well name it button.gl() ( from getLabel) if they are really so concerned about typing to many letters </sarcasm>

I see two 'honest' possibilities. Either go 'we-want-to-have-C-in-java' route, and covert all methods to static, use static imports, int pointers where needed and have 1-to-1 compatibility with C code, or try to make it java opengl binding and remove C we-need-to-emulate-namespace prefixes, remove redundant suffixes and make all methods instance to allow overriding/layering/etc. For me, anything in between is just a set of arbitrary choices, according to personal preferences, not a coherent system.

There is also third choice - make truly OO opengl binding, with objects like Texture, VertexBuffer, Material, where you would be actually able to guarantee safety of executed code (no hacks/crashes through too small buffers for GetPixels). I'm still talking about immediate mode API - just instead of calling number of methods for setting material colors, you would create Material object and call glContext.setCurrentMaterial(material) and then glContext.draw(vboBuffer); followed by glContext.swapBuffers();. But this rings a 'scenegraph' bell and we are discussing opengl binding... I mean C-version-of-opengl-binding...

Artur Biesiadowski
Offline hdevaan

Senior Newbie




Java games kick @ss!


« Reply #48 - Posted 2004-04-15 20:37:57 »

That convention is common only in the C/C++ community. Since we're dealing with a Java API, I maintain that such resemblance is completely irrelevant. You're using the domain (OpenGL) as focal point of the architecture, instead of the platform (Java).

Furthermore, the idea that you wouldn't know that myOnscreenRenderer is an OpenGL object when the method name doesn't have the 'gl' prefix is a nonsensical argument. A method with gl prefix does not provide any harder evidence that myOnscreenRenderer is an OpenGL object, because other methods can have a 'gl' prefix as well.

[edit]
This is a reply to post #46... which I thought would be direcly above this one... but I'm not as fast as I like to think Tongue
[/edit]
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #49 - Posted 2004-04-15 21:24:38 »

First off all I want to lessen the religous style of this discussion. The 'prefix-or-not' discussion is as old as the bindings to OpenGL .... and I can say that I can live with either of them but ...

1) there exists a design document somewhere which describes how java identifiers should be named and gl/GL_ and the type postfixes are just clutter.

2) OpenGL explicitly allows the usage of simplified identifiers.

3) In XY years one has to explain why the implementation of the official Java OpenGL binding breaks the standard naming rules of java. Then it will be difficult to explain to someone what the need for d/f/i/v is when there is such a convenient thing named method overloading?
Then it has to be said that there was once a popular language called C which used that syntax and people thought they would ALWAYS copy-and-paste old C code into Java ...

Again I vote for an evaluation time where both can be used and the convenient one is implemented as a wrapper. The code snippets that are flying around here and there are just not meaningful.

Does anyone knows a convenient way to generate these wrapper classes?

(XY => put your favorite number here Cheesy )

---

EDIT: I was asked to explain the wrapper classes and do not wanted to add another post:

I think of a wrapper class which maybe called JavaGL (and JavaGLU) which takes an GL (or GLU) object as an parameter and delegates all calls to this object. The interesting thing is that JavaGL(U) contains all methods of the GL(U) interface with respect to Java's naming convention. That means GL.glVertex3d() (and all variants) are accessible via JavaGL.vertex(). Additionally every constant (eg GL.GL_TEXTURE2D) is converted as well (JavaGL.TEXTURE_2D). The generation of such wrapper classes (for GL, GLU and maybe GLUT) should be done automatically. Please keep in mind that performance is not the goal of this test. It should be a way to evaluate which naming scheme is better suited for everyday use and whether there are any problems creating it (eg. unsolvable name conflicts). The wrapper classes itself do not need to be a part of JOGL.

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline hdevaan

Senior Newbie




Java games kick @ss!


« Reply #50 - Posted 2004-04-16 06:09:11 »

Quote
Does anyone knows a convenient way to generate these wrapper classes?


Could you elaborate on what kind of wrappers you're thinking of exactly? I might be able to provide some help, but it really depends on whether or not I understand you correctly...
Offline pepijnve

Junior Member




Java games rock!


« Reply #51 - Posted 2004-04-16 06:54:28 »

Quote

Again I vote for an evaluation time where both can be used and the convenient one is implemented as a wrapper.

I don't think that would be a good idea. I have a gut feeling that this would just result in splitting the developer group in two camps, each using there preferred version, and not provide a solution in the end...
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #52 - Posted 2004-04-16 15:45:15 »

I concur with pepijnve.  I think the whole naming thing will become a holy war if we introduce N versions of JOGL, each with different names depending on what religion you belong to.  The goal here is to provide official OpenGL bindings, not create 30 different unofficial ones.  I also don't think the guys making the JOGL bindings feel like maintaining all the different versions.

Something to remember about all of this, too, is that the final JSR binding needs to be endorsed (sometimes officially, sometimes not) by Sun, the OpenGL community, and the ARB.  This may require going with what the general community is doing, despite personal preferences.

The intent of this thread is to provide JOGL feedback for JSR231, not have a flame war about naming conventions.  Since the JOGL architects have gone with the full C names, our task is to provide feedback.  I think plenty has been given on this particular item.  Maybe we can move on now.

Perhaps people have feedback on other jogl features?

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #53 - Posted 2004-04-16 16:02:19 »

How about actually getting around to fixing all those bugs in the bug tracker?

Being able to create a framebuffer with an alpha component on linux would be a good start. As would throwing sane exceptions instead of the crap that gets chucked out at the moment. And all the other bugs that I've mentioned that get swept away with a 'soon' promise before the developers go and hide for the next couple of months. Angry Angry

And from an API point of view the whole Animator requirment is just plain ugly. But 'expose glSwapBuffers' has already been mentioned I think.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline trance-x

Junior Newbie




Java games rock!


« Reply #54 - Posted 2004-04-16 17:09:56 »

i see, no unknown discussion but ...

it hurts me hard to see these unnessecary doubled gl_prefixes ... its like a bad covered/ported song where the musican simply makes an 1:1 copy of notes but has no knowledge and feeling for music, takes no care about the result ... got not the sense of the song itself ...

please have a look at this snippet:

gl.glBegin(GL_QUADS);
  gl.glNormal3f( 0.0f, 0.0f, 0.5f);
  gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f(-1.0f, -1.0f, 1.0f);
  glTexCoord2f(1.0f, 0.0f); gl.glVertex3f( 1.0f, -1.0f, 1.0f);
  glTexCoord2f(1.0f, 1.0f); gl.glVertex3f( 1.0f, 1.0f, 1.0f);
  gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f(-1.0f, 1.0f, 1.0f);
  (...)
gl.glEnd();

what should be the meaning of "gl.glBegin(...)? it tells me: there is a "begin" of "something what GL is" which will be addressed to "something what GL" is. sorry: if you want to know why some softwarepackages are oversized, full of crap, intransparent, too complexe and other packages are smart, fast, consistent and readable, so you can find the difference in decisions like this... summary shows quality ...

its like good performance optimization: the focus should not be at a few ppl which are in an openGL-porting context or "porting C programs to java" ) ... the focus should be at "the everyday situation of masses of java programers which uses an 3d-opengl-java api in combination with other apis and with the intention to create readable software". some "wrong" ports and you can make a languages and system absolutly inconsistent, oversized, unreadable ... the mistake: wrong focus ... optimizing the wrong part of a program ...

you CAN relatively simple automate portings from "C/C++-openGL" to java and ... in any event ppl doing this needs to know more details  ... but you can NOT avoid the effects of wrong complexity/overhead, intransparency and inconsistency for the masses in an everyday situations for masses of programers ... every "bit" as a result of a wrong decision could be the switch that a good idea, a good software will never be realized. intelligence keeps things easier and there are very good reasons for that...

and: i think ... it is simply no good idea to create an enviroment where the source gets more and more distance to an selfexplaining character (and to the logic of oo/java). imagine a program where every method is oversized or modified because "in the history of building this api ..." or "ok, the logic will raise if you think about conversion" etc. ... this would not be anymore a good language for programing but an indirecte porting and conversion language ...

and sorry, with a little sense for aesthetics and logic: "gl.gl_vertex3f(...)" SCREAMS for a better solution! "gl.vertex3f(...)" tells everything you want to know, gives an assocative bridge to openGL, shows consistent that vertex is in "gl" etc.

so i think the next snippet is much better and if you imagine thousands of situations where ppl read javacode and check their sources, so you can calculate where the priorities should be ...

gl.begin(QUADS);
  gl.normal3f( 0.0f, 0.0f, 0.5f);
  gl.texCoord2f(0.0f, 0.0f); gl.vertex3f(-1.0f, -1.0f, 1.0f);
  gl.texCoord2f(1.0f, 0.0f); gl.vertex3f( 1.0f, -1.0f, 1.0f);
  gl.texCoord2f(1.0f, 1.0f); gl.vertex3f( 1.0f, 1.0f, 1.0f);
  gl.texCoord2f(0.0f, 1.0f); gl.vertex3f(-1.0f, 1.0f, 1.0f);
  (...)
gl.end();

- better integration in the logic of oo/java
- much better readable sources
- more transparency
- more elegance
- more sense
- smaller

:)


ps: finally ... if the prefix will not change it could be really an idea to make an alternate/modified port of the port for ppl who dont like the senseless overhead ... serioes: i personally really dont like such "style" in my sources ... baeh!

ps2: i also think that "one" standard would be the best ... but like in offline life: there are limits - or better: i prefer the focus at the general standard of the oo/java context ...
Offline hdevaan

Senior Newbie




Java games kick @ss!


« Reply #55 - Posted 2004-04-16 17:52:10 »

The prefix/suffix dilemma

According to the JSR 231 document, the goal of the API is to create "bindings to the native 3D graphics library, OpenGL". Furthermore, "the specification will be made device agnostic to allow for the possibility of subsetting the API for different classes of devices (via future JSR's)". Although the document states that "having an API based on the OpenGL specification will ease the efforts of porting these applications to the Java platform", it is a mistake to think of the JSR 231 API as a migration toolkit for C/C++ OpenGL programs. It is first and foremost an API for Java developers who need to program 3D  graphics. I mean no disrespect to the LWJGL or JOGL community when I say this, but the C/C++ mindset is not quite relevant for a Java API.

The issue of removing the GL prefixes and type suffixes is not simply a flame war on naming conventions; there's more to it than that. The GL prefixes were introduced to prevent name clashes, because C does not have namespaces. Java has namespaces; they're called packages. The type suffixes were added to allow several functions with nearly identical names that take different parameters. Java has method overloading, which is one of the key concepts of object oriented programming. Using method overloading, the system automatically routes your call to the right method depending on the parameter types. To ignore packages and method overloading is worse than reinventing the wheel; it's 'uninventing'  it. Effectively, you're blatantly ignoring the object oriented nature of the Java platform.

Reuse Java AWT/2D/3D

Another key issue of object oriented programming (perhaps software development in general) is to reuse existing components. I know very well that this is much easier said than done, but it should be kept in mind when carving the JSR 231 API. At least for interfaces, it would be a good idea not to invent new ones that do what some in Java AWT and 2D already do (and perhaps 3D? Maybe not; that's a fairly difficult one). I think JOGL already exhibits good reuse left and right, so this should not be a problem.

Don't fear objects

Performance scare, more than any other reason, is used to fight against having objects around. For an object oriented platform like Java, that is really a non-issue. If you dislike objects enough not to want any instances around, Java is not for you.

Having said that, I certainly concede that having many instances with short life cycles is not a healthy recipe for performance. This means that often choosing static members over instance members and often using wrapper objects around static code is very reasonable. I think JOGL is already doing a nice job in this area.

The API and the impl

Last but not least, I would like to point out that JOGL is a candidate for becoming the reference implementation of the JSR 231 API. This  means it does not have to be a 'picture perfect' software package from the perspective of Java standards and practices. It means that it must be so at the interface level. I hope this makes it clear that I'm purposefully measuring JOGL and the future JSR 231 API in different ways.

Sincerely,
Hugo de Vaan

PS: To ensure that people do not get the wrong idea - I deeply respect the efforts of the people behind the LWJGL and JOGL projects. By no means are my comments or ideas intended to question the quality of the code or design of those projects. As someone who has over 5 years of experience in professional Java development for companies like IBM, the Royal Bank of Scotland and EDS, I am trying to convey some key principles and standards of Java with a certain amount of enthousiasm. Whenever that amount gets too much, let me know that I've come dangerously close to flaming and I'll apologize and try to rephrase my points.
Offline djp

Junior Member





« Reply #56 - Posted 2004-04-16 18:48:00 »

OK, so I take it that the gl/GL prefix issue is a hot topic!  There have been valid points made on both sides of the argument.  I don't think we need to keep thrashing the issue around in the forums anymore.

This will be one of the first issues to be decided by the JSR 231 Expert Group.  What I intend to do is summarize all of the points made here and use them to start the EG discussion.  I can already tell that whatever decision is made someone won't be happy.  Hopefully whatever is decided will not cause a rift in the community.

Moving on from G's and L's, if this API feedback topic were closed today, does it capture all of the current issues with how JOGL handles the OpenGL API?  I don't want to overlook anything because everyone got sidetracked on the naming convention.

By the way thanks for the input!  The more I have the better I can guide the EG to the problems the community feels are important.

d
Offline abies

Senior Member





« Reply #57 - Posted 2004-04-16 19:02:23 »

In addition to things I have mentioned in my first post (security), I wonder if it would be possible to integrate java images with opengl calls - so ImageIO could be used directly for feeding textures to opengl.

There is also a big question of updating the official binding. With JOGL, in theory you could just regenerate it every time  new glext.h appeared. With official libraries, it would be very bad to have to wait more than few weeks for new extensions to appear in GL.java - so some kind of process has to be set up to keep it up to date.

Artur Biesiadowski
Offline trance-x

Junior Newbie




Java games rock!


« Reply #58 - Posted 2004-04-16 19:04:56 »

1. imagine another world ... openGL was originally built in java and we talk about a port for C ...

in java: gl.vertex3f(...)

what would be the porting result for C?

it would be: gl_vertex3f(...)

now, do simply a vice versa ... and you get the clou ...

would u like an gl_gl_vertex3f(...)?
no? ... but this would be the backresult of a port of "gl.glVertex(...)"  keeping and using the unlogical way ... we would now discuss why it makes more sense for C to use gl_vertex(...) and not gl_gl_vertex3f(...) ... check your arguments against this example ... ppl who think gl.glVertex(...) makes sense should simply port to C then back to java then back to C ... after some rounds they will recognize that their arguments will stay in the same logic but produce more and more "gl_gl_gl_gl_gl_..." :)

2. i also see no need for a war (ok, it could make fun, some emotions:)  ... but like other ones already said: it is not only a simple question to give things a name ... it has more consequences ...

there are reasons to tell these consequences ... and give discussions a room ... avoiding this would mean "probably fixing a wrong direction/standard" ... today there are not so much ppl using opengl and java ... this could change ... and then ...

so: i see no need for a war but a need to debate this ...

3. in respect for the ppl who did already software using jogl etc. i think in any rate a wrapper/converter/porting tool  would be a good idea ... not primary to see which name convention will win (i dont believe that sun/java serioesly would introduce such a obscure double name convention) but it could make sense for the whole java-opengl- and general java community to have a tool which can port the old javastuff to the probably new name convention - and make the porting process from C and other languages so easy ... that in shortest time all the old and new opengl demos, games, appz, sources  will be available in java. this could also mean that generally software which are only available for one platform/os run after the porting on all platforms .. now available for all users of all systems ... maybe some optimizing included (hardwareFx which are 5 years before not exists, newer methods, better javacode for networking etc.) and as a synergetic effect: etablishing java and 3d mentally as a practical working alternative ...
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #59 - Posted 2004-04-17 03:24:32 »

Note to rest of readers:  I apologize for revisiting this topic after suggesting we move on.  I just want to respond to our new reader.

Uh, trance.  I don't think you are following the argument correctly.  You seem to think the people who want to be consistent want to change things.  Please see www.dictionary.com for a definition of the word "consistent."  That is exactly the opposite of what we are saying.

We are suggesting maintaining exact names across languages.  So, if I had a Java function called like so

1  
myObject.foo()


the "equivalent" C++ code would be

1  
myObject.foo()


or, if the function was static,

1  
myObjectNamespace::foo()


of, if you are in a previous generation language like C,

1  
foo()

Note that you do have to deal with the object here, but you could do something clever to make it all work.  The point is the consistent function name.

Perhaps you see the pattern here.  Hint: run a string comparison on the function name.

The alternative to consistency is doing whatever you want.  Suggestions for possible naming conventions include:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
gl.vertex()
gl.Vertex()
gl.vertex3[df]()
gl.vertex3[DF]()
gl.Vertex3[df]()
gl.Vertex3[DF]()
gl.v()
//Remember, the "pro-renaming argument fails to
//address the issue of naming your GLDrawable
//something besides "gl", which has great potential to
//confuse others.
al.(one of the above)
whateverYouCallYourObject.(one of the above)
bar.culmination //I don't like the word "vertex", so I used a synonym
foo.monkey //Why not?  I can do whatever I want as long as I think it looks like Java.


There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (16 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (73 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!