Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (636)
Games in Android Showcase (178)
games submitted by our members
Games in WIP (687)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / OpenGL Development / Re: JOGL Wrapper Challange on: 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.
2  Java Game APIs & Engines / OpenGL Development / Re: JOGL Wrapper Challange on: 2012-10-14 15:29:17
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.

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?
3  Java Game APIs & Engines / OpenGL Development / Re: JOGL Wrapper Challange on: 2012-10-14 04:13:44
I see,

I've now corrected this in the post (I also corrected some bad spelling...)
4  Java Game APIs & Engines / OpenGL Development / Re: JOGL Wrapper Challange on: 2012-10-14 02:50:52
Thanks Riven,

I could modify the original post using your instructions.
5  Java Game APIs & Engines / OpenGL Development / JOGL Wrapper Challange on: 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:
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
This thread lack helpful instrutions
The instructions are outdated and do not work with the latest version of JOGL
The instructions are outdated and do not work with the latest version of JOGL
The instructions are outdated and do not work with the latest version of JOGL
Does not deal with JOGL2/does not solve the issue
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!
Pages: [1]
Dwinin (72 views)
2015-11-07 13:29:08

Rems19 (81 views)
2015-10-31 01:36:56

Rems19 (77 views)
2015-10-31 01:32:37

williamwoles (107 views)
2015-10-23 10:42:59

williamwoles (93 views)
2015-10-23 10:42:45

Jervac_ (110 views)
2015-10-18 23:29:12

DarkCart (135 views)
2015-10-16 00:58:11

KaiHH (117 views)
2015-10-11 14:10:14

KaiHH (156 views)
2015-10-11 13:26:18

BurntPizza (172 views)
2015-10-08 03:11:46
Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48

Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11 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‑
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!