JOGL in jME development

@sgold Thank you. By the way, I’ve found only three bug reports affecting the JOGL backend:
https://github.com/jMonkeyEngine/jmonkeyengine/issues/796
https://github.com/jMonkeyEngine/jmonkeyengine/issues/1045
https://github.com/jMonkeyEngine/jmonkeyengine/issues/1092

You already know the first one. I’ll have to find a machine to give it a try.

The second one will require some help of JogAmp’s JOCL maintainer as I’m a total JOCL / OpenCL newbie.

The third one contains only one line which is a piece of stack trace without any explanation to reproduce the bug, I’ll try to use the offscreen drawable with the JOGL backend but if I don’t get much more information, I’ll just close this bug report. The reporter always posts a single line from a stack trace in issues on Github, it’s not serious.

I’ll move those Github issues into our bug tracker very soon.

7 Likes

Awesome teamwork, guys. I’m glad we resolved the problem without losing all the hard work it took creating it. And an extra awesome :heart: to @sgold for extending his efforts to make your life easier maintaining it in the future.

7 Likes

I created a bug report in JogAmp’s bug tracker about the migration of this backend:
https://jogamp.org/bugzilla/show_bug.cgi?id=1427

5 Likes

@sgold com.jme3.input.MouseInput supports only mice with at most 3 buttons, it would be nice to have some constants to support more buttons as you can see here:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/v3.3/jme3-jogl/src/main/java/com/jme3/input/jogl/NewtMouseInput.java#L305

The only limitation is that getButtonCount() will go on returning 3 as there is no mean to know how many buttons a mouse has in our (JOGL) API yet.

Moreover, the call to confinePointer(false) in NewtMouseInput is useless as confinePointer(true) is no longer called, it was called in an older implementation of mouse centering. Please can you remove this line and try to reproduce your bug with JMonkeyEngine 3.3?

Finally, calling hack_confinePointer() in mouseEntered() and mouseExited() is probably useless, it’s already called in mouseMoved(). The behaviour that I advise is the current behaviour of its equivalent in JogAmp’s Ardor3D Continuation as you can see here.
Relative mouse motion events will help to provide a better implementation on the long term without having to recenter the mouse cursor.

1 Like

Thanks for the suggestions. I’ll follow up on them soon.

1 Like

If the additional mouse buttons have descriptive names, we should add constants for them. But if their names are simply “BUTTON4”, “BUTTON5”, and so on, we may as well refer to them by indices, like so:

            case MouseEvent.BUTTON4:
                index = 4;
                break;
            case MouseEvent.BUTTON5:
                index = 5;
                break;

Thanks for the suggestion. Removing the confinePointer(false) at NewtMouseInput line 125 doesn’t resolve issue 796.

I’m not sure I understand. Would implementing the behaviour you advise involve changes to jme3-core?

Your suggestion about returning the index makes sense to me.

Removing the call to hack_confinePointer() in mouseEntered() and mouseExited() doesn’t require to modify jme3-core. Thank you for having tested my first hypothesis, please can you test whether this change fixes or mitigates the issue 796?

Using relative mouse motion events in the JogAmp backend shouldn’t require any changes in the core. Instead of having to use only absolute mouse motion events requiring to recenter the mouse pointer, jme3-jogl NEWT input classes would ask NEWT (JOGL) to provide relative mouse motion events so that the delta would be straightforwardly obtained from NEWT and passed to jme3-jogl that would use it to build the events passed to the core. Other backends already able to provide relative mouse motion events probably do something similar, it’s smoother, more reliable, and the resulting source code is easier to maintain. You don’t need to make some debatable guesses on which events or data should be discarded. Calling warpPointer() would become useless in most cases.

Maybe a change would be required in the core if you decided to support grabbing the mouse without hiding its cursor and/or not grabbing the mouse but hiding its cursor. I don’t see any use case for such things in games.

1 Like

Sorry, removing those calls does not resolve issue 796, not by itself nor in combination with the removal of line 125.

By the way, the hooks for jme3-jogl have been restored in the master branch of the jMonkeyEngine repo.

2 Likes

@sgold Thank you for having tested anyway and for the restored hooks. I just hope that the renderer based on the backward profile will work because my hardware is not very young…

1 Like

I’m curious about the status of the backend migration. Has the new repository been set up? Have any of the old issues been reproduced and/or solved?

1 Like

Hello

At first, as I don’t have the necessary permissions, I still have to wait for the creation of the repository in the JogAmp infrastructure (I hope that it will be done next month).

Secondly, we still have to fix several bugs before releasing JOGL 2.4.0, I’ll have some time to work on JMonkeyEngine after that.

I’m sorry for the current situation, the combination of very few contributors with a little time to spare and critical bugs whose reporters take months to provide the necessary information leads to this slowness.

3 Likes

You have my sympathy!

3 Likes