JOGL Wrapper Challange

OpenGL Development
#1

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 designed
LWJGL: 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.

Before you start sending me links about “Active rendering” let me declare which resources I have already used and why they do not work:

  1. http://www.java-gaming.org/topics/active-rendering-with-jogl/17661/view.html
    The instructions are outdated and do not work with the latest version of JOGL
  2. Pro Java™ 6 3D Game Development: Java 3D™ chapter 15
    The instructions are outdated and do not work with the latest version of JOGL
  3. http://forum.jogamp.org/Regarding-active-rendering-of-JOGL-td2989970.html
    This thread lack helpful instrutions
  4. http://www.java-gaming.org/index.php?topic=21559.0
    The instructions are outdated and do not work with the latest version of JOGL
  5. http://www.java-gaming.org/index.php?topic=21050.0
    The instructions are outdated and do not work with the latest version of JOGL
  6. http://forum.jogamp.org/Rendering-without-callbacks-td2259774.html
    The instructions are outdated and do not work with the latest version of JOGL
  7. http://stackoverflow.com/questions/7420027/jogl-how-can-i-create-my-own-opengl-context-and-bind-it-to-a-glcanvas
    Does not deal with JOGL2/does not solve the issue
    8.) http://www.java-gaming.org/topics/jogl-design-issues/19099/view.html
    StrideColossus makes several valid point and no one seem to get it. Instead of solving the problem he seems to settle with an LWJGL implementation which is not what I am looking for.

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?


public interface Renderer {
    
    public void startRendering();
    // 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                                       
    public void finnishRenderingAndRefreshDisplay();
    // 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

    public void drawImage(int x, int y, Alignment al, ImageResource img)
    // Graphics instructions 1
    
    public void drawText(int x, int y, Alignment al, String text);
    // Graphics instruction 2

    // ... more graphics instructions ...
}

Simple enough?

NB! There is also a wrapper for the actual windows/GUI rectangles that owns the renderer, but this is not relevant to the problem discussed.

Thanks in advance for any replies!

#2

Using the [ code ] tag:


System.out.println("hello jgo!");
#3

Thanks Riven,

I could modify the original post using your instructions.

#4

Issues and fixes in JOGL and LWJGL are independent. Therefore point #5 makes no sense :point:

#5

I see,

I’ve now corrected this in the post (I also corrected some bad spelling…)

#6

Rather go to the official forum of JogAmp if you still need some help with JOGL 2.0. However, if you use the term “biatch” to speak about one of our APIs, you won’t get any answer. JOGL 2.0 already provides an hardware accelerated Java2D implementation as a separate project.

JOGL 1.1.1a is no more maintained and it might not work on any OS whose version has been released after 2010.

Why not using LibGDX and helping us to implement a backend based on JOGL 2.0?

#7

You can render to as many windows as you like in LWJGL. The Display class however is optimised to the general use-case of a game, which is where you have just one, that is likely to take over the whole display.

Cas :slight_smile:

#8

Slight aside - is that possible without using AWTGLCanvas? Or at least without requiring use of the EDT?

#9

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?

#10

The problem is not only about me. Several people have contributed to this project for several years (and even more than ten years if we include GL4Java and Jungle, 2 ancestors of JOGL).

You’re completely wrong about JOGL 2.0. It is possible to perform active rendering without using GLEventListener, this is actually what is done in Ardor3D, both in the renderer based on JOGL 1.1.1a and on mine based on JOGL 2.0 pre-RC11. JOGL contains some abstractions, some layers, they allow to ensure that people don’t do bad things but most of the time you’re not forced to use them. You can create a texture in the “old” way or you can use the Texture class, you can choose which thread is used for rendering with NEWT and setEDTUtil(). There is no build-in timer in JOGL as far as I know. You can get a reference of a context, make it current and send OpenGL instructions to the card but if you do it in a way that is not supported by your hardware, wrong things will happen and it won’t be caused by JOGL. JogAmp APIs take the best of the both “approachs”, most of the time there are an low level access and an high level API. It is possible to achieve the highest possible frame rate with JOGL. The abstractions do not get in your way of doing so. What you say is completely wrong and almost all my suggestions were already true when JOGL 2.0 did not yet exist (except NEWT and GLG2D). There is nothing lost. JOGL 2.0 contains both a Java binding for the OpenGL API and for the OpenGL-ES API, working fine both in desktop and embedded environments, even on a Raspberry Pi and a PandaBoard. Look deeper at our APIs in order to avoid writing so wrong things about them.

GLG2D is here:

#11

Been possible for quite some time, but I’ve never personally had any need for it (being a games developer) so I can’t tell you off the top of my head the way to do it right now. I’m not even sure if AWTGLCanvas is the preferred approach or not.

Cas :slight_smile:

#12

It does not. Old versions of the BSD license had the obnoxious “advertising clause”, but that was removed a long time ago. http://www.lwjgl.org/license.php

The static API is, well, just the way it is. OpenGL itself is not very nice that way, LWJGL doesn’t try to fix that.

#13

Not ? Well I’m not that good with these legal texts; what does

[quote]Redistributions in binary form must reproduce the above copyright

  • notice, this list of conditions and the following disclaimer in the
  • documentation and/or other materials provided with the distribution.
    [/quote]
    mean ?
    I would always have a folder for this stuff with README, LICENSE, CREDITS and a 3rdparty subfolder with openal, lzma, jogl and jinput license
    I just copied the whole folder from a lwjgl jar
#14

I don’t want to turn this into a competition, because JOGL really does have a lot to recommend it, but JOGL has exactly the same terms. Word for word. http://jogamp.org/git/?p=jogl.git;a=blob;f=LICENSE.txt

#15

All you need to do is include the text files in your redistributions if you use any LWJGL binary code or code derived from LWJGL. Not exactly a big deal. It’s not like we get upset if you forget either.

Cas :slight_smile:

#16

Thank you, this just answered a question I asked Riven about the Sync.java…

EDIT: Does this mean I have to include the license.txt somewhere in my project? Or does it mean I have to only include the comment at the top and the authors at the top of the file?
Also, does it need to be in the same package?

#17

What you have to do is described in the license itself :slight_smile:

Cas :slight_smile:

#18

That’s nice. I would even prefer all JogAmp APIs to be double-licensed under GPL or at least LGPL.

#19

:)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.