Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  JOGL vs LWJGL and the best way to start learning  (Read 15855 times)
0 Members and 1 Guest are viewing this topic.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #30 - Posted 2012-11-04 20:33:19 »

The fact that LWJGL is 'all static' doesn't impose any limitation (as an OpenGL wrapper) because OpenGL itself is 'all static' as well.

Using OOP for window-management however, make perfect sense.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Danny02
« Reply #31 - Posted 2012-11-04 20:35:59 »

The fact that LWJGL is 'all static' doesn't impose any limitation (as an OpenGL wrapper) because OpenGL itself is 'all static' as well.

mm I would say the opposite, if I have understood how GL contexts work.

Can you have multiply OpenGL contexts with lwjgl?
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #32 - Posted 2012-11-04 20:38:24 »

mm I would say the opposite, if I have understood how GL contexts work.

Can you have multiply OpenGL contexts with lwjgl?

OpenGL contexts are all static too... Everything about the OpenGL API is static.

http://lwjgl.org/javadoc/org/lwjgl/opengl/GLContext.html

Quote
This class is thread-safe in the sense that multiple threads can safely call all public methods. The class is also thread-aware in the sense that it tracks a per-thread current context (including capabilities and function pointers). That way, multiple threads can have multiple contexts current and render to them concurrently.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #33 - Posted 2012-11-04 21:11:00 »

mm I would say the opposite, if I have understood how GL contexts work.

Can you have multiply OpenGL contexts with lwjgl?
Yes multiple contexts are supported.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #34 - Posted 2012-11-05 00:11:39 »

I like the fact that LWJGL is a 1-1 binding to the native OpenGL API.  I do like first-class object-oriented graphics contexts, and think they're a better way to think about a lot of the stateful bits, but that's something a pure java layer could do without much additional overhead.

Ultimately it doesn't make a hell of a lot of difference in the end, you still have to deal with the awesomely crufty and awkward API that is OpenGL either way.  Tongue

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2012-11-05 00:48:18 »

It beggars belief how people can so thoroughly misunderstand OpenGL context management, still, after all these years. Though I suppose some people were about 6 years old when we first made LWJGL. One born every minute and all that.

Cas Smiley

Offline Spasi
« Reply #36 - Posted 2012-11-05 03:05:46 »

As soon as I know, they plan to fix this design flaw in the third version.

It wasn't a design flaw, it was a design choice to keep the native window implementation simple. Multiple contexts have been supported for a long time through AWT. A lot of things will obviously change in the next major release, but the current architecture has worked pretty well for a lot of people.

"all static" drives it simple/simplistic which is nice for newbies but it has a cost.

What cost is that exactly? With JogAmp you need to pass GL instances around, whereas LWJGL uses a ThreadLocal to store context data. If you mean the TL access, that's dirty cheap. Last time I checked, the method call overhead in LWJGL is lower than JogAmp on all GL calls. Mostly by a small margin, but JogAmp can be up to twice slower on GL calls that accept buffers (e.g. glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS, buffer)). Not that it matters at all for properly written GL code, except maybe on low-power devices.

Offline ra4king

JGO Kernel


Medals: 345
Projects: 3
Exp: 5 years


I'm the King!


« Reply #37 - Posted 2012-11-05 03:34:50 »

Slightly off-topic: the example on the ThreadLocal javadocs has a tiny bug: they used "uniqueId.get()" instead of "uniqueNum.get()". Where do I report this?

Offline nsigma
« Reply #38 - Posted 2012-11-05 09:45:24 »

Slightly off-topic: the example on the ThreadLocal javadocs has a tiny bug: they used "uniqueId.get()" instead of "uniqueNum.get()". Where do I report this?

I read that 3 times before I noticed the bug even after you'd said what it was!  Emo

Try http://bugs.sun.com/ - love they keep the Sun domain for broken stuff.  Cheesy

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Spasi
« Reply #39 - Posted 2012-11-05 09:50:42 »

Where do I report this?

It's already fixed in the Java 7 docs.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #40 - Posted 2012-11-05 20:02:13 »

It wasn't a design flaw, it was a design choice
It's a matter of viewpoint.

What cost is that exactly? With JogAmp you need to pass GL instances around
It depends on what you mean. You can get it from anywhere as soon as the context is current, you don't need to pass it.

, whereas LWJGL uses a ThreadLocal to store context data. If you mean the TL access, that's dirty cheap. Last time I checked, the method call overhead in LWJGL is lower than JogAmp on all GL calls. Mostly by a small margin, but JogAmp can be up to twice slower on GL calls that accept buffers (e.g. glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS, buffer)). Not that it matters at all for properly written GL code, except maybe on low-power devices.
JogAmp is not twice slower.

Offline ra4king

JGO Kernel


Medals: 345
Projects: 3
Exp: 5 years


I'm the King!


« Reply #41 - Posted 2012-11-05 23:42:38 »

Oh sweet!

Offline Spasi
« Reply #42 - Posted 2012-11-06 01:02:41 »

JogAmp is not twice slower.

Feel free to test it yourself: LWJGL test - JogAmp test

My results (Win 8 x64, Java 8 x64 Server VM, i5 Sandy Bridge 3.1GHz, latest AMD drivers):

LWJGL - glGetInteger - 18ns
LWJGL - glDepthMask - 12ns
LWJGL - glColor4f - 13ns

JogAmp - glGetInteger - 42ns (58ns with int[] instead of IntBuffer)
JogAmp - glDepthMask - 14ns
JogAmp - glColor4f - 14ns

Again, these numbers don't mean anything in practice for real GL code, just want to back up what I said earlier with some data.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #43 - Posted 2012-11-06 09:46:18 »

I am sober now. Porting TUER to LWJGL suddenly seems like the most amazingly f**kwitted idea I ever had.
I might port JOGL to LWJGL though, which would be funny.

Cas Smiley

Offline nsigma
« Reply #44 - Posted 2012-11-06 09:57:10 »

I am sober now.

Wow, did it really take you three days to sober up?!  Tongue  (actually, reminds me of a friend's recent stag do, but I digress )

Porting TUER to LWJGL suddenly seems like the most amazingly f**kwitted idea I ever had.

Ah, but sir, I believe we have it in writing that you're going to do this ...  Wink

I might port JOGL to LWJGL though, which would be funny.

Port NEWT to LWJGL - that would actually be useful and fun (no guarantees given on the latter!  Grin )


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

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #45 - Posted 2012-11-06 10:48:02 »

LWJGL does need a fundamental overhaul of its display architecture, but really, it'd be nice if there was an AWT system that was lightweight and well designed enough to Just Work with LWJGL in the first place. NEWT may indeed be a good start.

Cas Smiley

Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #46 - Posted 2012-11-07 09:57:49 »

Isn't JOGL the same as LWGJL except without the LWGJL code?(As in, the display). So, basically, the JOGL is like OpenGL, and LWGJL is that and extra?  Huh

Smiley
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #47 - Posted 2012-11-07 10:17:39 »

JOGL is a bit like the OpenGL part of LWJGL, except it's got the irritating requirement of passing round a redundant "gl" instance everywhere, which from the API perspective, is plain wrong, and why we didn't just throw up our hands in the air and abandon LWJGL when JOGL was "officially" announced by Sun.

Cas Smiley

Offline Varkas
« Reply #48 - Posted 2012-11-07 13:15:58 »

Inspuired by this thread I decided to set LWJGL up and see if I can get a small demo to run with it. Took about half an hour and worked without problems. I think this is a fairly good time for setting up a new framework, so I can recommend it at least from this point Wink

Now on to make something serious with it ...

Edit: Something makes me feel like saying "Thanks for the new toy!"   ... regardless if it fits this thread or not Grin

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline matheus23

JGO Kernel


Medals: 107
Projects: 3


You think about my Avatar right now!


« Reply #49 - Posted 2012-11-07 14:37:51 »

Isn't JOGL the same as LWGJL except without the LWGJL code?(As in, the display). So, basically, the JOGL is like OpenGL, and LWGJL is that and extra?  Huh
JOGL is a bit like the OpenGL part of LWJGL, except it's got the irritating requirement of passing round a redundant "gl" instance everywhere, which from the API perspective, is plain wrong, and why we didn't just throw up our hands in the air and abandon LWJGL when JOGL was "officially" announced by Sun.

Cas Smiley

WHAAA?!?

Why people why???

Yes, JOGL is not that much of a library... It has "only" got NEWT, works also with AWT, and wraps Input and OpenGL... Then it also "only" adds utility classes for something like Framebuffers, VBO's and includes a rendering loop and an FPS counter... (Let's leave out the math utilities)

But yeah... Then there is also JogAmp, which is, what it should be called, and which is actually even another story...



I'm NOT comparing LWJGL with "JOGL". I'm complaining about people thinking that "LWJGL" would be a "Game Engine" and JOGL being an "OpenGL wrapper"...
Neither of them is "only" an OpenGL wrapper nor a Game Engine!

And, NO PRINCEC, JOGL is NOT "like the OpenGL part of LWJGL". It IS more.
And nope, nobody wants one to throw the hands in the air and abandon LWJGL.

I now get why people from JOGL get angry about such storys...  Cranky

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

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #50 - Posted 2012-11-07 15:20:42 »

And, NO PRINCEC, JOGL is NOT "like the OpenGL part of LWJGL". It IS more.
Its not more its less, JOGL is just an OpenGL wrapper (with native windowing) LWJGL is a OpenGL, OpenAL and OpenCL, JInput wrapper (with native windowing). So technically you can say it is like the OpenGL part. Smiley

Oh and for clarification, Jogamp != JOGL but includes JOGL as a part.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #51 - Posted 2012-11-07 15:21:37 »

I stand by precisely what I have said.

Cas Smiley

Offline matheus23

JGO Kernel


Medals: 107
Projects: 3


You think about my Avatar right now!


« Reply #52 - Posted 2012-11-07 15:26:41 »

Yeah I understood what you said there now with it being the openGl part...

But it's really not nice to do so, because these guys are talking about JogAmp actually, they just don't know that that would be the right name for it.

Also, you should say "JOGL [like] is the OpenGL part of JogAmp" not LWJGL.

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: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #53 - Posted 2012-11-07 15:34:46 »

I'm really not sure where the confusion arises. JOGL is JOGL and the question was about JOGL not JogAmp, and compared with "the OpenGL part" of LWJGL. And they are orthogonally equivalent give or take a couple of utilities and the aforementioned ghastly object-oriented hammer/nail paradigm.

Cas Smiley

Offline matheus23

JGO Kernel


Medals: 107
Projects: 3


You think about my Avatar right now!


« Reply #54 - Posted 2012-11-07 15:39:59 »

I'm really not sure where the confusion arises. JOGL is JOGL and the question was about JOGL not JogAmp, and compared with "the OpenGL part" of LWJGL. And they are orthogonally equivalent give or take a couple of utilities and the aforementioned ghastly object-oriented hammer/nail paradigm.

Cas Smiley

And in the end you didn't even mention, that JOGL is not the whole story. That'd be nice.

The reader propably wouldn't even know that you are actually not talking about the JogAmp project, which the reader propably thought JOGL would be, but JOGL.

So to the reader:

Yes, JOGL is only a OpenGL wrapper with a windowing system, called NEWT, which got input management, another windowing system based on AWT and a game loop.

But JOGL is only a part of JogAmp and JogAmp actually consists of:
  • JOGL
  • JOAL (OpenAL wrapper)
  • JOCL (OpenCL wrapper)
  • Many other utilities, like math utilities, some helpful classes for wrapping OpenGL stuff like, the Framebuffer or the VBO.
[size=8pt]
In the end I'd personally even say that JogAmp has much more "features" than LWJGL. You can argue about the GL instance and whether those features are redunant or not, but it seems to be a fact.[/size]

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: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2012-11-07 15:42:46 »

I'm sure JogAmp has more features than LWJGL. LWJGL is not meant to have many features in it because those features are usually implemented in a way that someone else would like to do differently.

This being a forum full of programmers that program in a language that complains that This is not equal to this and you're surprised that I give a very specific answer to a very specific question?

Cas Smiley

Offline matheus23

JGO Kernel


Medals: 107
Projects: 3


You think about my Avatar right now!


« Reply #56 - Posted 2012-11-07 17:24:23 »

The only problem I had was that it was misleading: You didn't point out that JOGL is only a part of the JogAmp project.

Yes, the answer was very specific, but you should give more information, so the reader actually learns something.

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: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2012-11-07 18:38:36 »

Didn't really cross my mind to be honest.

Cas Smiley

Offline gouessej
« Reply #58 - Posted 2012-11-07 22:15:07 »

matheus23 is right, there is some helper classes to manipulate FBO, create textures, draw curves and texts directly on the GPU, simulate the fixed pipeline, display video, ... JogAmp works fine on Raspberry Pi, it has been fully tested on lots of embedded devices, xranby can confirm that, it has an homogeneous support of OpenGL-ES. JogAmp is fully modular, you can deploy only what you need by using "atomic" JARs. All experts with whom I have worked find JogAmp very good and agree with our design choices, especially the interfaces (GL2, GL2GL3, ...). You cannot compare JOGL with its competitor, it is more fair to compare it with JogAmp or to compare its OpenGL part with JOGL. Even JOGL is much more than a "simple" OpenGL wrapper.

The benchmark is flawed, just disable caching in the competitor of JOGL and you will probably get the same results. We advise to cache constants externally, like in Ardor3D (see JoglContextCapabilities).

Offline sproingie

JGO Kernel


Medals: 202



« Reply #59 - Posted 2012-11-07 23:05:46 »

It's 17 less keystrokes to type "LWJGL" instead of "The Competitor of JOGL".  I'll add that the apparent maturity level of the developer community is a large consideration when choosing a platform.
Pages: 1 [2] 3
  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.

BurntPizza (21 views)
2014-09-21 02:42:18

BurntPizza (15 views)
2014-09-21 01:30:30

moogie (18 views)
2014-09-21 00:26:15

UprightPath (25 views)
2014-09-20 20:14:06

BurntPizza (27 views)
2014-09-19 03:14:18

Dwinin (43 views)
2014-09-12 09:08:26

Norakomi (73 views)
2014-09-10 13:57:51

TehJavaDev (97 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!