I started working on a jogl renderer today. I am pressed for time and do not know if I will be able to finish it soon so if any one wants to take over for me I will send them my code.
Sorry to jump on you… got my own life issues to deal with here. Thanks for getting together a list.
Personally, and this is by no means a critisism at you badmi, but I dont see a point for JOGL yet. Everyone on the boards have LWJGL working for them just fine (besides a few exceptions), so really, the only reason jME needs JOGL is for Solaris support?
Also, can you please compare the FPS you get badmi using lwjgl and jogl with the same test? Id like to know if there is any significant FPS increase/loss…
DP 
"renanse" wrote:
instead of being a broken record
After thinking about the posts I made in the last few days I think that you are right. I most sound like a broken recorded. I will stop posting on this subject until I contemplate my posts. ://
I will go threw the code and give you a list of changes Wednesday.
so really, the only reason jME needs JOGL is for Solaris support?
And not to mention the proof of concept.
Come on, instead of being a broken record, do something useful. For example, if you want certain changes made in .9, document them specifically. (And don’t say “well just look at my zip of code” because that won’t happen.)
After giving it much consideration I think that the changes to the core should be implanted in .9 because they change the way you can use jme. If you wait too long there may come a time that it would be impossible to add in jogl support. The rest of the jogl renderer can wait along as these changes are in. This will be consistent with mojo
I can help you if you want. I’ve used JoGL for some times before switching to LWJGL.
Chman
I do not really know jogl, I am learning as I go so I would apresheate any advice help you can give me. Converting the renderer is mostly copy and pasting with a fue modifications. One thing I can not figure out is what to replace GL11.GL_ARB_multitexture and GL11.OpenGL13 with.
About multitexturiing, everything you need is located in the GL interface… Simply do a gl.glActiveTextureARB(gl.GL_TEXTURE0_ARB); to activate the first texture unit… It’s really easy
About the OpenGL13 thing, I don’t really understand what you’ve wanted to say, but as everything related to OpenGL, JoGL put all into the GL interface.
Chman
LWJGL contented these variables that tell you if the functions are supported. For example GL11.GL_ARB_multitexture is true if multitextures are supported.
i use this snippet to check what’s available in jogl:
static Hashtable _glExtensions = null;
public static boolean isExtensionAvailable(GL aContext, String anExtension)
{
if (_glExtensions == null)
{
_glExtensions = new Hashtable();
String allExtensions = aContext.glGetString(GL.GL_EXTENSIONS);
StringTokenizer aTokenizer = new StringTokenizer(allExtensions, " ", false);
while (aTokenizer.hasMoreTokens())
{
String aToken = aTokenizer.nextToken();
_glExtensions.put(aToken, aToken);
// System.out.println(aToken);
}
}
return _glExtensions.get(anExtension) != null;
}
You can simply use something like that :
public boolean isMultitextureSupported()
{
String extensions = gl.glGetString(gl.GL_EXTENSIONS);
if(extensions.indexOf("GL_ARB_multitexture") !=-1)
{
return true;
}
else
{
return false;
}
}
Far more easier :)
What string is insted of OpenGL13?
JOGL seems to rewire a callback to render the seen. IS there any way to bypass it? IF there is not then what is the best way to integrate this jogl with the current app frame work. My idea is to have the app call a method in the reindeer. The reindeer would than call the apps render method when it is immediately in the LWJGL reindeer or from the callback in the JOGL.
I solved the problem but it required a change in jme’s interface.
Till now when the App classes got up to rendering they just called there render function. To get jme working with jogl needed to change this. Now the app class tells the display class that in needs to render. The display class then calls the app’s render function when it is ready to render. Please note that every thing happens on one thread so there is no problem with thread safety. Mojo is this ok with you?
Post code of what you want to change and explain why JOGL requires it. That post is not nearly enough to go on for making a change to the core.
JOGL seems to rewire that all calls to gl be form a callback function. Basically in JOGL I call a function that tells JOGL that I want to render. JOGL then calls my callback function when it is reedy. All rendering must be done in the call back function.
Instead of calling render the apps would call:
display.render(this, -1.0f);
Witch is defined by this in LWJGL:
public void render(AbstractGame app,float interpolation)
{
app.render(interpolation);
}
Mojo is the change I posted acceptable or do I need to post more information?
Mojo, is jme reedy for a jogl renderer? Is the port worth my time?
Mojo is the change I posted acceptable or do I need to post more information?
Just make the changes to your local copy and we'll deal with it when you are further along.
Mojo, is jme reedy for a jogl renderer? Is the port worth my time?
Sure, JOGL is on the todo list.