JOGL exposed (Cross post from java.net)

[jbanes]

Hi guys! I finally got ahold of some JavaDocs for JOGL (thanks Mind2Machine!) and I find that my initial reaction is a bit mixed. Is it just me, or does the API seem to expose too much system specific stuff? For example, the DDS reader deals with DirectDraw surfaces while XVisualInfo deals with an X11 specific structure. On top of that, we have some really odd looking APIs that seem like quick "we need that!" jobs. The DurationTimer is a perfect example. We are somehow supposed to guess that it's a thin wrapper for System.currentTimeMillis() and that in the future it won't change to some other timing than 1/1000 of a ms. (Or will it?)

To the JOGL guys: Do you consider these API calls complete, or do you mind if I throw a few "clean" APIs your way?

(Please forgive my crossposting, but I realize that a lot of people still can't  ead java.net.)

[jbanes]

I've put the JOGL docs up on the web at http://java.dnsalias.com/jogl

[Orangy Tang]

Just a small note (which i just stumbled across myself after downloading Mind2Machines package) - the DefaultGLCapabilitiesChooser page is broken. Looks like something (javadoc?) truncated the filename - changing it from the .ht to .html works file

[jbanes]

Fixed. Thanks for pointing that out OT.

[rgrzywinski]

I was personally hoping that DurationTimer was a left over turd that didn't get removed before it was moved from intermal to java.net.  It appears to have no dependencies.

There is a real problem with the net.java.games.util package as it screams for namespace collision with other projects.  These are the things that late painful nights of hair pulling are made from.  All packages for jogl should be under net.java.games.jogl.  The whole push to java.net appears to be slapdash.  For example, the jinput classes are in the net.java.games.input package.  Oye!

If people want to add useful items such as a high resolution timer, they should go either in a common or util project and package (jutils may be a good start).  This is obviously MHO but a similar structure has suited the Jakarta people just fine and that's a massive project that must have had similar problems.

[ckline]

To the JOGL guys: Do you consider these API calls complete, or do you mind if I throw a few "clean" APIs your way?

Hi jbanes,

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.

Did you have any problems with platform-specific stuff being exposed in the core java.net.games.jogl package classes? We went to great pains to hide all the system-specific stuff there, so hopefully you'll find that clean.

And yes, *please* suggest better APIs. The new site is getting there piece by piece; it looks like we can add forums now; as soon as we figure out which forums to add we'll enable them and then you can begin posting your ideas there.

-chris

[Orangy Tang]

Well after some tinkering  I managed to get the Gears demo up and running, very little work required - found a good pixel format on its own, seemed to work straight out of the box

Is there a high res timer planned? This is currently a major ommision I think, its pretty much essencial for game programming. Perhaps theres some existing code that can be borrowed?

The JCanvas is a nice idea, even if the performance is horrible its nice to have something that will play nice with Swing. I can imagine it being handy for embedded small views (mini wireframe images in a menu?). For the most part mixing the heavyweight canvas with Swing probably isn't going to cause too many problems - j3d.org seems to have covered this pretty well anyway

ckline: Any idea when we'll be able to see these demos? They sound like they could be handy in showing the proper use of the API..

[Anonymous]

I don't have an ETA on the demos, but hopefully as soon as possible. I would suggest contacting kbr (Ken Russell) on the java.net forums; he's the one putting them together.

The reason for the delay is that some of the demos use a UI toolkit that Ken wrote, which is available under the BSD license but Sun wants to make sure that everything is legally kosher before posting it. They don't want any sort of legal problem that could haunt developers down the road.

Sorry for the delay. Once the lawyers get involved, everything takes longer. But hopefully it's in the best interests of everyone.

-chris