Staredit Network > Forums > Technology & Computers > Topic: Advanced Java Help: FSEM and Shutdown Hooks
Advanced Java Help: FSEM and Shutdown Hooks
Jun 3 2008, 5:58 am
By: DT_Battlekruser  

Jun 3 2008, 5:58 am DT_Battlekruser Post #1



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.


Post has been edited 2 time(s), last time on Jun 3 2008, 6:04 am by DT_Battlekruser. Reason: grammar, spelling, etc.



None.

Jun 3 2008, 2:50 pm Cole Post #2



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.



None.

Jun 3 2008, 10:01 pm DT_Battlekruser Post #3



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.




None.

Jun 4 2008, 2:09 am Cole Post #4



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);



None.

Jun 4 2008, 2:18 am DT_Battlekruser Post #5



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?



None.

Jun 4 2008, 2:27 am Cole Post #6



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.



None.

Jun 4 2008, 6:19 am DT_Battlekruser Post #7



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.




None.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[06:57 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[06:57 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[06:57 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[06:56 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[06:56 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[06:56 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[06:56 am]
maxar39174 -- Outdoor gym and fitness equipment manufacturer and suppliers https://mountwoodco.com/outdoorgym-equipment-manufacturer-in-uttar-pradesh.php
[05:02 am]
Oh_Man -- whereas just "press X to get 50 health back" is pretty mindless
[05:02 am]
Oh_Man -- because it adds anotherr level of player decision-making where u dont wanna walk too far away from the medic or u lose healing value
[05:01 am]
Oh_Man -- initially I thought it was weird why is he still using the basic pre-EUD medic healing system, but it's actually genius
Please log in to shout.


Members Online: Roy