Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JOGL Exposed  (Read 6713 times)
0 Members and 1 Guest are viewing this topic.
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Posted 2003-06-19 00:50:30 »

This is a continuation of this discussion:

http://www.puppygames.net/forums/viewtopic.php?t=83

I figured it needed to move here now that the forums are reopened. Smiley

Quote
Everything in the util package is, as you said, a "we need that quick" class. They're not intended to be "jogl"... rather, they were helper classes that a bunch of the demos used. But since the demos didn't all get posted (yet), their presence is misleading. They should probably all go in *.demos.util; nothing in the jogl "core" depends on any of them.


Ok. So can I safely assume that net.java.games.jogl is the only real API? If that's the case, there are only a couple of comments I have about it.

1. The XVisualInfo docs state that the class is useless to the end developer. Shouldn't it be hidden?
2. A model loader/texture loader API is probably needed as a separate project from the JOGL stuff. Many of the UTIL classes could move there then.
3. DurationTimer should probably be forgotten about. It's a very confusing implementation. There are plenty of good timers out there. If you'd like, you can take my GAGETimer and roll it into a utility project. I won't mind. Smiley


Beyond that, I'd just have a few semantic disagreements. I personally don't like the idea of the "static imports" and would much rather see the "gl" dropped from method names. That's just my opinion tho, so take it for what it's worth. Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2003-06-19 05:35:05 »

There are some X11-specific OpenGL extensions which refer to the XVisualInfo data type. These extensions are exposed in the public interface GLX. For this reason the XVisualInfo class was exposed in the public API rather than put into an implementation package; we didn't want to unduly limit the usefulness of any window system-specific extensions though to be honest not too many can be taken advantage of by end users since they require information not provided by the library. However, they are used by the implementation; for example, the pbuffer implementation on Windows uses the publicly-visible WGL extensions heavily.

The model loading code was "quick and dirty" as is probably apparent. We only put in exactly what was needed to get the demos we needed to port working. Some more one-off loaders will be checked in along with the demos.

DurationTimer was a quick hack to get some framerate statistics out of some of the demos and can be deleted at pretty much any time. I did add another set of timer classes for animation purposes which will show up in the source tree as soon as we get clearance to post the source code for the demos, at which point more discussion can usefully be had about what' should go where and what should be changed.

There are several strong technical arguments against changing the GL interface to be a class with static methods. Regardless, the naming convention of the methods themselves will almost certainly not change.
Offline abies

Senior Member





« Reply #2 - Posted 2003-06-19 06:23:39 »

Quote
Regardless, the naming convention of the methods themselves will almost certainly not change.

Could you please explain the rationale behind sticking to gl.glEnable/gl.glColor3f instead of gl.enable/gl.color3f ? Legacy programs already ? Easier to conver programs from C (replace gl->gl.gl instead of gl -> gl.<and_change_next_letter_to_small) ?

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #3 - Posted 2003-06-19 06:38:25 »

Quote
Could you please explain the rationale behind sticking to gl.glEnable/gl.glColor3f instead of gl.enable/gl.color3f ? Legacy programs already ? Easier to conver programs from C (replace gl->gl.gl instead of gl -> gl.<and_change_next_letter_to_small) ?


I can't sate why JOGL did this, but I suspect that it is the same reason for it, that is causing LWJGL to do this too.
Static imports in Java 1.5.

thus:
gl.glEnable(...) becomes:

<in the top of java file)
import org.lwjgl.opengl.GL;

glEnable(...)

you would then not need to modify the methodnames of any of your c sourcecode

Offline abies

Senior Member





« Reply #4 - Posted 2003-06-19 11:05:29 »

I could understand the reason of static imports, but Ken just said they are against static methods. So my question is: Why gl prefix with _instance_ methods ?

Artur Biesiadowski
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #5 - Posted 2003-06-20 02:36:04 »

The decision to leave the method names alone was not made based on the future use of static imports. The names were left unchanged simply because all of the existing documentation and code refers to those names, and changing them would cause unnecessary confusion.

-Ken
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2003-06-20 06:30:57 »

If you're not planning on using static imports, why not remove the 'gl' prefix from all the methods?

Personally, I think its redundant and daft to include them. The original names were C names, and so with no proper namespacing the prefix was needed. By having a GL class then function name collisions are automatically avoided.

There was a thread about this when LWJGL had to make the decision (way before static imports were likely) and the overall majority was for the gl.Enable() style instead of the redundancy of gl.glEnable().

Edit: I can't find the thread Sad Either i'm searching for the wrong things, or it died with the previous boards.

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

Senior Member


Medals: 1


Who, me?


« Reply #7 - Posted 2003-06-20 08:41:54 »

I believe at least part of that discussion was on SourceForge...

Ah, found it:

http://sourceforge.net/forum/forum.php?thread_id=718108&forum_id=196813


Edit: And heh, it may not be publically linked anymore, but if you know where to look... Grin

http://www.java-gaming.org/discus/messages/141/1582.html

Hellomynameis Charlie Dobbie.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #8 - Posted 2003-06-20 11:29:55 »

Bah,  the gl prefix is far too trivial to argue over.

It really isn't going to have a meaningful effect on anything in the long run.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #9 - Posted 2003-06-20 11:52:51 »

Quote
I believe at least part of that discussion was on SourceForge...

Ah, found it:


Uncannily enough, that was exactly what i was trying to find Smiley I'm sure the concensus remains with striping the prefixes..

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline josgood

Senior Newbie




Nudge reality.


« Reply #10 - Posted 2003-06-23 02:05:06 »

What's old is new again...

Alligator Descartes and I hashed thru the Java vs 'C' method names debate SEVEN years ago.  Alligator wanted backward compatibility to facilitate porting.  I wanted rational bindings for Java.

It was then covered again by the ARB in 1998.  

Our compromise was to have both.  Included in the bargain were convenience methods, for instance GL.color( java.awt.Color ).

And before anyone freaks about code bloat, that's what packagers like IBM's JAX are for.
Offline ckline

Senior Newbie





« Reply #11 - Posted 2003-06-23 02:47:28 »

It would be easy to modify BuildComposablePipeline.java to emit another pipeline which contained non-prefixed calls wrapping their prefixed base methods (e.g., color3f() calling glColor3f()). This modification would probably take 10 minutes, tops.

This would, as Jason suggested, give you the best of both worlds.

-chris
Offline josgood

Senior Newbie




Nudge reality.


« Reply #12 - Posted 2003-06-23 17:50:55 »

Hi Chris-


Quote
...another pipeline which contained non-prefixed calls wrapping their prefixed base methods (e.g., color3f() calling glColor3f()).


Hey, thanks for listening! <grin>

In Magician, the type denoting suffixes were also dropped for the Java-ified names.   For example, color( float, float, float ) in place of color3f( float, float, float ).


Cheers, Jason
Offline abies

Senior Member





« Reply #13 - Posted 2003-06-23 18:57:39 »

This is not a poll, but yet another, maybe a bit funny argument in favor of dropping prefixes: Even official opengl document list function names and constants without GL prefix (example
http://oss.sgi.com/projects/ogl-sample/registry/ARB/transpose_matrix.txt
) - gl/GL_ prefixes are unfortunate requirement of flat C namespace.

Artur Biesiadowski
Offline leknor

Junior Member




ROCK!!!


« Reply #14 - Posted 2003-06-23 20:43:11 »

I doubt I'll have any influcen on JOGL API but when I write an API at my work I try to think What Would XXX Do? Smiley Where XXX is Joshua Bloch or Ken Arnold. The Java API has it's fair share of warts but from what I've seen of the APIs crafted by these two I really respect their opinions. (I've found the four intervies in the second section of the Artima Design Corner be good reads.)

Anyway, JOGL is an OpenGL API so you don't really have the flexibility to make all the design decisions but there is reasonable flexibility when adapting the C API to a Java API.

I belive the arguments for of preserving the gl prefix doesn't carry much weight when you move out of a flat namespace. I give the most weight to the aguments for making the API the easiest for the programmer to read and understand.

My OpenGL experience is minimal, so I'm not going to claim to be an authority on OpenGL usability but that's my $0.03 cents as it applies to APIs.
Offline abies

Senior Member





« Reply #15 - Posted 2003-06-25 16:50:54 »

Quote


In Magician, the type denoting suffixes were also dropped for the Java-ified names.   For example, color( float, float, float ) in place of color3f( float, float, float ).



Unfortunately, this doesn't work for vertex2fv versus vertex3fv - they both expect float[], just with different lengths. So, at least for ?v calls, suffix has to stay - but if it stays for them, it should probably stay for all methods.

I have modified composable pipeline class to generate ShortGL wrapper, which contains names without prefixes. Unfortunately, due to reflection-only way it works, parameter names are lost, which IMHO is not worth the gain from more clear method names. If at some point composable pipeline will become full GlueGen-based stage, then we can get back to that idea.

Artur Biesiadowski
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #16 - Posted 2003-06-25 19:23:40 »

You could never get rid of the signed/unsigned "u" suffix either...

Hellomynameis Charlie Dobbie.
Pages: [1]
  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.

Dwinin (28 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (74 views)
2014-09-10 06:39:09

Tekkerue (38 views)
2014-09-09 02:24:56

mitcheeb (57 views)
2014-09-08 06:06:29

BurntPizza (45 views)
2014-09-07 01:13:42

Longarmx (28 views)
2014-09-07 01:12:14

Longarmx (34 views)
2014-09-07 01:11:22

Longarmx (35 views)
2014-09-07 01:10:19

mitcheeb (40 views)
2014-09-04 23:08:59
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!