JOGL and JSFML

[pdinklag]

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

But if you use a "classical" main loop, you can render to the canvas like to any other render target with no trouble at all. You can use it like a normal RenderWindow, AWT will not interfere and run happily in its own thread.

I don't know your application, so I might be missing something. But from the sound of it, you are trying to protect yourself against problems that do not exist.

[Groogy]

Not really protecting myself. Just don't want to throw myself out into the big scary unkown of Java directly

Anyway trying to use the render canvas together with Swing so I can use the GUI builder of Netbeans but it seems to be messing with me. The Render canvas only gives me the error message that it fails to initialize.

I am placing the render canvas behind a custom panel that is very basic and have more or less nothing in it:

package tool;

import org.jsfml.graphics.Color;
import org.jsfml.graphics.RenderCanvas;
import org.jsfml.graphics.RenderWindow;

/**
 *
 * @author Groogy
 */
public class MainDisplayPanel extends javax.swing.JPanel {
    RenderCanvas gameCanvas = null;
    RenderWindow gameWindow = null;
   
    /**
     * Creates new form MainDisplayPanel
     */
    public MainDisplayPanel() {
        this.initComponents();
       
        this.gameCanvas = new RenderCanvas();
        this.add(gameCanvas);
        this.gameCanvas.initialize();
        this.gameWindow = this.gameCanvas.getRenderWindow();
        this.gameWindow.clear(Color.BLUE);
        this.gameWindow.display();
    }

    /**
     * This method is called from within the constructor to initialize the form.
     * WARNING: Do NOT modify this code. The content of this method is always
     * regenerated by the Form Editor.
     */
    @SuppressWarnings("unchecked")
    // <editor-fold defaultstate="collapsed" desc="Generated Code">                          
    private void initComponents() {

        setName("MainDisplayPanel"); // NOI18N

        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(this);
        this.setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 1024, Short.MAX_VALUE)
        );
        layout.setVerticalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGap(0, 768, Short.MAX_VALUE)
        );
    }// </editor-fold>                        
    // Variables declaration - do not modify                    
    // End of variables declaration                  
 

This panel is then put into the main window frame. Could that mess the render canvas up? How do you recommend that I approach this?

PS: Also tried moving the canvas to the frame with the same code but nothing is rendered(though I can get a label and similar to render)

[pdinklag]

You call "initialize" before the canvas actually has a handle. AWT doesn't give it a handle before the canvas becomes visible. During construction, it's not visible yet, therefore it has no handle, therefore you can't initialize it.

You say you added the panel to a frame - after you made that visible (setVisible), call "initialize". I'm not sure if overriding "setVisible" in your panel could do the trick - if it does, that would be good to know. I would really like to automate the "initialize" call.

[pdinklag]

Quick update: pull the newest version of the "render-canvas" branch.

The render canvas will now initialize itself automatically after validation. It has a handle at that point, and the manuall call can be avoided. Note, however, that before this happens, your gameWindow will be NULL.

Your option would be to override "validate" in your panel and get the window after the super call completed. "validate" works recursively, that means after the super call, all child components have been validated and the render window has been initialized.

[Groogy]

Will try that when I get home from jobb, thanks.

How is the Java way of doing a frame method? In C# I just make sure that invalidate is called on the panel and that I override the OnPaint method.

[pdinklag]

What do you mean by a "frame method"?

You don't have to care about repainting the RenderCanvas. The content of the canvas will always be empty from Java's point of view. SFML / OpenGL does the "painting".

[Groogy]

What I am talking about is not JSFML specific but Java Remember this place is pretty alien to me. But anyway what I want is to have a method called every frame/update so I can synchronize my render thread that will do the actual painting on the canvas.

I could hook up some ugly thing with timers I guess but I thought it would be smart to ask a more experienced JSFML user on what is the "Java way" to do this?

[pdinklag]

some ugly thing with timers

Well, that actually is the Java way to do it. You would create another thread that loops. It always sleeps for a certain interval and then does whatever timed action you want. Abusing validation and painting for this is not even nice in C#.

That's why I keep ranting about the "main loop".

In a usual SFML application, you have a "main loop" that does all the input handling, timed updates, rendering, etc while the window is open. There is absolutely no reason to not do it the same way with a render canvas. You just create the frame, add the canvas, make it visible and enter your main loop. You don't have to create another thread, AWT runs in its own thread by default.

The only thing that you need to synchronize into that main loop would be AWT input, e.g. when the user presses a button. AWT event listeners are always called in the AWT thread. I'm not sure what else you would like to synchronize between threads.

[Groogy]

Well it seems like the template that Netbeans puts up will make it near to impossible to do that since it seems to launch a thread for you which does only this:

new Tool().setVisible(true);

Where Tool is the frame class that netbeans generated for me.

Forgot to push my latest changes to Github so don't have the tool up there yet so can't pastebin some more complete code to you to show how it actually looks. But I'll fiddle around with netbeans generated code to see if I can inject some of my own stuff in there.

And I am rendering my graphics in a separate thread(well it is interfaced like if it was in a separate thread though if it should run in a separate thread is configurable) and I have this cause I am doing some heavy operations there and since it's an easy task to separate out and work on in parallell with the logic. But this isn't exposed to the AWT/Swing or whatever. So don't bother with this as it works on it's own. I more or less only need an entry point to call game.update() each frame and that's what I am more or less asking about where is the best way to do this in a Java GUI environment?

[pdinklag]

I would have to see exactly what NetBeans generated there, but it sure doesn't make anything impossible. We should probably stop discussing this until I can have a look at it.

Anyway, timed functions in Java are done using background casts. The simplest approach would be your own thread that does a loop that sleeps, the "Java way" would be using Java's Timer and TimerTask. It doesn't really matter whether you run in a GUI environment or not, Timer and TimerTask are the Java way.

http://sakhatech.com/blog/2011/03/23/java-timer-task-example/

[Groogy]

That actually looks quite nice, would let me also easily implement the logic to update at a fixed frame rate which would be awesome as well. The less code I have to write the better Why reinvent the wheel or work against the system?

Thanks I'll have a look at it when I get back home. I'll also show some pictures as soon as I have anything that looks remotely pretty

[Groogy]

Gah this is annoying. Trying to add the canvas to my custom panel but whenever I try Netbeans refuses me to drag-n-drop the panel to the main window. Getting really annoyed. I guess you have no idea?

Adding a Label and borderlayout and everything works just fine. Gah I was doing this in order to make tool development easier... This is the damned opposite.

Update: Even found a way to add the render canvas trough the GUI builder interface since it extends the canvas class. Still doesn't work(though with a plain canvas it works just perfectly)

Update: Nevermind, unless you want to delve into it and get it to work properly. But i managed to get it to work trough bypassing the GUI builder and adding the custom panel with the canvas in it for hand in the code so it isn't displayed trough the gui builder, then I got it to work.

[pdinklag]

I... have never worked with that GUI builder and never planned on doing that, sorry.

If I have to do something small in order for NetBeans to show it properly, let me know. I believe that somebody who calls himself a "Java developer" should be able to code up his GUI from scratch in vi, though.

[Groogy]

Alright little update, got timer on running the event loop and call update and eventually got everything working around the GUI Builder. It's not optimal but it is functional and I don't want to modify the game display canvas anyway so it doesn't really matter.

Little screenshot just of it in action:


Everything works with resize and so on as well so it's really SWEET to work with

Why the update time is so high(5ms) is because the timer is set to that, since it's just tool doesn't really matter what FPS I have there as long as I don't change the underlying game structure to support the tool that will eventually slow the game itself down.

[pdinklag]

Great to know.
The latest version on git changed the wav the RenderCanvas receives events entirely. It worked fine on Linux as far as I could test.

It would be good if you had a shot at it as well, ie whether events are received properly.