[color=#b5b5ff]I'm not sure if anyone out there has done enough Java to help me with this, but I'm have an issue with Full-Screen Exclusive Mode (FSEM) and shutdown hooks. Very simply put, whenever I exit the JVM while in FSEM, any shutdown hooks I have attached to the current runtime (such as restoring the window to the OS) do not execute. If I manually restore the window before I call [font=courier]System.exit(0)[/font] then the shutdown hook is then run. This is my code to initiate FSEM and paint the canvas; the superclass makes periodic calls to the render and paint methods:[/color] [size=11] [code] protected void setupCanvas() { GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); hardwareRenderer = ge.getDefaultScreenDevice(); setUndecorated(true); setBackground(Color.WHITE); setIgnoreRepaint(true); setResizable(false); if (!hardwareRenderer.isFullScreenSupported()) { System.err.println("Hardware Compatibility Error: Full Screen Exclusive Mode not supported."); System.exit(0); } hardwareRenderer.setFullScreenWindow(this); super.setGameSize(getSize()); try { EventQueue.invokeAndWait(new Runnable() { public void run() { createBufferStrategy(bufferCount); // Asynchronous dispatch } }); } catch (Exception e) { System.err.println("Buffer strategy creation error."); System.exit(0); } // Allow dispatch to complete - yes I KNOW this is a shoddy cop-out try {Thread.sleep(500);} catch (InterruptedException e) {} bufferStrategy = getBufferStrategy(); pack(); setPaused(true); startGame(); } public void renderGame() { try { Graphics g = bufferStrategy.getDrawGraphics(); drawGame(g); g.dispose(); } catch (Exception e) { System.err.println("Render-time graphics error!"); e.printStackTrace(); terminate(); } } public void paintScreen() { try { if (!bufferStrategy.contentsLost()) bufferStrategy.show(); Toolkit.getDefaultToolkit().sync(); } catch (Exception e) { System.err.println("Paint-time graphics error!"); e.printStackTrace(); terminate(); } } [/code] [/size] [color=#b5b5ff]The superclass calls [font=courier]Runtime.getRuntime().addShutdownHook[/font] to call the method [font=courier]runBeforeTermination()[/font] which is overridden below. Also shown is the code to terminate the program (called if a click a quit button, etc. - the "normal" way to exit) and to restore the screen.[/color] [size=11] [code] protected void restoreScreen() { Window w = hardwareRenderer.getFullScreenWindow(); if (w != null) w.dispose(); hardwareRenderer.setFullScreenWindow(null); } public void terminate() { restoreScreen(); super.terminate(); } public void runBeforeTermination() { restoreScreen(); System.out.println("hi"); } [/code] [/size] [color=#b5b5ff]Any time I call [font=courier]terminate()[/font] with a call to [font=courier]restoreScreen()[/font], then the shutdown hook runs and "hi" is printed to the console. If I comment out the [font=courier]restoreScreen()[/font] or exit via alt+f4, my screen remains the last painted frame and I have to assume nothing is printed to the console (I have to close Eclipse to get my screen back). I know there are [i]some[/i] coding people out there.. is FSEM just not compatible with hooks or something? I see nothing in the API to this effect.[/color]

I'm not sure if anyone out there has done enough Java to help me with this, but I'm have an issue with Full-Screen Exclusive Mode (FSEM) and shutdown hooks. Very simply put, whenever I exit the JVM while in FSEM, any shutdown hooks I have attached to the current runtime (such as restoring the window to the OS) do not execute. If I manually restore the window before I call System.exit(0) then the shutdown hook is then run.

This is my code to initiate FSEM and paint the canvas; the superclass makes periodic calls to the render and paint methods:

Code

    protected void setupCanvas() {    
        GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
        hardwareRenderer = ge.getDefaultScreenDevice();
       
        setUndecorated(true);
        setBackground(Color.WHITE);
        setIgnoreRepaint(true);
        setResizable(false);
       
        if (!hardwareRenderer.isFullScreenSupported()) {
            System.err.println("Hardware Compatibility Error: Full Screen Exclusive Mode not supported.");
            System.exit(0);
        }
       
        hardwareRenderer.setFullScreenWindow(this);
       
        super.setGameSize(getSize());
       
        try {
            EventQueue.invokeAndWait(new Runnable() {
                public void run() {
                    createBufferStrategy(bufferCount);     // Asynchronous dispatch
                }
            });
        }
        catch (Exception e) {
            System.err.println("Buffer strategy creation error.");
            System.exit(0);
        }
       
        // Allow dispatch to complete - yes I KNOW this is a shoddy cop-out
        try {Thread.sleep(500);}     catch (InterruptedException e) {}
       
        bufferStrategy = getBufferStrategy();
       
        pack();
        setPaused(true);
        startGame();
    }
   
    public void renderGame() {
        try {
            Graphics g = bufferStrategy.getDrawGraphics();
            drawGame(g);
            g.dispose();
        }
        catch (Exception e) {
            System.err.println("Render-time graphics error!");
            e.printStackTrace();
            terminate();
        }
    }
   
    public void paintScreen() {
        try {
            if (!bufferStrategy.contentsLost())
                bufferStrategy.show();
            Toolkit.getDefaultToolkit().sync();
        }
        catch (Exception e) {
            System.err.println("Paint-time graphics error!");
            e.printStackTrace();
            terminate();
        }
    }

The superclass calls Runtime.getRuntime().addShutdownHook to call the method runBeforeTermination() which is overridden below. Also shown is the code to terminate the program (called if a click a quit button, etc. - the "normal" way to exit) and to restore the screen.

Code

    protected void restoreScreen() {
        Window w = hardwareRenderer.getFullScreenWindow();
        if (w != null)
            w.dispose();
        hardwareRenderer.setFullScreenWindow(null);
    }
   
    public void terminate() {
        restoreScreen();
        super.terminate();
    }
   
    public void runBeforeTermination() {
        restoreScreen();
        System.out.println("hi");
    }

Any time I call terminate() with a call to restoreScreen(), then the shutdown hook runs and "hi" is printed to the console. If I comment out the restoreScreen() or exit via alt+f4, my screen remains the last painted frame and I have to assume nothing is printed to the console (I have to close Eclipse to get my screen back).

I know there are some coding people out there.. is FSEM just not compatible with hooks or something? I see nothing in the API to this effect.

I'm know C#, but Java and C# are pretty similar, so maybe I can try and help with a little googling. You sure there's no way to get rid of all the try's and catches? They are horrendously slow. Anyway, I found a nice PDF related to Java game development, and the segment on exiting the game is as follows: [quote]2.5. Exiting the Game The primary means for terminating the game remains the same: when the running boolean is true then the animation loop will terminate. Before run() returns, the finishOff() method is called. [code]private void finishOff() { if (!finishedOff) { finishedOff = true; printStats(); System.exit(0); } }[/code] The finishedOff boolean is employed to stop a second call to finishOff() printing the statistics information again. The other way of calling finishOff() is from a shutdown hook (handler) set up when the JPanel is created: [code]Runtime.getRuntime().addShutdownHook(new Thread() { public void run() { running = false; System.out.println("Shutdown hook executed"); finishOff(); } });[/code] This code is normally called just before the application exits, and is superfluous since finishOff() will already have been executed. Its real benefit comes if the program terminates unexpectedly. The shutdown hook ensures that the statistics details are still reported. This kind of defensive programming is often very useful. For example, if the game state must be saved to an external file before the program terminates, or if critical resources, such as files or sockets, must be properly closed[/quote] Don't know if that will help ya much, but I hope it does.

I'm know C#, but Java and C# are pretty similar, so maybe I can try and help with a little googling.

You sure there's no way to get rid of all the try's and catches? They are horrendously slow.

Anyway, I found a nice PDF related to Java game development, and the segment on exiting the game is as follows:

Quote

2.5. Exiting the Game
The primary means for terminating the game remains the same: when the running
boolean is true then the animation loop will terminate. Before run() returns, the
finishOff() method is called.

Code

private void finishOff()
{ if (!finishedOff) {
finishedOff = true;
printStats();
System.exit(0);
}
}

The finishedOff boolean is employed to stop a second call to finishOff() printing the
statistics information again.
The other way of calling finishOff() is from a shutdown hook (handler) set up when
the JPanel is created:

Code

Runtime.getRuntime().addShutdownHook(new Thread() {
public void run()
{ running = false;
System.out.println("Shutdown hook executed");
finishOff();
}
});

This code is normally called just before the application exits, and is superfluous since
finishOff() will already have been executed. Its real benefit comes if the program
terminates unexpectedly. The shutdown hook ensures that the statistics details are still
reported.
This kind of defensive programming is often very useful. For example, if the game
state must be saved to an external file before the program terminates, or if critical
resources, such as files or sockets, must be properly closed

Don't know if that will help ya much, but I hope it does.

[color=#b5b5ff]I have that book :P The try-catch in the repeated methods is probably unnecessary, but also irrelevant. So far it just seems that shutdown hooks are not compatible with FSEM, but there really ought to be away to prevent alt-f4 exiting to result in a screen loss (I haven't tried running from a JAR - maybe the termination of the process will grab the screen back). Thanks for trying, and the pointer on try/catch.[/color]

I have that book

The try-catch in the repeated methods is probably unnecessary, but also irrelevant. So far it just seems that shutdown hooks are not compatible with FSEM, but there really ought to be away to prevent alt-f4 exiting to result in a screen loss (I haven't tried running from a JAR - maybe the termination of the process will grab the screen back).

Thanks for trying, and the pointer on try/catch.

Wouldn't it be possible to disable alt + f4? I'm sure there must be a way; some games have alt + f4 disabled. Then you could either implement your own version of it or just not have it enabled at all. This topic is from a long time ago however it may help in disabling alt + f4: http://forum.java.sun.com/thread.jspa?threadID=284195&messageID=1216200 Mainly this piece of code: setDefaultCloseOperation(DO_NOTHING_ON_CLOSE);

Wouldn't it be possible to disable alt + f4? I'm sure there must be a way; some games have alt + f4 disabled. Then you could either implement your own version of it or just not have it enabled at all.

This topic is from a long time ago however it may help in disabling alt + f4:
http://forum.java.sun.com/thread.jspa?threadID=284195&messageID=1216200
Mainly this piece of code:
setDefaultCloseOperation(DO_NOTHING_ON_CLOSE);

[color=#b5b5ff]That would certainly get around that method of force-exiting, and perhaps it should be enough. A comment on that thread talks about Sun fixing something in 1.4, do you know if this ever happened?[/color]

That would certainly get around that method of force-exiting, and perhaps it should be enough. A comment on that thread talks about Sun fixing something in 1.4, do you know if this ever happened?

I was reading that myself, I have no idea as I never really did much with Java. I also found this: http://forum.java.sun.com/thread.jspa?threadID=5301341 It talks about thread priorities, and maybe that's what is causing your problem in full screen mode.

I was reading that myself, I have no idea as I never really did much with Java.

I also found this:
http://forum.java.sun.com/thread.jspa?threadID=5301341

It talks about thread priorities, and maybe that's what is causing your problem in full screen mode.

[color=#b5b5ff]Manually handling the frame's closing with the window listener successfully catches most attempts to exit, so thanks for the help. If any Java whiz feels like commenting on the thread issues, be my guest.[/color]

Manually handling the frame's closing with the window listener successfully catches most attempts to exit, so thanks for the help.

If any Java whiz feels like commenting on the thread issues, be my guest.