0.95 - Setting display mode and fullscreen

OpenGL Development
#1

I’m porting SH to 0.95 but I can’t get the ingame mode switching to work flawlessly.

  1. Switching between displaymodes retrieved from Display.getAvailableDisplayModes() results in windowed mode results in first a mode switch to 640x480 then back to desktop resolution. Then there seems to be 2 windows. A black undecorated window. Behind it a decorated with my game partially showing.

  2. Staring in fullscreen and setting a displaymode created with the DisplayMode constructor do of course not work. But I get native crash wich is a bit unplesant. Fair enough.

  3. Starting in fullscreen and later calling Display.setFullscreen(false) I get the following native crash:

  1. Starting in fullscreen and later switching to displaymode I got using Display.getDisplayMode() before Display was created the first time, I also get the same native crash as above.

At this point I gave up staring in fullscreen mode and trying to switch to windowed mode :frowning:

  1. There is 2 mode switches when I need to switch between windowed/fullscreen and also change resolution. As both setFullscreen and setDisplayMode will change mode. This is a bit unpleasant on my monitor as it makes 2 loud sounds each time a mode is changed. Any chance of having a setDisplayMode(DisplayMode newMode, boolean fullscreen) that does it with only one mode change?

So I’m having great problems switching modes in game. Is this something you are willing to fix. How are you dealing with it?

#2

I’ve done a little more testing and it seems that all display mode changes fails in a native crash if I start in fullscreen with a different bit depth than the desktop.

#3

Changing display mode color depth is not recommended, since most drivers seem to either crash or simply render garbage when tried. Use the same display mode depth or use Display.destroy()/Display.create() if you want to switch color depth.

As for the other bugs, please wait for 0.96 which should be out this weekend and test with that. There is simply too much internal restructuring for me to bother with trying to fix anything in 0.95 at the moment, sorry.

  • elias
#4

[quote]Changing display mode color depth is not recommended, since most drivers seem to either crash or simply render garbage when tried. Use the same display mode depth or use Display.destroy()/Display.create() if you want to switch color depth.
[/quote]
Makes sence. I’ll probably drop the bit depth option in my game. Or I can fall back on the context save/restore code that I already got working.

[quote]As for the other bugs, please wait for 0.96 which should be out this weekend and test with that. There is simply too much internal restructuring for me to bother with trying to fix anything in 0.95 at the moment, sorry.
[/quote]
No problem. I propose that a smal test app is written, similar to FullScreenWindowedTest, that will test ingame mode switching. Pressing the keys 1, 2, 3, 4 will swicth to:

  1. Windowed 640x480
  2. Fullscreen 640x480
  3. Windowed 800x600
  4. Fullscreen 800x600
    It can be part of the lwjgl test package. It could replace the FullScreenWindowedTest. Or you can just use it internally before releasing new versions of lwjgl to make sure there is no regression bugs. I’d be happy to write the test app if you are interested in using it.

I know it don’t have a high priority as I’m guessing I’m the only one doing ingame mode switching :slight_smile:

#5

You’re wrong :slight_smile: We’re using runtime switching between windowed/fullscreen in TT with good results.

  • elias
#6

[quote]I’d be happy to write the test app if you are interested in using it.
[/quote]
I’m on it - wife is out of town anyway :slight_smile:

#7

New window creation test in. Definately bugs in mode switching.
randomly changing between fullscreen and windowed mode and display modes will make fullscreen stop working… sometimes :’(

I tried to completely destroy the display before changing modes - but still the same result

Display.destroy();
Display.create();
Display.setDisplayMode(fixed_modes[mode]);
Display.setFullscreen(fullscreen);
#8

I knocked up a little something on my system. Going from windowed->windowed, or windowed->fullscreen works well. Going from fullscreen to windowed causes some ugly side effects, such as a borderless window hanging around with the game window behind it. I assume it’s the ghost of the window created by the fullscreen handling. This appears same effect occurs regardless of whether I destroy and recreate the display or if I call setFullscreen(false).


public class DisplayModeTest
{
    void run() throws Exception
    {
        setDisplayMode(640, 480);
        boolean running = true;
        
        while(running)
        {
            GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
            GL11.glBegin(GL11.GL_TRIANGLES);
            GL11.glVertex2i(400, 400);
            GL11.glVertex2i(300, 300);
            GL11.glVertex2i(500, 300);
            GL11.glEnd();
            Display.update();
            
            if(Keyboard.isKeyDown(Keyboard.KEY_ESCAPE))
            {
                running = false;
            }
            else if(Keyboard.isKeyDown(Keyboard.KEY_1))
            {
                setDisplayMode(640, 480);
                GL11.glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
            }
            else if(Keyboard.isKeyDown(Keyboard.KEY_2))
            {
                setDisplayMode(640, 480, 32);
                GL11.glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
            }
            else if(Keyboard.isKeyDown(Keyboard.KEY_3))
            {
                setDisplayMode(800, 600);
                GL11.glClearColor(0.0f, 1.0f, 0.0f, 0.0f);
            }
            else if(Keyboard.isKeyDown(Keyboard.KEY_4))
            {
                setDisplayMode(800, 600, 16);
                GL11.glClearColor(0.0f, 0.0f, 10.0f, 0.0f);
            }
        }
        
        Keyboard.destroy();
        Display.destroy();
    }
    
    void setDisplayMode(int width, int height) throws Exception
    {
        if(Display.isFullscreen())
            Display.destroy();
        if(!Display.isCreated())
            Display.create();        
        /*
        if(Display.isFullscreen())
              Display.setFullscreen(false);
        */
        DisplayMode mode = new DisplayMode(width, height);
        Display.setDisplayMode(mode);
    }
    
    void setDisplayMode(int width, int height, int bpp) throws Exception
    {
        DisplayMode[] modes = Display.getAvailableDisplayModes();
        DisplayMode match = null;
        
        for(int i=0; i<modes.length; ++i)
        {
            if(modes[i].getWidth() == width && modes[i].getHeight() == height && modes[i].getBitsPerPixel() == bpp)
                match = modes[i];
        }
        
        if(null == match)
            match = new DisplayMode(width, height);
        
        if(Display.isCreated())
            Display.destroy();
        Display.create();
        Display.setDisplayMode(match);
        Display.setFullscreen(true);
    }

    public static void main(String[] args)
    {
        try
        {
            new DisplayModeTest().run();
        }
        catch(Exception e)
        {
            e.printStackTrace();
        }
    }
}
#9

On what OS is this happening on? On my Windows XP SP 2 with an ATI gfx card it works fine.

  • elias
#10

I get the same bugs as described by aldacron. I’m running XP sp 2, ATI 9500 Pro, Catalyst version 03.8 (from display properites), driver filename was “wxp-w2k-catalyst-7-94-030917m-011434c.exe”.

I know it is not the latest drivers. But it is the only version that don’t crash my computer on a regular basis.

#11

I’m getting it too on my Radeon 9700 XP SP2, Catalyst 4.10 (Omega).
My laptop at work (XP, SP2, GeForce 4400 Go) does not have any issues whatsoever.

I have mailed elias a video of whats happening, so he can get a clue as to whats going on. His latest commit did not help.

#12

Windows XP SP2, Geforce FX 5700 LE, Forceware 66.93 (which was the latest release prior to March 11) drivers. I’m downloading the newest release, 71.84, now and will see what that does for me.

#13

I’ve noticed that going from windowed to fullscreen sometimes causes a crash on my mac (Powerbook so ATI graphics). It doesn’t happen every time, but it’s quite common. Doesn’t appear to be a problem on my pc. There were some similar discussions surrounding Java2D.

Is is issue still existing & is there any workaround? (Apart from not allowing to switch back to full screen from windowed

Alan

#14

I get this too - I get an IllegalStateException when trying to read the keyboard afterwards, like the keyboard is being mucked around with in a race condition. At least, I think that’s the problem.

Cas :slight_smile:

#15

Cas, thanks for your reply, it confirms my suspicions.

Incidentally, there are a number of Java2D threads which have a suspiciously similar problem. It appears to be related to setting windows decorations on/off, which you have to do when going windowed <=> fullscreen. Basically you can’t change the decorations while the window is displayed, and if you dispose() it, there appears to be a bug in the java disposer. There is a stacktrace at the bottom of the thread. It does have the keyboard handler in the trace, but I suspect that it might be that the setFullScreen() is in the keyboard callback so this might not mean anything.

Think this goes on the ‘Too Hard’ pile, so I’ll ignore this problem for the time being.

Alan