:)Thanks everyone for all the replies and also the clarifications on the license agreement etc.

From what I read I seem to be wrong about most of what I thought I understood about JOGL and LWJGL . It makes me happy because it means that I may be able to accomplish what I set out to do, but it also makes me puzzled because if JOGL and LWJGL are that solid how did I fail that miserably at digging up this information?

I am not good enough to actively contribute to these libraries, but I hope that this post can help others who use them avoid making the same mistakes/assumptions that I did.

In any case I will take some time to look into all the resources you have described. If I succeed I will post some sample code and if I fail I will post some sample code, so don't expect this thread to close just yet.

gouessej:1st: Sorry that I offended you. Obviously JOGL is a very solid library in terms of content and performance. However, isn't it a waste that such important and unique functionality (direct access to the graphics card) is made inaccessible unless I buy into the authors vision of what my program should look like? What if I don't want your timer? What if I want to render in the thread that I choose? What if I just want to send OpenGL instructions to the card? All of that potential lost for what? Achieving the highest possible frame rates? Protecting programmers from their own mistakes?2nd: You came with a lot of suggestions for further exploration. Thanks for pointing out why to use JOGL 2 and not 1.1.1. I will definitely check JogAmp forums, the J2D implementation and LibGDX. I'll check the documentation and also do some surgery on the source code.

princec:That is great news! I must have been living under a rock during the last year or so - or perhaps this was possible all along?

Hi everyone. I have a task that I need to complete involving JOGL and since I have tried everything I thought this may be the place to go. Could any one of you seasoned Java OpenGL programmers give me some leads?

Here is the task:Create a wrapper class for rendering that is Graphics API agnostic i.e. can be extended to wrap JOGL/LWJGL/Java2D etc...

Progress so far:Java 2D: No help needed - Wrapping Java2D is simple because it is completely unintrusive and true to Java concept and generally well designedLWJGL: No help needed - Wrapping LWJGL is relatively straight forward since it is unintrusive and allows calls to the OpenGL methods at any time and because it does not put restrictions on timing and threading. However it is built around the assumption that there is only one display and it has an, in my opinion, unwarranted crush on static classes (c++ fetish).JOGL: This is where I need help - JOGL is *edit* difficult *edit* to wrap because it is built on the assumption that the renderer is the center of the universe and that I want to inject API specific code in callback method inside my game code.

To save some time:Q: Why not just use an older version of JOGL?A: Of course this is possible but then I would miss out on any bug fixes that has happened in the meantime. Reverting to an older version of JOGL is the very last option here.

Q: Why not just have a method in the wrapper interface returning the appropriate callback strategy object forwarded by the underlying API.A: 1) It's a matter of who is potential employer and who is the potential employee: "Don' call us - we'll call you". The graphics is a peripheral that the core may want to use, not the other way around 2) It does not remove API-specific code from the game code.

Q: Why not just skip JOGL and use LWJGL instead.A: 1) LWJGL does not allow me to render to separate windows 2) It has a large disk-space footprint (I may not need half of the files included in the library) 3) It requires me to put a license notice on my game/application 4) It is completely built around static classes. This means that no matter how cleanly I wrap it, any part of the application could still make direct calls to static classes and screw things up.

So what does the wrapper interface look like?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

publicinterfaceRenderer {

publicvoidstartRendering();// must be called before any graphics instructions are executed at the beginning of each render // When extending Java2D this would secure the Graphics object of the image used for drawing, and for JOGL it would probably secure the graphics context publicvoidfinnishRenderingAndRefreshDisplay();// must be called at the end of any series of graphics instructions at the end of each render// When extending Java2D this would release the graphics object and blit a buffered image to the display, for JOGL it would probably release the context and refresh the display

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