I have just forgotten to speak about OpenGL-ES. I have no hardware supporting it with JOGL 2.0. I will use the backward compatible profile by default. I will advise people with a recent graphics card and strong skills in shaders to use the forward compatible profile in order to check if it really works (you might have a performance gain, it depends on your driver). You can test OpenGL-ES support under Windows with ANGLE.
I will probably test it first with iOS and the sources 
@normen said:
I will probably test it first with iOS and the sources :)
We don't support iOS yet. LibGDX authors seem to prioritize their backend based on MonoTouch whereas their other backend based on JACK seems more interesting.
It would work almost as is on Meego (Nokia N9) and Raspberry Pi with JavaSE For Embedded or OpenJDK. I have never tested on Android because my smartphone supports only Android 2.1 and JOGL 2.0 needs a new code path to support Android versions lower than 2.3 (it relies on a Surface API introduced in Android 2.3) and the packaging is a bit different.
Another contributor said that FirefoxOS supports plugins unlike what Mozilla developers claimed but I haven't checked that by myself.
Does JMonkeyEngine require some AWT interoperability?
Does Nifty GUI still use a separate renderer for JMonkeyEngine?
The JOGL sources just use OpenGLES native API right? Then it should work with avian, I got jME running on iOS with a null renderer just fine and JNI works as usual. Maybe I can help you guys too a bit this way
AWT panels as they are implemented atm would be nice yes, we do need it for the SDK which is swing.
The nifty renderer should work without adapting the core ogl renderer, its a proper jme renderer, not a hacked system going down to ogl level like fengui et al on jME2. Theres no lwjgl calls in our nifty renderer.
@normen said:
The JOGL sources just use OpenGLES native API right? Then it should work with avian, I got jME running on iOS with a null renderer just fine and JNI works as usual. Maybe I can help you guys too a bit this way :)
Yes JOGL 2.0 use OpenGL-ES native API. Avian had no hardware float support when I looked at it, that's why my eyes were on LibGDX and a bit on XMLVM. Xerxes RĂ„nby is our specialist of embedded devices, he probably knows better than me how to setup JOGL on them.
@normen said:
AWT panels as they are implemented atm would be nice yes, we do need it for the SDK which is swing.
Ok I will use the AWT/NEWT bridge (NewtCanvasAWT). We have a bridge for SWT too (NEWTCanvasSWT and the heavyweight SWT canvas GLCanvas).
@normen said:
The nifty renderer should work without adapting the core ogl renderer, its a proper jme renderer, not a hacked system going down to ogl level like fengui et al on jME2. Theres no lwjgl calls in our nifty renderer.
Ok it is a good piece of news, thanks. The other Nifty GUI renderers heavily rely on the fixed pipeline and especially on immediate rendering which is not supported by OpenGL-ES.
Edit.: JOGL has some sort of video playback through FFMPEG and LibAV.
@gouessej said:
Yes JOGL 2.0 use OpenGL-ES native API. Avian had no hardware float support when I looked at it, that's why my eyes were on LibGDX and a bit on XMLVM. Xerxes RĂ„nby is our specialist of embedded devices, he probably knows better than me how to setup JOGL on them.
Ok I will use the AWT/NEWT bridge (NewtCanvasAWT). We have a bridge for SWT too (NEWTCanvasSWT and the heavyweight SWT canvas GLCanvas).
Ok it is a good piece of news, thanks. The other Nifty GUI renderers heavily rely on the fixed pipeline and especially on immediate rendering which is not supported by OpenGL-ES.
Edit.: JOGL has some sort of video playback through FFMPEG and LibAV.
Avian performed very good (as good as android) when I did my initial tests:
http://hub.jmonkeyengine.org/groups/jmonkeyplatform/forum/topic/sneak-peek-of-the-next-big-jme3-addition/
What exactly do you mean by "hardware float support"? Using the floating point unit of the CPU right?
Your "NEWT" windowing api seems to be quite robust so why not use that, yes.
About nifty: It should work on GL2 and GL1 if the renderer supports fixed funcs properly.
The video playback is interesting but patent issues basically require that we use vorbis.
Oh, @gouessej I forgot to ask: What about applets? I know their future is uncertain but they are kinda neat 
Our ogles renderer does not use LWJGL so it doesnât have to use JOGL.
Focus on a desktop renderer.
@normen said:
Avian performed very good (as good as android) when I did my initial tests:
http://hub.jmonkeyengine.org/groups/jmonkeyplatform/forum/topic/sneak-peek-of-the-next-big-jme3-addition/
What exactly do you mean by "hardware float support"? Using the floating point unit of the CPU right?
Your "NEWT" windowing api seems to be quite robust so why not use that, yes.
About nifty: It should work on GL2 and GL1 if the renderer supports fixed funcs properly.
The video playback is interesting but patent issues basically require that we use vorbis.
JOGL doesn't ship FFMPEG and LibAV to avoid patent issues. As far as I know, AvianVM has been improved and now supports the floating point unit of the CPU. Yes NEWT is obvisously more robust than AWT and supported under Android :) I have to dig a bit more for applets.
@nehon said:
Our ogles renderer does not use LWJGL so it doesn't have to use JOGL.
Focus on a desktop renderer.
I will focus on the desktop renderer but I don't totally exclude to use JOGL for the OpenGL-ES rendering too as it might be a bit more robust than using plain native EGL/OpenGL-ES. For example, Xerxes had to implement a special hack to use OpenGL-ES on Raspberry Pi, it would be logical to use JOGL rather than copying his hack into your OpenGL-ES renderer.
Doing an GLES renderer is fine but we will probably want to integrate other parts in iOS via JNI so it doesnât need to be too involved in the rest of the JOGL API, its mainly about the actual OpenGL access and mainly for iOS and possibly other platforms in the future.
Edit: On iOS for example Iâd like to just import the JOGL source files in XCode so that the java JNI calls work.
@normen said:
Doing an GLES renderer is fine but we will probably want to integrate other parts in iOS via JNI so it doesn't need to be too involved in the rest of the JOGL API, its mainly about the actual OpenGL access and mainly for iOS and possibly other platforms in the future.
Edit: On iOS for example I'd like to just import the JOGL source files in XCode so that the java JNI calls work.
Ok I see a bit what you mean. I have to sleep now. I've taken 4 days off as I said, I'll be ready to work on this port tomorrow morning :)
2 Likes
@gouessej said:
Ok I see a bit what you mean. I have to sleep now. I've taken 4 days off as I said, I'll be ready to work on this port tomorrow morning :)
Thats really awesome. Sleep well :)
Thank you very much @gouessej, it seems JOGL is much better since the last time we looked at it.
EDIT: Another thing I noticed is that thereâs a shared desktop/mobile interface called GL2ES2 ⊠How hard would it be to port to it instead of using just GL2 or GL3?
Out of coursiosity, what happens with the OGL4.1 stuff which was easy to implememnt in the current renderer when GL2ES2 get used as main renderer?
In general, i the new renderer going to be a replacement or can it be used optionally?
Hi
@Momoko_Fan said:
Thank you very much @gouessej, it seems JOGL is much better since the last time we looked at it.
Yes but JOGL already deserved some attention one year ago.
@Momoko_Fan said:
EDIT: Another thing I noticed is that there's a shared desktop/mobile interface called GL2ES2 .. How hard would it be to port to it instead of using just GL2 or GL3?
I will try to use the most fitted interfaces so that it will not be very difficult to switch to GL2ES2. Actually, if the engine is really heavily shader based and as you don't use immediate rendering, I assume it won't be too big an effort but Sven, Dominik and Xerxes feel more comfortable with mobile support than me, one of them could answer your question more precisely.
@zzuegg said:
Out of coursiosity, what happens with the OGL4.1 stuff which was easy to implememnt in the current renderer when GL2ES2 get used as main renderer?
You can use GLBase.isGLES2Compatible() in order to check whether the current profile is compatible with ES2, you can use the same kind of check for OpenGL 4. You still have to use isExtensionAvailable and isFunctionAvailable. Then, you can use in the same renderer features supported only by OpenGL 4.1 and features typically supported in OpenGL ES 2.0, you can isolate the code working only in one of these cases.
@zzuegg said:
In general, i the new renderer going to be a replacement or can it be used optionally?
It's not up to me, it won't be my decision but it will be available and frequently maintained whatever the choice the core developers will do and I highly encourage you to use it. Just look at what I did with the renderer based on JOGL 2.0 for Ardor3D, most of the bugs are fixed within hours, I even fixed some bugs without being able to reproduce them (because they only occurred under Windows).
Ok, I'm eating and then I'm going to setup my environment.
Edit.: I don't want to turn this thread into a "JOGL vs the other thing" debate. We do our best, all JogAmp APIs are actively maintained, we have a clear visibility with the bug tracker, lots of unit tests (thanks to Sven :)), we try to be professional as our APIs are used by professionals (lots of universities, research labs, industries, a very few game editors).
1 Like
I havenât found anything about building JME3 from the sources with Eclipse⊠
Try that (have not read the contents of the link):
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:setting_up_jme3_in_eclipse
The official way is using the SDK which is based on Netbeans, but there are some people using eclipse.
@kwando said:
Try that (have not read the contents of the link):
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:setting_up_jme3_in_eclipse
The official way is using the SDK which is based on Netbeans, but there are some people using eclipse.
Thanks. I have downloaded and installed Netbeans. The instructions for Eclipse are nice for binaries but not for building from source. Eclipse is a major IDE like Netbeans, it would be good to have a specific page in the wiki to explain how to build JME3 from the sources with it.
@zzuegg said:
Out of coursiosity, what happens with the OGL4.1 stuff which was easy to implememnt in the current renderer when GL2ES2 get used as main renderer?
In general, i the new renderer going to be a replacement or can it be used optionally?
Yes, please guys, keep the discussion down. *IF* we use the JOGL renderer it will completely replace the LWJGL one as we always said. Discussing the reasons can be done elsewhere, if at all we can discuss implications here.
1 Like
@gouessej said:
Thanks. I have downloaded and installed Netbeans. The instructions for Eclipse are nice for binaries but not for building from source. Eclipse is a major IDE like Netbeans, it would be good to have a specific page in the wiki to explain how to build JME3 from the sources with it.
There is, you are supposed to use the ant script. Eclipse cannot compile jme as it has no way to separate the jar files / do inter-dependence checks (apart from with an ant file, so like its now).