In my humble opinion, most of the initialization code should be called in a static initializer.
Sven fixed the bug of the OpenALSoft fallback I’ll update JOAL soon.
Yeah!!! I was right! It works! Now I have to fix the bug of the OpenGL initialization and I’m going to commit my few fixes now.
@gouessej said:
In my humble opinion, most of the initialization code should be called in a static initializer.
Sven fixed the bug of the OpenALSoft fallback :) I'll update JOAL soon.
Static initializer? The only static methods that deserve to exist imo are system-level (hardware/os) or work self-contained. Do you mean that? Generally we'd like to avoid any static methods that are renderer-related (or better related to one renderer).
Ok, the sound tests work bit I still have no idea about the “dark screen of the death”…
@normen said:
Static initializer?
Yes. It is quite common to initialize ALUT in a static initializer once for all. Ensuring that it is called only once without using such an initializer may lead to uglier hacks.
@gouessej said:
Yes. It is quite common to initialize ALUT in a static initializer once for all. Ensuring that it is called only once without using such an initializer may lead to uglier hacks.
Right, that would be kind of hardware level then :) The question is if we can keep theoretic support for multiple applications in one VM, which we'd like to. But I guess its about the main initialization and grabbing the hardware reference, right? I mean there won't suddenly appear more audio bandwidth to play more channels than the hardware supports anyway.
Yes, you’re right. It’s almost half past one in France, I have to sleep. I have just tried the renderer based on the fixed pipeline and the renderer based on the programmable pipeline, I just get a black screen. I would appreciate that someone else checks whether I have forgotten something obvious. The display(GLAutoDrawable) method is called, I don’t see what is wrong.
Hi
The renderer based on the fixed pipeline works! I have just tested it on HelloJME3. There is something wrong in the handling of uniform variables; as I’m not a specialist of shaders, it is a bit difficult for me to fix that. I’m going to commit my few fixes very soon. I’m very glad to obtain a first success with JMonkeyEngine 3.0.
Awesome, keep up the good work
@normen said:
Cool, I pinged @Momoko_Fan, he will know best :)
I probably did something wrong when using direct NIO buffers or when building the name of the uniform to retrieve it.
@wezrule said:
Awesome, keep up the good work :)
Thank you and long live JOGL.
@gouessej: Make sure to check for GL errors after every call. I am not sure how this is done in JOGL, I think you may need to wrap the GL object with either TraceGL or DebugGL.
@gouessej: Could you hint me at what libraries/native files etc. I should try to assemble to get a NEWT display for iOS working? I can get some stuff together but as theres a lot of duplicates for various platforms some list of things you think should be in to do that would be nice. Also about where to put the actual implementation etc. then.
@Momoko_Fan said:
@gouessej: Make sure to check for GL errors after every call. I am not sure how this is done in JOGL, I think you may need to wrap the GL object with either TraceGL or DebugGL.
Yes I have to repair the piece of code using TraceGL and DebugGL.
@normen said:
@gouessej: Could you hint me at what libraries/native files etc. I should try to assemble to get a NEWT display for iOS working? I can get some stuff together but as theres a lot of duplicates for various platforms some list of things you think should be in to do that would be nice. Also about where to put the actual implementation etc. then.
Actually, I don't know, you should contact Xerxes Ranby, he's our specialist of embedded platforms. You need libjogl_mobile.jnilib, libnativewindow_awt.jnilib, libnativewindow_???.jnilib and libnewt.jnilib.
When the AWT version works, I will switch to NEWT.
I get that when running the blender test:
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform g_CameraPosition is not declared in shader [ShaderSource[name=Common/MatDefs/Light/Lighting.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Light/Lighting.frag, defines, type=Fragment, language=GLSL100]].
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform g_WorldMatrix is not declared in shader [ShaderSource[name=Common/MatDefs/Light/Lighting.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Light/Lighting.frag, defines, type=Fragment, language=GLSL100]].
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform m_ParallaxHeight is not declared in shader [ShaderSource[name=Common/MatDefs/Light/Lighting.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Light/Lighting.frag, defines, type=Fragment, language=GLSL100]].
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform m_UseMaterialColors is not declared in shader [ShaderSource[name=Common/MatDefs/Light/Lighting.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Light/Lighting.frag, defines, type=Fragment, language=GLSL100]].
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform m_Minnaert is not declared in shader [ShaderSource[name=Common/MatDefs/Light/Lighting.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Light/Lighting.frag, defines, type=Fragment, language=GLSL100]].
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform m_WardIso is not declared in shader [ShaderSource[name=Common/MatDefs/Light/Lighting.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Light/Lighting.frag, defines, type=Fragment, language=GLSL100]].
26 oct. 2012 20:16:45 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
INFO: Uniform m_VertexColor is not declared in shader [ShaderSource[name=Common/MatDefs/Misc/Unshaded.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Misc/Unshaded.frag, defines, type=Fragment, language=GLSL100]].
@gouessej said:
Actually, I don't know, you should contact Xerxes Ranby, he's our specialist of embedded platforms. You need libjogl_mobile.jnilib, libnativewindow_awt.jnilib, libnativewindow_???.jnilib and libnewt.jnilib.
Heh, no, I mean the sources ^^ I'd work on creating the actual window implementation for iOS. I guess an XCode project will be necessary to build it anyway though, tough to keep a "normal" build for iOS working.
Edit: Btw, try clean&build every once in a while in your project, due to the changes in the build folders fro the jar separation our NetBeans project sometimes behaves a bit weird and finds old files.
@normen said:
Heh, no, I mean the sources ^^ I'd work on creating the actual window implementation for iOS. I guess an XCode project will be necessary to build it anyway though, tough to keep a "normal" build for iOS working.
The source code of NEWT is here.
@gouessej said:
The source code of NEWT is here.
Oh, I see, I never bothered to look at the actual NEWT source itself.. That looks relatively slick, I guess that can be done..
Whether jME ends up with one or the other OGL-wrapper is nothing I have an opinion about, but the amount of work @gouessej is putting into this now is impressive to me.
@jmaasing said:
Whether jME ends up with one or the other OGL-wrapper is nothing I have an opinion about, but the amount of work @gouessej is putting into this now is impressive to me.
Thanks. I still have a lot of features to implement and JMonkeyEngine 3.0 will end up with 2 renderers based on JOGL 2.0 available as "external modules" or as part of the engine. I hope I haven't wasted my time.