Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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  
  [Announcement] JSR-231 and JOGL  (Read 3186 times)
0 Members and 1 Guest are viewing this topic.
Offline Ken Russell

JGO Coder




Java games rock!


« Posted 2004-12-13 23:13:35 »

JSR-231 (Java bindings for OpenGL) has been in discussion in the expert group for some time now and several technical and specification issues have been resolved. As has been mentioned and discussed in the past, the expert group has been planning to use the JOGL APIs and source base as the starting point for the specification and its reference implementation. We would like to keep the development of the RI as open as possible for many reasons. The community's involvement in the development of JOGL has been significant and the product is much more robust as a result of having many people using, looking at, and contributing to the system. We also want to avoid fragmenting the developer community by having multiple projects implementing similar functionality but with slightly different APIs or semantics. For these reasons evolving the JOGL source base toward the JSR-231 API set seems like a good approach to take.

Our current thinking is to create a branch of the JOGL sources on java.net with a tag such as JSR_231_DEVEL. This branch would not become the default (yet), but anyone could check out the sources under it. Implementation of the JSR 231 APIs would occur under this branch. The community could see, test, and comment on the APIs as they are committed. At some point there would be a poll to fold this branch into the main JOGL trunk. This would probably not occur until the JSR 231 APIs are very close to being finalized.

Stability and other robustness issues in the JOGL project are still very important. We aren't planning to halt work on trying to make the project more stable and full-featured, but do want to start the changes in the implementation that will be required to support the full JSR 231 spec while trying to preserve and also improve the overall robustness and portability of the system.

What do you all think about this plan? Assuming the response is positive, we plan to create the new branch within the next few days.

Offline Rob Nugent

Junior Devvie




May contain nuts


« Reply #1 - Posted 2004-12-14 03:39:10 »

Ken,

This sounds like it's probably great news, and good to hear that JSR-231 is still alive.

It'd be a bit easier to comment further if  there was any spec for JSR-231 available to give some clue as to what direction we might be headed. I took a quick look on the www.jcp.org pages for JSR-231 but couldn't find anything public yet. Is there anything that can be shared with us yet ?

Rob
Offline nnevatie

Junior Devvie




It is slightly better to be simple than correct.


« Reply #2 - Posted 2004-12-14 04:31:10 »

Quote
Ken,

This sounds like it's probably great news, and good to hear that JSR-231 is still alive.

It'd be a bit easier to comment further if  there was any spec for JSR-231 available to give some clue as to what direction we might be headed.


I agree Rob here. Also, what is the procedure to subscribe to cvs@jogl.dev.java.net mailinglist?

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline rexguo

Junior Devvie




Real-Time Java


« Reply #3 - Posted 2004-12-14 05:09:10 »

I also agree that there should be a JSR-231 spec for
public review before we can comment on this.

While I'm very glad that JSR-231 is moving forward,
I'm not entirely clear why there needs to be a branch
as it obviously will take more manpower to work on
both trunks. I'd love to see a focused effort on a
singular goal instead: it always gives better results.

Lastly, the JSR-231 specifies OpenGL 1.5 as the
target version, but OpenGL 2.0's specs is already
out. So does it make sense to target OpenGL 2.0
instead?

.rex

http://www.rexguo.com - Technologist + Designer
Offline rexguo

Junior Devvie




Real-Time Java


« Reply #4 - Posted 2004-12-14 05:13:20 »

Hi Ken,

I think I speak for alot of people by saying that
the integration of Java2D with JOGL/JSR-231 is
very important for those developing (or planning
to) real-time media applications for desktop Java.

While I've heard from several people from Sun
that this is a goal, I'd love to hear an update of
plans now that JSR-231 is in the picture again.

Thanks!

.rex

http://www.rexguo.com - Technologist + Designer
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2004-12-14 09:15:04 »

I have only one request: try as hard as is humanly possible (no, harder) to make it an SPI!

Don't make the horrendous train-wreck mistakes of java.util.logging, java.util.regex (they damn well should have been SPI'd; no reason not to. But they weren't - and now we have this horrible "it almost compiles when you change implementation, but not quite, because the lack of SPI".

There is, of course, the humongous problem of naming conventions. Off the top of my head AFAICS it is impossible to transparently SPI different naming conventions (that is, after all, the point of SPI: to alter the implementation whilst preserving the method signatures!).

The best I can think of is to have two copies of the API method signatures, BOTH of which drop down to the identical ogl binding that's been plugged in via SPI.

One called something like

  java.opengl.c

the other

  java.opengl.java

where the former uses C notation and naming conventions, the latter uses java. Then, using the SPI, any binding has to implement one, the other, or both. It would be nice if SPI enabled one implementation to trivially implement both, but I'm guessing the SPI mechanism is a lot less "smart" than that and only does plain pass-through of methods (i.e. you can't plugin a translation layer as part of the SPI, enabling it to "adapt" any foreign API into the form of the java-facing API). Preferably, over time, all bindings would end up implementing both.

This would impress the pants off of a lot of people: "not only does java have true OGL access, not only can you port C code almost instantaneously, BUT you also get to gradually upgrade - class by class! - all your non-OOP naming conventions and non-OOP args (raw arrays, no ENUMs, etc) to modern OOP equivalents whilst still using the same underlying library"

Sorry if I'm shockingly naive about SPI...I'm off to refresh my memory on it. Take the above with a sellar of salt modulo my complete misunderstanding of SPI Grin.

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

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #6 - Posted 2004-12-14 12:18:03 »

Very good news. I was a bit worried jogl got killed by politics.

To me, java+opengl seems like a match made in heaven, and the fact that it didn't become part of core java in tiger (as javax.opengl, possibly) struck me as very weird.
Those 3d shockwave games everyone goes "woo" and "aahh" about could be java already.


I won't rush you as I know it won't help (hurry! Wink), but I'm very glad something more official than just jogl seems to finally be happening. =)
Keep us posted.

Play Minecraft!
Offline shaddam_IV

Junior Devvie




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


« Reply #7 - Posted 2004-12-14 15:14:53 »

I too am very excited about this development.  I have two suggestions:

1. Modify the JSR to specify generation of current bindings to follow the latest version of OpenGL.

2. Provide precompiled binaries and libs instead of requiring a source checkout and compile for those of us who want to use the code but not work on it.

Yay for the JSR!

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

JGO Coder




Java games rock!


« Reply #8 - Posted 2004-12-14 20:58:57 »

Quote
Also, what is the procedure to subscribe to cvs@jogl.dev.java.net mailinglist?


Log on to the java.net web site. You need to be an Observer of the JOGL project. Click the Mailing Lists link and click the Subscribe button for the cvs@jogl.dev.java.net mailing list.
Offline nnevatie

Junior Devvie




It is slightly better to be simple than correct.


« Reply #9 - Posted 2004-12-15 01:18:32 »

Quote
Log on to the java.net web site. You need to be an Observer of the JOGL project. Click the Mailing Lists link and click the Subscribe button for the cvs@jogl.dev.java.net mailing list.


Thanks for that information. However, I can't seem to access anything on the site right now. The message I'm constantly seeing is:

"Your account does not have the "Project Page - View" permission needed for you to access the page you requested in the java-net project (view your permissions). Either ask the project administrator for more permission, or log in using a different account"

I remember registering to the site a long time ago, and it used to work just fine (I could use the issue tracker and so on). Who is the project administrator I could ask these permissions from?

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
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 #10 - Posted 2004-12-15 14:35:36 »

Quote
I remember registering to the site a long time ago, and it used to work just fine (I could use the issue tracker and so on). Who is the project administrator I could ask these permissions from?


I am. What's your username on the java.net website? If you don't have your password you'll have to either create a new user account or ask the java.net site admins to reset it, though.
Offline nnevatie

Junior Devvie




It is slightly better to be simple than correct.


« Reply #11 - Posted 2004-12-15 15:40:04 »

Quote
I am. What's your username on the java.net website?


It's same as here (nnevatie). I have no problems logging in with my password but it seems that my permission set is very limited, as I can't really do anything with the account (subscribe to mailinglists, etc.)

Edit: Actually, my permissions are so limited, I can't even view my current permissions (don't have the permission to do that...) Smiley

Thanks in advance!

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #12 - Posted 2004-12-15 15:45:14 »

Quote
It's same as here (nnevatie). I have no problems logging in with my password but it seems that my permission set is very limited, as I can't really do anything with the account (subscribe to mailinglists, etc.)


You're now an Observer of the JOGL project. Let me know via email if you have problems adding yourself to mailing lists, etc.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2004-12-16 21:11:27 »

Here is a fairly long list of decisions already made by the JSR 231 and 239 Expert Groups as well as a couple of issues needing further discussion. Please post your comments.

Some of these issues have been raised on these forums already, such as exposing GLContext in the public API. The expert group decisions were made on the basis of supporting more styles of application rendering (in particular rendering in parallel to multiple contexts on the same drawable) as well as providing lower-level control to applications desiring it. We aren't in a position to publish a specification on these forums yet, but if you subscribe to the cvs@jogl.dev.java.net email list you'll be able to see the checkins that will morph the current JOGL APIs toward the JSR 231 APIs.

Currently the plan is to create a branch of the JOGL source tree under which to do the initial work. Once the APIs have stabilized and they are implemented on all platforms we're planning to revisit the issue of folding this branch back in to the main JOGL trunk, though doing so will break existing JOGL applications since there will be some incompatible API changes.

Decisions that have been made:

  • The C naming conventions for OpenGL functions will be preserved: for example, glVertex3f.
  • The APIs will be window system-independent and not be inherently tied to the AWT. From a practical standpoint this means:

    • Interfaces like GLDrawable which are not tied to a particular AWT component will remain in the public API. However, concrete components like GLCanvas will also remain in the public API.
    • A Service Provider Interface (SPI) will be present to allow new implementations of the GLDrawable interface to be created by vendors. For a concrete example of this see Alex Radeski's notes: http://members.iinet.net.au/~alexr/jsr231-notes.html

  • Platform-specific extensions to OpenGL (WGL, GLX, CGL, EGL) will not be exposed in the public API. Instead, platform-independent abstractions will be provided that bridge these window system-specific APIs.

    • Part of this decision was overturned in a later JSR 239 vote in which the attending EG members voted to expose the EGL interfaces in the public API. Some of the EG members felt that it was only necessary to expose EGL if it wasn't possible to expose all of the EGL functionality in a higher-level API. Even if EGL is exposed, it may still be possible to provide an abstraction layer to provide some source code compatibility between the 231 and 239 specs.

  • GLCanvas and GLJPanel will be made non-final.
  • The GLContext will be exposed in the public API. This decision was made to make it easier to structure certain types of applications as well as to allow more low-level control over rendering. There will be both a low-level and a higher-level rendering layer, the higher-level layer providing the GLEventListener callback mechanism currently present in JOGL. There will be synchronization mechanisms built in to the GLContext to make it possible to implement the current callbacks on top of public APIs.
  • It will be possible to wrap an existing Canvas (or other appropriate GUI element) with a GLDrawable, rather than requiring use of the GLCanvas class.
  • It will be possible to create multiple GLContexts per GLDrawable.

Issues we are aware of that need further discussion:

  • Vendors need to be able to add extensions without changing the public API and thereby causing the signature tests to fail.

    • One way to implement this would be for the vendor to subclass the GL interface into e.g. NVidiaGL and provide the methods and constants corresponding to the new extensions in that subinterface. Users would then be required to downcast the GL interface to NVidiaGL in order to access the extension.
    • Another, possibly better, way to implement this would be to add a method like
      1  [/li][/list]
      public Object getExtension(String extensionName);

      to the GL interface. The user would be required to know the type of the returned Object in order to cast and call methods on it. LWJGL's support for OpenGL extensions is similar to this.
    • The intent would be to fold new extensions into the core GL interface as quickly as possible.

Offline Mikael Grev

Junior Devvie




Appearance is everything!


« Reply #14 - Posted 2004-12-17 01:48:11 »

Ken,  can you contact me at grev (at) javalobby.org.

Cheers,
Mikael Grev

Mikael Grev.
www.migcalendar.com - Advanced Calendar Component
Offline nnevatie

Junior Devvie




It is slightly better to be simple than correct.


« Reply #15 - Posted 2004-12-17 07:10:58 »

Ken, that is truly excellent news!

This kind of information is exactly what the community needs to see.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #16 - Posted 2004-12-17 08:26:53 »

What about any potential synergies between the opengl accelerated java2d in tiger and this new jogl variant?

Like, for example, a GraphicsOGL that extends Graphics2D and lets you paint swing type components on any gldrawable?

I'm aware that's not horribly practical, but being able to do something like render a webpage onto a pbuffer then using that as a texture in a game would be extremely cool.

Play Minecraft!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #17 - Posted 2004-12-17 13:41:06 »

I agree that better interoperability between Java2D and JOGL would be very useful but from a practical standpoint (deadline and manpower constraints) I don't think exactly what you suggest will be implemented in the next release. Still, I am hoping there will be time to continue prototyping sharing the Swing back buffer between Java2D and JOGL when using the OpenGL pipeline for Java2D. We demonstrated this at JavaOne last year with the VertexProgRefract demo from the jogl-demos workspace running inside a JInternalFrame surrounded by lightweight widgets. This kind of functionality is really compelling. It would probably be exposed to JOGL via the JAWT and so wouldn't require many, or any, API changes at the Java level.
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #18 - Posted 2004-12-17 20:02:13 »

I didn't expect that to make the first (or even second) release, but it seems like a worthwile long term goal to me. =)


/me is excited about JSR-231 is a nerdy way

Play Minecraft!
Offline rexguo

Junior Devvie




Real-Time Java


« Reply #19 - Posted 2004-12-18 01:50:59 »

Ken, I realise manpower is always at a premium,
so how about you give us an itemised list of the
things we can help with? I'm sure some of us
will have extra cycles to spare given our obsession
with OpenGL.

.rex

http://www.rexguo.com - Technologist + Designer
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #20 - Posted 2004-12-20 17:13:23 »

Right now the top things we could use help with are

  • Bugs -- the bug list is getting long again. If someone could look more into some of the longstanding issues like there being a dependence on the order of certain operations like adding of the GLCanvas to its parent Frame that would be helpful.
  • NURBS -- I've checked in the beginnings of a port of the GLU NURBS library from C++ to Java. If people could pitch in on that port that would be a great help.
  • GLJPanel -- GKW on these forums has been trying to add hardware-accelerated support for the GLJPanel using pbuffers. Pushing this project through to completion would help a significant number of applications.

I think the JSR 231 implementation work needs to be carried through to a certain point by the expert group and other core developers before we can open it up to contributions from the community. The reason is that we have to firm up the APIs, which will be in flux for a while.
Offline Mithrandir

Senior Devvie




Cut from being on the bleeding edge too long


« Reply #21 - Posted 2004-12-21 03:22:36 »

Ken,

At what point will JOGL officially become an implementation of JSR-231 - or will there always be considered two separate projects. One of the big items is the package being used. At some point JOGL will have to change package if it is going to be an official spec implementation. Alternatively, it could remain a test sand pit for various implementations and retain it's current packages.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #22 - Posted 2004-12-22 17:46:23 »

Quote
At what point will JOGL officially become an implementation of JSR-231 - or will there always be considered two separate projects. One of the big items is the package being used. At some point JOGL will have to change package if it is going to be an official spec implementation. Alternatively, it could remain a test sand pit for various implementations and retain it's current packages.


I don't know the answer to this question. There have been discussions internal to Sun regarding the license of the reference implementation of JSR-231. Until these issues are resolved I can't comment on package naming issues. For the time being the development will continue in the net.java.games.jogl namespace.
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.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (54 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (85 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (79 views)
2014-12-05 12:39:02

SHC (89 views)
2014-12-03 16:27:13

CopyableCougar4 (97 views)
2014-11-29 21:32:03

toopeicgaming1999 (155 views)
2014-11-26 15:22:04

toopeicgaming1999 (153 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!