Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (577)
games submitted by our members
Games in WIP (498)
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  
  LWJGL on JOGL  (Read 3579 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2004-02-02 07:54:54 »

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 Smiley


Offline alexz

Senior Newbie




Java games rock!


« Reply #1 - Posted 2004-02-02 09:53:39 »

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! Roll Eyes
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2004-02-02 10:41:32 »

Well, let's put it in another perspective:

You wisely develop your game in LWJGL because <insert wise reasons here without starting flame war> 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 Smiley

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

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

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #3 - Posted 2004-02-02 11:21:01 »

*votes for not spamming lwjgl on the jogl forums*

Play Minecraft!
Offline elias

Senior Member





« Reply #4 - Posted 2004-02-02 11:56:59 »

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

- elias

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #5 - Posted 2004-02-02 13:54:56 »

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

Play Minecraft!
Offline alexz

Senior Newbie




Java games rock!


« Reply #6 - Posted 2004-02-02 15:17:41 »

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

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2004-02-02 16:30:22 »

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 Wink ), 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 Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #8 - Posted 2004-02-02 17:19:24 »

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.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2004-02-02 20:11:52 »

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 Smiley

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

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2004-02-18 08:55:06 »

In CVS tonight I'll be committing org.lwjgl.opengl.GLContext. This is a three method interface:
1  
2  
3  
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 Smiley

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #11 - Posted 2004-02-18 11:31:34 »

Quote
[...]we'll be adding some strong memory security to the wrapper to prevent VM crashes caused by sloppy Java programming.[...]


-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... don't use JFrame.add() use JFrame.getContentPane().add() instead alike ish Smiley

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

edit: grammar++ ._.

弾幕 ☆ @mahonnaiseblog
Offline pepe

Junior Member




Nothing unreal exists


« Reply #12 - Posted 2004-02-18 13:15:44 »

Quote
In CVS tonight I'll be committing org.lwjgl.opengl.GLContext. This is a three method interface:
1  
2  
3  
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 Smiley

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

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2004-02-18 14:11:22 »

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 Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2004-02-18 15:09:37 »

Quote

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

Quote

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.

Quote

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.

malloc will be first against the wall when the revolution comes...
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #15 - Posted 2004-02-19 01:10:18 »

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

Quote

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  Embarrassed

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #16 - Posted 2004-02-19 01:16:29 »

Quote
In CVS tonight I'll be committing org.lwjgl.opengl.GLContext. This is a three method interface:
1  
2  
3  
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 Smiley



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 Smiley Love the architecture, but its way obfuscated and not documented in any meaningful manner.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2004-02-19 08:52:45 »

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 Smiley




Offline pepe

Junior Member




Nothing unreal exists


« Reply #18 - Posted 2004-02-19 14:29:35 »

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?

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2004-02-19 14:38:04 »

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

Cas Smiley

Offline pepe

Junior Member




Nothing unreal exists


« Reply #20 - Posted 2004-02-19 15:51:00 »

and?
Can you be a bit more precise?
All i see in the event listening is all you'll need to handle anyway, isn't it?

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2004-02-19 18:26:20 »

The more interfaces and classes referenced by each API the more interdependent the two APIs become. I'm trying to get a simple no-brain one-class interface between them working so the chances of anything misbehaving or changing are minimal.

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #22 - Posted 2004-02-19 18:31:13 »

Indeed. All that's needed here is an adaptor class. One that can take one rendering interface and munge it for use by another. Cas, the one thing that I'm somewhat curious about though - does this mean that you will be able to render in an AWT/Swing component? Smiley

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2004-02-19 19:49:55 »

Yes, and this is my prime motivator. Or Swing components rendered over GL drawn components. I'd really like to see it working.

Cas Smiley

Offline pepe

Junior Member




Nothing unreal exists


« Reply #24 - Posted 2004-02-19 21:21:32 »

An Adaptor is the only way to go so that NO API on the extremities are tied to one an other, and always from higher level to lower level.
It may not be part of the gaming initiative, but maybe it would be time to start an adaptor scheme that every low level API creators should take care to be easy to be linked from. That way, everyone using that adaptor would be free to use any underlying rendering API.
Would be cleaner, imho...

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2004-02-19 21:32:52 »

That's pretty much what I'm trying to do, without actually producing an implementation, just mandating the functionality of an interface and giving it a name.

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #26 - Posted 2004-02-19 21:35:59 »

Cas, start a different thread on adaptor based rendering so we can poll the audience and see what they think. What we're talking about here is an easy change and will make it possible for someone to select a renderer from either JOGL, LWJGL, or some bastard jogl-lwjgl two-headed hybrid Smiley In either event, the code is done in my tree. I can't check it in until I get some feedback of the other owners though as it may have some unknown impact - though its just an interface and all I've done is set up GLCanvas to implement that interface.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #27 - Posted 2004-02-20 00:12:23 »

good going, this should really help with the LWJGL port of Xith3d!

Will.

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.

xsi3rr4x (18 views)
2014-04-15 18:08:23

BurntPizza (15 views)
2014-04-15 03:46:01

UprightPath (28 views)
2014-04-14 17:39:50

UprightPath (13 views)
2014-04-14 17:35:47

Porlus (29 views)
2014-04-14 15:48:38

tom_mai78101 (54 views)
2014-04-10 04:04:31

BurntPizza (111 views)
2014-04-08 23:06:04

tom_mai78101 (212 views)
2014-04-05 13:34:39

trollwarrior1 (181 views)
2014-04-04 12:06:45

CJLetsGame (187 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!