LWJGL on JOGL

[princec]

I’m not sure that anyone else has twigged yet, but in an idle musing I was talking to Matzon about LWJGL and JOGL. But the general gist of it is:

LWJGL already works on top of JOGL.

It doesn’t take a genius to figure out how this is so. LWJGL is a direct connection to OpenGL. Provided you’ve got a current OpenGL context, you can call OpenGL methods that render into that context.

Now, LWJGL hides away all the context management in a convenient lightweight manner behind the scenes. But if for example you wanted to use JOGL to set up your context and manage page flipping etc. then you can. Trouble is you’ve got all this OpenGL binding baggage in JOGL that you probably don’t want to deploy.

There are a couple of tiny issues in our design that need to be addressed to make it really work well, like our automatic determination of GL capabilities is handled by our context manager rather than the JOGL one; but otherwise - you’r sorted. Swing components and LWJGL can coexist.

I was therefore wondering whether JOGL might split itself up logically into context management and GL rendering API. Which would make sense.

Cas

[alexz]

Interesting in theory, but I don’t see a reason for this in real life. Too few native libraries for your Java project? Want more? No, thanks! :

[princec]

Well, let’s put it in another perspective:

You wisely develop your game in LWJGL because and all is well and good. But then you think, hm, I could do with a level editor or somesuch and I can’t be bothered with writing a huge and complicated GUI in GL. So why not just Swing? And so you can still use LWJGL code to do your game object rendering and have the benefit of Swing controls to manipulate it.

Or:

You want to write a Swing + OpenGL application but are mightily cheesed off with the weirdo kludge design of the OpenGL wrapper in JOGL* But you don’t want to sacrifice AWT and Swing just to use the neato LWJGL API. So you use JOGL’s context management code to integrate cleanly with AWT, and use the LWJGL API to draw into it without fuss.

Cas

• and before you go thinking that’s flamebait, until quite recently the LWJGL API made the same mistakes. But we’ve realised the error of our ways and fixed them

[Markus_Persson]

votes for not spamming lwjgl on the jogl forums

[elias]

That’s a weird response, why not work actively for closer cooperation of the two java GL projects?

• elias

[Markus_Persson]

LWJGL does what it does excellently, but it’s not a pure opengl wrapper… it’s more. As princec said himself, it could very well use JOGL for the opengl wrapper parts.

So if you change LWJGL to do that, great, but informing the people who are using JOGL that they can now also use LWJGL seems to me like purely advertising LWJGL.

And on a personal, slightly trollish note; I prefer the JOGL way.

[alexz]

Cas,

Thanks for explanation. Personally, I will switch to JOGL (it won’t be hard actually) as soon as I do realize that I extremely need Swing + OpenGL for my project. Until then there are other ways to make a level editor.

[princec]

The OpenGL part of LWJGL is a pure OpenGL wrapper. You can tell it’s pure because it will actually work with any other Java OpenGL binding (whereas, none of the other bindings can be used easily with each other). Which makes me think that somewhere along the line there’s a huge effort being wasted; although we’ve deliberately trimmed methods from the LWJGL that make no sense in Java for performance or semantic reasons.

We’ve also been hard at work preparing for 1.5’s static import feature (ok, Elias has ), and for the next release, we’ll be adding some strong memory security to the wrapper to prevent VM crashes caused by sloppy Java programming.

The other bits - input, sound, context management - are by comparison tiny little bits indeed, and all optional of course.

Cas

[gregorypierce]

That really came from out of left field - that’s for sure and I think it warrants consideration. However I think that there are some problems /concerns with this line of thinking.

Personally I’ve always advocated building LWJGL on top of JOGL. It made sense to me then and still does now - despite any acrobatics of dealing with Sun from a legal/business perspective. If LWJGL were to head in that direction (which I’m still pretty sure it won’t based on conversations we’ve had in the past), I think that you’d find a rapid explosion of people using it over raw JOGL.

It is my hope that at some point these two divergent paths can come together and play nicely because LWJGL is mostly where the java gaming development community wants to go. Having hopped back and forth between the two projects I still think that LWJGL is the more mature library of the two - but some of the things that LWJGL wants to do are a bit extreme. The same should be said of the way JOGL is written. There needs to be some middle ground that both projects can reach which is the best of both worlds both in terms of development energy and feature set.

[princec]

Well, let’s put it this way: it only takes one change to one line of code in LWJGL as it stands to work with JOGL, and no lines of code (to my knowledge although I stand to be corrected) to make JOGL work with LWJGL.

Proof of concept likely to follow…

Cas

[princec]

In CVS tonight I’ll be committing org.lwjgl.opengl.GLContext. This is a three method interface:

public void makeCurrent();
public int getWidth();
public int getHeight();

Now, I know it’s in the ever-so-scary LWJGL namespace etc. but is there just a glimmer of a chance some bright spark could copy this interface into JOGL and have the JOGL context class(es) implement it? It’s super tiny and very unintrusive - a mere three methods, two of which are almost certainly trivial to implement. We are guaranteed not to move or change this interface when 0.9 is released at Easter as we’re going into beta finally.

Ideally this would be in a javax.awt.* package of course, but we’re not allowed to do that.

Any takers? Gregory?

Cas

[oNyx]

[quote][…]we’ll be adding some strong memory security to the wrapper to prevent VM crashes caused by sloppy Java programming.[…]
[/quote]
-it just works
-it works and tells you that you have done something stupid
-it works and tells you that you have done something stupid if you use the debug thingy

I think it’s good to know if you have done something wrong… [i]don’t use JFrame.add() use JFrame.getContentPane().add() instead[i] alike ish

But you were about to do it that way anyways right?

edit: grammar++ ._.

[pepe]

[quote]In CVS tonight I’ll be committing org.lwjgl.opengl.GLContext. This is a three method interface:

public void makeCurrent();
public int getWidth();
public int getHeight();

Now, I know it’s in the ever-so-scary LWJGL namespace etc. but is there just a glimmer of a chance some bright spark could copy this interface into JOGL and have the JOGL context class(es) implement it? It’s super tiny and very unintrusive - a mere three methods, two of which are almost certainly trivial to implement. We are guaranteed not to move or change this interface when 0.9 is released at Easter as we’re going into beta finally.

Ideally this would be in a javax.awt.* package of course, but we’re not allowed to do that.

Any takers? Gregory?

Cas
[/quote]
???
if that kind of thing eve r happens to jogl, it will be a great danger. Not that i don’t think it is wise to correct flaws or incapacities, but doing so in such a manner frozes me to the bone.
I’m wondering why you want JOGL to bend to a lwjgl interface. Can’t a request for JOGL to directly implement those methods be correct?

Cas. i’ve been back around here since two or three weeks, and i found myself being reacting mainly to your posts -not in the way of progress, but more to oppose to your sayings. I found -and it seems that i’m not the only one- that you were using troll ways to promote lwjgl. Not that trolling may not be helpful sometimes, but i feel you pass your time doing so in a quite vicious manner.

That JOGL virus interface scares me, wondering what you try to achieve -or worse, trying not to believe what my intuition tells me-.
If that interfacing has to happen, that would mean to me the death of JOGL as a neutral thing.

Maybe it is me. Maybe i don’t understand anything, but i find all this quite intriguing.
Please, explain your goals.

[princec]

My goals are well stated already in this thread, but I’ll just recap:

There are a few API bindings to OpenGL around (JOGL and LWJGL being the main ones), and no one API binding is going to please everybody.

However, underneath all the OpenGL bindings there is a common context management problem that has very little to do with the binding API itself. In LWJGL we solve the problem by supplying our own Window class. SWT provides an SWTGLCanvas. AWT now has JOGL.

Unfortunately at this stage a choice of one context management system leads to lock-in with the GL binding API. If I wanted to use JOGL inside SWT widgets in a standalone Jet applicatoin I couldn’t easily, because there’s no way to use JOGL on SWT with. Likewise I am unable to use the LWJGL API to draw my game on an AWT window with some Swing widgets. Etc.

There are four resolutions to the problem:

a) Troll each other. No code is written. Status quo is maintained. So much for open source, blahblahblah gets the last laugh

b) Carry on as before, with binding/context management lock-in. Choose context management requirements and then be forced to use binding API supplied. Component code written to use LWJGL won’t run on AWT without porting the whole lot, and vice-versa.

c) Each independently produce interfaces to each API. JOGL team produce JOGL-LWJGL bridge component. SWT guy makes SWT-LWJGL bridge component. LWJGL team makes LWJTL-JOGL component. Etc. With 3 context management APIs (so far!) and 2 major binding efforts that’s a lot of duplicated code, plenty of chances for bugs, and no-one’s any the wiser.

d) Agree on one tiny, simple, three method interface. Everyone implements it somewhere sensible - we’ve already put it in LWJGL, it took about half an hour. Provided you get an instance of this interface you can render to it with whatever GL API binding you like.

d) is obviously the solution I’m plugging for, and frankly, I have no time for trolls, only people with a can-do attitude.

Cas

[blahblahblahh]

So if you change LWJGL to do that, great, but informing the people who are using JOGL that they can now also use LWJGL seems to me like purely advertising LWJGL.

I can see this may have made sense to you when you wrote it. I can, however, vouch that it is incorrect - it is not merely advertising. I chose some time ago to use JOGL rather than LWJGL (no need to go into reasons), and do not follow the LWJGL forums.

However, what Cas is proposing is something I would almost kill for - like several others I’m getting really frustrated with some of the problems with JOGL development, and increased modularity would be a great boon; to know I wasn’t trapped into this one monolithic thing.

It would also, if it were carried out well, cause three things to happen:

[] I’d start using LWJGL
[] I’d be more committed to both, because…
[*] …I suspect it would relieve some of the burdens of JOGL that are causing me grief right now

Disclaimer: I realise I may actually by coincidence be the only person who feels this way :). This post is merely an FYI to declare that there are at least some excusively JOGL people who appreciate knowing about this. I’m too ignorant on the bowels of JOGL to have an opinion on whether it’s a good idea; I can only say that what Cas has described is something I’d want, if I could get it.

a) Troll each other. No code is written. Status quo is maintained. So much for open source, blahblahblah gets the last laugh

This, obviously, is the best solution of all. As time goes on, some opensource projects are in danger of making it hard for me to maintain my cries of “in general, opensource projects are rubbish”; at the moment, they’re still sufficiently few in number that I don’t feel too threatened, but of course I’d appreciate a few more counter examples to replenish my current stock.

seems to me like purely advertising LWJGL.

One final thought. What the heck is wrong with open source projects “advertising” to each other’s users? Especially when the advertising is about inter-operability! (I’m not trying to do a thread-jack, this is just a rhetorical question; feel free to steer the linux /opensource thread raging in offtopic by taking a quote from this post if you wish)

To cut a long post short, there are few opensource projects with the courage to post an accurate and fair “competitive comparison” showing other opensource apps trying to solve the same or similar problems. They nearly always tend to be the best ones to go with, because the attitude tends only to be found on a well-run, well-planned project.

[divzero]

I am getting very sick of people pointing fingers and shouting “troll” around here. What on earth is wrong with discussing different options and other open source API’s? Is it that people have chosen their technologies and closed their minds up to all alternatives? There is no need to feel threatened and try to stifle such “radical” suggestions as this one. Open your mind up a little and think of the bigger picture - we are trying to convince the software engineering world that Java is good for making 3D real time applications (by making some!) - not by partaking in some childish API competition.

I think that the closer these two API’s are the better. It makes sense in so many ways, not least of all what Cas was saying regarding maintaining the codebase. Why duplicate effort unnecessarily? What is achieved by sticking with a)?

To cut a long post short, there are few opensource projects with the courage to post an accurate and fair “competitive comparison” showing other opensource apps trying to solve the same or similar problems. They nearly always tend to be the best ones to go with, because the attitude tends only to be found on a well-run, well-planned project.

I could not agree more and I applaud the LWJGL team for always entertaining discussions comparing their technology to JOGL and being frank regarding the limitations and features of both.

Will.

[edit] note to self - spell check before posting :-[

[gregorypierce]

[quote]In CVS tonight I’ll be committing org.lwjgl.opengl.GLContext. This is a three method interface:

public void makeCurrent();
public int getWidth();
public int getHeight();

Now, I know it’s in the ever-so-scary LWJGL namespace etc. but is there just a glimmer of a chance some bright spark could copy this interface into JOGL and have the JOGL context class(es) implement it? It’s super tiny and very unintrusive - a mere three methods, two of which are almost certainly trivial to implement. We are guaranteed not to move or change this interface when 0.9 is released at Easter as we’re going into beta finally.

Ideally this would be in a javax.awt.* package of course, but we’re not allowed to do that.

Any takers? Gregory?

Cas
[/quote]
I’m down. Shoot me an email or PM with what you need me to do. Its pretty straightforward with GlueGen to include some common java code across all of the implementations.

Wow… I can’t believe I used straightforward and GlueGen in the same sentence Love the architecture, but its way obfuscated and not documented in any meaningful manner.

[princec]

I think you won’t even need to fiddle with gluegen…
It looks like all you have to do is get GLCanvas to implement the interface - it already has getWidth() and getHeight() of course from Canvas - and the makeCurrent() call needs to forward to the JOGL GLContext.makeCurrent() call.

In fact it’s entirely possible to completely get away without implementing the interface at all but it makes certain kinds of programming a little more difficult.

Consider a “BSP Rendering Bean”. It will need to be initialised with a context:

bspBean.setGLContext(context);

At which point it will have to determine what GL capabilities the context has so it can configure its rendering paths; it can only do that at init time, of course, if it has the ability to make the context current at the time it’s called. Otherwise you’ve got to defer capability detection until its first call to render().

What’s more it’s pretty important to get the dimensions of the context so you can set the viewport appropriately or you’ll get rendering off the edges of the component. So the bean would need to be able to ask its context how big it was every time it was asked to render.

It seems that a whole load of the JOGL context management appears to be way over the top but it’s so complicated I haven’t had time to figure out why it’s so complicated. I think it’s something to do with rendering thread safety and the AWT thread; but we’ve all gotten used to Swing only working in one thread… so perhaps this area could be cleaned up a bit and simplified? I dunno, but it seems like it should be as simple as the LWJGL way.

Cas

[pepe]

Maybe i’m mistaken, but… Shouldn’t the bean simply be a GLEventListener implementor and add itself to the list of listeners once the GLDrawable is sent to it through its setContext() method?

[princec]

That would start to involve dragging in a lot more complexity and classes and dependencies.

Cas