I dunno why that reminds me of this. Word association I guess.
I have done my best to ease this task in case someone really needs to do it, especially in the pre-beta version in which almost all references to classes relying on JOGL are done in the main class. It’s under GPL v2 after all, feel free to do so; while you respect the license, I won’t complain.
Please stop FUD.
[quote]rc11 packages have been pushed to the staging repositories for Central
[/quote]
Source: http://forum.jogamp.org/Release-v2-0-rc11-tp4026703p4026731.html
There is still something wrong, I’m really sorry, the push takes age to end:
[quote]… but I’m still waiting for the pushed packages to be synced to the Central repository. I’m not sure what’s taking so long…
[/quote]
http://forum.jogamp.org/Release-v2-0-rc11-tp4026703p4026755.html
You have to replace some classes using the renderer based on JOGL 2.0 by their equivalents based on its competitor in this class:
http://tuer.svn.sourceforge.net/viewvc/tuer/pre_beta/engine/service/Ardor3DGameServiceProvider.java
At first, you have to replace JoglNewtFocusWrapper, JoglNewtKeyboardWrapper, JoglNewtMouseManager and JoglNewtMouseWrapper by their equivalents based on the binding of your choice.
Then, you have to retrieve the width, the height and the bits per pixel without using NEWT which should be trivial.
After that, if you want to port JFPSM too, you will only have to replace com.jogamp.common.nio.Buffers by something else (plain standard Java or an helper coming from the binding you use) which is trivial again.
Finally, you will have to modify the Ant script. I advise you to take as an example an older revision that does not use the automatic extraction and loading of native libraries from JARs as you won’t rely on a feature coming from JogAmp. You have to replace all references to GlueGen, JOAL and JOGL resources by their equivalents… When you’re ready, you’ll be able to use this script to generate all signed JARs and the JNLP files.
Yes, LWJGL needs NEWT! Time for you guys to bury the hatchet, preferably somewhere other than each others’ skulls! 
You can mix NEWT with the competitor of JOGL or port it, both use similar licenses.
The fun thing would anyways be, that you couldn’t be able to use the NEWT multi-window feature because LWJGL is all static. And then it would even make no sense, because when you built the stuff in LWJGL from static to instanced, then you’d have a small part of JogAmp…
If you want NEWT you’d just go with JOGL/JogAmp ;D
As soon as I know, they plan to fix this design flaw in the third version. you’re right to point out this aspect. “all static” drives it simple/simplistic which is nice for newbies but it has a cost. JogAmp and its competitor already share some classes, we borrowed some classes (for projections) and they did it too (Java GLU implementation).
I have just removed some references to com.jogamp.common.nio.Buffers from JFPSM. I will try to move the mechanism that retrieves the screen size and the bits per pixel into Ardor3D. If you want, I will add an option allowing to restart TUER with the third version of the competitor of JogAmp when it is ready.
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.
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.
[/quote]
Yes multiple contexts are supported.
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. 
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 
[quote=“gouessej,post:29,topic:39904”]
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.
[quote=“gouessej,post:29,topic:39904”]
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.
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. 