Before I start down the road of re-compiling JOGL from source, just wondering if anyone has tried rebuilding with all the OpenGL 1.5 additions. In particular, I’m interested in using GL_ARB_shading_language_100 and GL_ARB_shader_objects extensions, which aren’t included in the stock download.
Let me know how that goes. I’m having enough trouble trying to kick Apple in the ass enough to support GL1.4
Also really interested in progress on that, because of I plan to add support for GLslang to Xith3D (2/3 of devs voted for GLslang support).
BTW, I see more issues than just adding support for these extensions: I think that parameter management also should be added, possibly in a way similar to JOGL-Cg integration lib.
Yuri
So I take it that everyone wants it, nobody has done it ;D
I’ll have a look into it later this week as I have to finish off a few things in Aviatrix first. There’s a few really nice demos using GLSLang that I’d like to port to JoGL/Aviatrix, and we have demos for a couple of clients the week after, so it will be quite high on the priority list. If anyone else is interested in helping out, email me at the usual address.
[quote]So I take it that everyone wants it, nobody has done it
[/quote]
Thing that stops me from using GLslang is a lack of support for it [right now] on nVidia cards, especially on Linux…
Yuri
That’s pretty much what stops me from seriously trying to figure out it. Without support on my host platform (OSX), its a lost cause.
We have both 3DLabs and ATI cards in-house so that isn’t an issue for us. There’s a few really nice demos out there with GLSLang, and I’ve been interested in porting them over to try out, hence the need for 1.5. Got everything else working except for that and trying to figure out how pBuffers have been done in JOGL. ???
Hi,
just wanted to know if you got it to work with the GLSL extensions as I’m now trying to look into GLSL, but I don’t really want to go into setting up a mingw-environment with a current glext.h, etc. if I don’t even know if it works at all.
I hope, I don’t sound too lazy
Regards,
Jan
I’ve now got the java code compiling, but the mingw setup to compile the native code is alluding me. No idea what I’m doing wrong as the build gets to tthe native compile and just exits with no errors or anything else marginally informative. Still working on it part time, but right now concentrating on a couple of issues with pBuffers and our SceneGraph API.
Speaking of shaders I got Fragment and Vertex program to work smoothly with Xith3D, head over to the dedicated part of these forums to see few demos
Getting shaders to work with JOGL is relatively easy. The interesting part is the scene graph design to accomodate them. In fact, we had shaders running in Aviatrix before most of the texturing was available : I had actually already read your thread on it and I think the basics are OK, but you’ll need to think very carefully about the shader design that you have because I don’t believe it is flexible enough - particularly as the 1.5/2.0 shaders act very differently (ie single file for both vertex and fragment ops) In addition, you haven’t yet dealt with render to texture ops, and at least 40% of the demos I’ve seen use dynamically rendered to texture as one of the inputs (eg glow effects). I’m fairly close to the final design for Aviatrix now, so once that is done we should compare notes.
Well there ain’t no 1.5 shaders (1.1, 1.3, 1.4 and then 2.0) and as you already mentioned my implementation is plain basic since I barely know how a scenegraph the size of Xith3D works.
Please if you see any flaws in my implementation (I’m positive there is a ton, it’s just that I’m not seeing them clearly) point them out to me, after all I’m here to learn and shape my skills
Hi,
Ok, here’s my current progress:
I got the current jogl CVS-checkout to compile using vc7. In order to get the shader extensions, etc. I downloaded the most current glext.h/wglext.h and places them in make\stub_includes\opengl\GL.
Now, when I do an ant win32.vc7, I just get a whole bunch (and I mean a whole bunch, the screen just keeps on scrolling forever) gluegen errors.
Do I have to make any adjustments in order for a vanilla glext.h to work?
Regards,
Jan
Another update:
Here’s what I did to get the current glext.h to work with the jogl-compile:
-
changed all accurences of
APIENTRYP
to
APIENTRY *
this just does what the typedef APIENTRYP APIENTRY * does anyway. But the gluegen doesn’t like it, so you have to do it manually. -
remove the
#include <stddef.h>
its only needed for the immediatly following typedefs for GLintptr/GLintptrsize
just do them manually:
define int GLintptr
define int GLintptrsize
(I guess this only works on ia32, if you are on a 64-bit platform, you will probably have to find another type) -
remove glGetBufferPointerv function
somehow, the extension version (with ARB in the end) does work. So I guess, there’s a workaround for it somewhere in the code, but I couldn’t find it. Anybody?
so far so good, but now the nasty surprise:
glShaderSourceARB
trips another bug, the gluegen doesn’t like the GLcharARB ** parameter.
I changed them to be GLcharARB *, an it compiles, but I don’t know if this works (e.g. if it takes it as an array of strings with just the first entry). I haven’t yet tested it, but I’ll keep you up to date.
What’s weird: the jogl-todo says, that the ** should work for const char (which the const GLcharARB is, I also tried by putting it in directly) and only other types should produce errors, but this seems not the case. Any ideas?
Well, thats it so far,
Jan
Alright, finally got it to work:
My solution is a little bit awkward to use (a lot of unecessary arrays, but I’m not that good at JNI and so, I’m happy that it works)
Of course, the stuff about changing from GLcharARB ** to GLcharARB * couldn’t work.
So leave that out.
what you got to to is:
- add a line
ManuallyImplement glShaderSourceARB
to gl-common.cfg in make
this tells the gluegen, that we are going to do our own handling of that function.
next, add the following code to gl-impl-CustomCCode.c
/* Java->C glue code:
* Java package: net.java.games.jogl.impl.windows.WindowsGLImpl
* Java method: void dispatch_glShaderSourceARB(int shaderObj, int count, java.lang.String string, int[] length)
* C function: void glShaderSourceARB(GLhandleARB shaderObj, GLsizei count, const GLcharARB * string, const
GLint * length);
*/
JNIEXPORT void JNICALL
Java_net_java_games_jogl_impl_windows_WindowsGLImpl_dispatch_1glShaderSourceARB(JNIEnv *env, jobject _unused, jint
shaderObj, jint count, jstring string, jintArray length, jlong glProcAddress) {
PFNGLSHADERSOURCEARBPROC ptr_glShaderSourceARB;
const char* _UTF8string = NULL;
GLint * _ptr3 = NULL;
if (string != NULL) {
_UTF8string = (*env)->GetStringUTFChars(env, string, (jboolean*)NULL);
if (_UTF8string == NULL) {
(*env)->ThrowNew(env, (*env)->FindClass(env, "java/lang/OutOfMemoryException"),
"Failed to get UTF-8 chars for argument \"string\" in native dispatcher for
\"dispatch_glShaderSourceARB\"");
return;
}
}
if (length != NULL) {
_ptr3 = (GLint *) (*env)->GetPrimitiveArrayCritical(env, length, NULL);
}
char ** _strptr = &_UTF8string;
ptr_glShaderSourceARB = (PFNGLSHADERSOURCEARBPROC) (intptr_t) glProcAddress;
assert(ptr_glShaderSourceARB != NULL);
(* ptr_glShaderSourceARB) ((GLhandleARB) shaderObj, (GLsizei) count, (GLcharARB **) _strptr, (GLint *) _ptr3);
if (string != NULL) {
(*env)->ReleaseStringUTFChars(env, string, _UTF8string);
}
if (length != NULL) {
(*env)->ReleasePrimitiveArrayCritical(env, length, _ptr3, JNI_ABORT);
}
}
this is mostly just copied from the generated gluegen-code generated with the GLcharARB * variant, but it adds another pointer level (_strport), so you get the **
now add the following to gl-impl-CustomJavaCode.java:
/** Entry point to C language function:
<code> void glShaderSourceARB(GLhandleARB shaderObj, GLsizei count,
const GLcharARB * string, const GLint * length); </code> */
public void glShaderSourceARB(int shaderObj, int count, java.lang.String string[], int[] length)
{
final long __addr_ = _context.getGLProcAddressTable()._addressof_glShaderSourceARB;
if (__addr_ == 0) {
throw new GLException("Method \"glShaderSourceARB\" not available");
}
dispatch_glShaderSourceARB(shaderObj, count, string[0], length, __addr_);
}
/** Encapsulates function pointer for OpenGL function
: <code> void glShaderSourceARB(GLhandleARB shaderObj,
GLsizei count, const GLcharARB * string, const GLint * length); </code> */
private native void dispatch_glShaderSourceARB(int shaderObj, int count, java.lang.String string, int[] length,
long glProcAddress);
this is just plain passing to the JNI function except that we only pass the first entry of the string array.
Well, this should be it. As said, this is just a quick hack, so there are some limitations:
1.) You can only use the first entry of the string-array.
2.) resulting from this, you always have to pass in 1 as the number of array entries
3.) you have to supply the length of the string as the first element of the int array.
I know, this is not very clean, but at least, it works for me now and I didn’t have too much time available. If anybody want to clean the code up and create a proper patch, I would love that.
If there’s someone out there, that want to get the complete jar without going through the compile/change-hassle, just drop me short mail at jeDROP@MEframesys.de and I’ll send it to you.
just remove the drop me from the mail adress (spam-trap)
Regards,
Jan