JOGL and JSFML

[Groogy]

Do you guys know of any way to use JOGL with JSFML? I am trying right now but it doesn't seem to work like in C where OpenGL only works on the current context. In JOGL it seems to be that you have to somehow aquire a context object to work with.

Just checking if someone already has solved this or if I should go ahead and try find a way?

[pdinklag]

I did experiment with LWJGL a little in the past. LWJGL is much better known than JOGL in the independent scene. It was clearly made with game development in mind, but it's a fully functional OpenGL, OpenAL and OpenCL binding for Java. JOGL is rather used in professional applications, I believe.

In any event, I'd like both LWJGL and JOGL to work with JSFML so you can do custom rendering.

What I tried is create a window using JSFML so that a valid context exists, and then I tried to tell LWJGL to use that context so I could do custom OpenGL rendering on my JSFML window. I made a forum post here, back then: http://lwjgl.org/forum/index.php/topic,4616.msg25357.html#msg25357
The "useContext" method was executed successfully (as in no exception was thrown), but I never actually saw anything. glClear or any type of rendering would have no effect on the window.

I never investigated any further because this kind of support is planned for later versions. However, feel free to experiment with this, I'd be extremely happy if JOGL and LWJGL were supported.

[Groogy]

At this time, is it possible to create a AWT frame or something similar from a SFML window? That could solve it for me.

[Groogy]

Nevermind found something way more interesting in the documentation

Update: Yepp works perfectly and irght out of the box. There is a function in the context/drawable factory to create a context representing an external context. Looking around JOGL looks freaking amazing and it supplements SFML perfectly on the raw OpenGL side.

Example code to get it to work:

package game;

import javax.media.opengl.GL;
import javax.media.opengl.GLContext;
import javax.media.opengl.GLDrawableFactory;
import javax.media.opengl.GLProfile;
import org.jsfml.graphics.RenderWindow;
import org.jsfml.window.VideoMode;
import org.jsfml.window.event.Event;

public class Game {
    static { GLProfile.initSingleton(); }

    public static void main(String[] args) {
        RenderWindow window = new RenderWindow();
        window.create(new VideoMode(640, 480), "Hello JSFML!");
       
        GLContext context = GLDrawableFactory.getFactory(GLProfile.getDefault()).createExternalGLContext();
        GL gl = context.getGL();
        gl.glClearColor(1, 1, 0, 1);

        window.setFramerateLimit(30);

        while(window.isOpen()) {
            gl.glClear(GL.GL_COLOR_BUFFER_BIT);
            window.display();

            for(Event event : window.pollEvents()) {
                if(event.getType() == Event.Type.CLOSED) {
                    window.close();
                }
            }
        }
    }
}

[Groogy]

JOGL was quite easy to get to work but it might be intimidating for newcommers. Especially if they want to compile to x86_64(that was a hell to go through) There are no tutorials or information on how to work with an external context either as far as I could find except in the documentation. So I am thinking if I maybe should write a tutorial something like next weekend to JSFML on how to get JOGL up and running.

[pdinklag]

That would be great, thanks for the help!
Good to see that it works this easily.

At this time, is it possible to create a AWT frame or something similar from a SFML window? That could solve it for me.

Code for that already exists, but is not checked in at this point. I should make it a branch really... It's supposed to be added in a future JSFML version.

[Groogy]

Code for that already exists, but is not checked in at this point. I should make it a branch really... It's supposed to be added in a future JSFML version.

Well to be honest I was looking into JSFML for the possibility to use the Java GUI together with SFML to make it easier to develop tools and so on, etc. etc. I guess this is possible with SFML.NET but... I get enough from C# at my day job so if I have to choose that would be Java that wins for me.

So I'll be looking forward to seeing Java GUI and SFML mix seamlessly
Wouldn't it be possible to take like the HWND or something like that from the Java Frame and create an SFML Window from that? Or you are thinking of a much wider support than just simply that?

[pdinklag]

Wouldn't it be possible to take like the HWND or something like that from the Java Frame and create an SFML Window from that?

Simple answer: yes.
Actual answer: nope, because first off, the handle is hidden away from Java and it has to be retrieved using native code. That's the easy part. On Windows at least, there's this problem that both SFML and AWT use the GWLP_USERDATA field to store information. I had a solution to this, but there were still some flaws if I recall right. I'm not sure how well it works on X/11 and Cocoa.

I guess there's only one way to find out. I'll create a branch for this some time this week and check that code back in.

[pdinklag]

Try the render-canvas branch: https://github.com/pdinklag/JSFML/tree/render-canvas
The org.jsfml.graphics.RenderCanvas is an AWT control that can have a RenderWindow.

Right now, you need to initialize it manually using "initialize". This has to be done when the canvas already has a window handle, e.g. once your window has become visible. I'm not sure yet how this can be detected automatically.

Simple example:

JFrame frame = new JFrame("JFrame");
frame.setSize(640, 480);
frame.setLayout(new BorderLayout());
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);

RenderCanvas canvas = new RenderCanvas();
frame.add(canvas, BorderLayout.CENTER);
frame.add(new JLabel("I'm a JLabel!"), BorderLayout.SOUTH);
frame.setVisible(true);

//canvas has a handle at this point
canvas.initialize();

RenderWindow window = canvas.getRenderWindow();
while (window.isOpen()) {
        window.clear(Color.RED);
        window.display();
}

[Groogy]

Seems to work ^^ Really nice! (And damn Java is fast compared to my beloved Ruby)

[Groogy]

But it seems like you are loading in AWT DLL and JOGL does that as well and this somehow crashes with the message:

Exception in thread "Thread-0" java.lang.UnsatisfiedLinkError: Native Library C:\Program Files\Java\jdk1.7.0_07\jre\bin\awt.dll already loaded in another classloader

Know how to fix this?

[pdinklag]

JOGL does that?
If so, make sure JOGL loads it first. In JSFML, this error should be caught and ignored.

[Groogy]

With RenderCanvas I am wondering about a thing. I am about to start using it. I refactored so everything is placed into it's own library and am about to start working on some tools. Though I have of course rendering in it's own thread and I am wondering if I can just send in the canvas to that thread without problems on JSFML side?

I did some experimentations so I can do all the rendering to a render texture that is then copied to the intended target at synchronization. Though this means that I have to fiddle around with the context activation between the threads and I measured that to actually add 200-220 microseconds on my high end machine. doesn't seem like much but if I can spare it then I will

I am going to try it out but if it doesn't seem to work do you think it's fixable to render to a canvas from another thread?

[pdinklag]

I had a working multi-threaded example working a good while ago. The code is lost in the nimbus but I know it's doable. I also ported the Context class a while ago, this should help with context activation. It was never tested so far...

I guess try it, if it doesn't work we'll see what we can do.

By the way, you do not have to do the rendering in an extra thread, you can use a main loop in the main thread without problems. All AWT / Swing events are handled in the separate "AWT Thread" already, so it won't freeze. You just have to deal with AWT events (e.g. button presses) asynchronously. A concurrent list to queue such events to be processed could be of help here.

Also, prepare for more refactoring, I've done a bunch of changes in the master branch to fix remaining design issues. Right now it should all be in its final form. I can't tell when I will merge the RenderCanvas into the master branch. It probably should be in JSFML 1.0, but it has to work properly. I will commence Linux tests some time soon.

[Groogy]

By the way, you do not have to do the rendering in an extra thread, you can use a main loop in the main thread without problems. All AWT / Swing events are handled in the separate "AWT Thread" already, so it won't freeze. You just have to deal with AWT events (e.g. button presses) asynchronously. A concurrent list to queue such events to be processed could be of help here.

Ah no I mean the game graphics are done in another thread. So I want the thread to be able to directly render to the render canvas so I don't have to deal with the context activations problems that SFML has. So the game library itself will not be aware that it is using a render canvas, it thinks it is only working with a render target while the tools application which generates the actual runnable code will be the one handling the AWT interface