Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
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 Wrapper Challange  (Read 2610 times)
0 Members and 1 Guest are viewing this topic.
Offline ElusiveCreator

Junior Newbie





« Posted 2012-10-14 02:34:04 »

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?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
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!
Online Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2012-10-14 02:44:59 »

NB2! Could someone please give me a hint how to properly paste code in agreement with forum rules?

Using the [ code ] tag:

1  
System.out.println("hello jgo!");

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ElusiveCreator

Junior Newbie





« Reply #2 - Posted 2012-10-14 02:50:52 »

Thanks Riven,

I could modify the original post using your instructions.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2012-10-14 02:52:43 »

Q: Why not just skip JOGL and use LWJGL instead.
A: ... 5) It may not be completely up to date with the latest changes (bug fixed) in JOGL

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ElusiveCreator

Junior Newbie





« Reply #4 - Posted 2012-10-14 04:13:44 »

I see,

I've now corrected this in the post (I also corrected some bad spelling...)
Offline gouessej
« Reply #5 - Posted 2012-10-14 09:07:38 »

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?

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2012-10-14 10:19:37 »

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 Smiley

Offline nsigma
« Reply #7 - Posted 2012-10-14 11:54:25 »

You can render to as many windows as you like in LWJGL.

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

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline ElusiveCreator

Junior Newbie





« Reply #8 - Posted 2012-10-14 15:29:17 »

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?
Offline gouessej
« Reply #9 - Posted 2012-10-14 21:45:10 »

gouessej:
1st: Sorry that I offended you. Obviously JOGL is a very solid library in terms of content and performance.
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).

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?
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.

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.
GLG2D is here:
https://github.com/brandonborkholder/glg2d

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

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2012-10-15 00:03:58 »

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?
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 Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #11 - Posted 2012-10-16 23:25:04 »

[LWJGL] requires me to put a license notice on my game/application

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.

Offline Cero
« Reply #12 - Posted 2012-10-17 00:24:47 »

[LWJGL] requires me to put a license notice on my game/application

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

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

Offline sproingie

JGO Kernel


Medals: 202



« Reply #13 - Posted 2012-10-17 02:22:18 »

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
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2012-10-17 08:57:08 »

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 Smiley

Offline matheus23

JGO Kernel


Medals: 109
Projects: 3


You think about my Avatar right now!


« Reply #15 - Posted 2012-10-17 12:44:30 »

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 Smiley

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?

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2012-10-17 13:16:31 »

What you have to do is described in the license itself Smiley

Cas Smiley

Offline gouessej
« Reply #17 - Posted 2012-10-17 22:38:21 »

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

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

Offline ElusiveCreator

Junior Newbie





« Reply #18 - Posted 2012-10-18 12:47:11 »

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

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (35 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!