i've been playing around with changing DisplayModes, and found that when combined with BufferStrategy its not just unstable, it simply doesn't work!

here is some cutdown code that demonstrates the sort of problems encountered.

also, in FullScreenFrame there are 2 lines (105 & 106) neither of which should be needed. However, by adding 1 or other (or both) of them I can get it to partially work. (but with allsorts of low-level exceptions being thrown up in native code)

Can some1 reassure me that its Sun code that is broken, not mine!(A friend has also independantly attempted to solve the same problem, but hes come across the same bugs and crashes as well )

// sets the display mode of this Frame// if the frame is not already visible,// it will also be made visiblepublicBufferStrategysetDisplayMode(booleanfullScreen, DisplayModedm) {System.out.println("Changing to "+ (fullScreen?"Full Screen ":"Window ") +dm.getWidth() + "x" + dm.getHeight() + "x" + dm.getBitDepth());

if(screenDevice.isDisplayChangeSupported() && !screenDevice.getDisplayMode().equals(dm)) {screenDevice.setDisplayMode(dm);createBufferStrategy(); }elseif(isWindowed) createBufferStrategy();isWindowed = false; }else//we are changing to window mode {if(!isWindowed) {//screenDevice.setDisplayMode(defaultMode); //this line shouldn't be needed//screenDevice.setFullScreenWindow(null); // this line shouldn't be neededdispose(); //dispose of the window...setUndecorated(false); //...so it can be changed to a decorated windowisWindowed=true; }

publicvoidkeyPressed(KeyEvente) {switch(e.getKeyCode()) {caseKeyEvent.VK_ESCAPE: //Escape to kill the Thread (and eventually dispose of the Window)running = false;return;caseKeyEvent.VK_UP: //up arrow to cycle up through supported resolutionsmodeChange=1;return;caseKeyEvent.VK_DOWN: //down arrow to cycle down through supported resolutionsmodeChange=-1; } }

Certainly, if you see exceptions or crashes, it's most likely our fault (with notable exceptions of some buggy video drivers that are out there).

I don't see anything really broken in your code, and I did see some problems when switching display modes in fullscreen, when running it on 1.4.1_01. The things sort of improved when I added a 2 seconds delay between the screenDevice.setDisplayMode(dm);and createBufferStrategy();

What jdk version were you using?

We've made a lot of full screen fixes in the upcoming patch release (1.4.1_02, will be out sometime in Q1'03), I'll try your app with the new build to see if we've covered these problems.

well, I was using jdk1.4.0, but my friend was using 1.4.1_01 and encountered the same problems.

In my original post, I ommited telling you how exactly to replicate the problems - oops

anyhow, here is the sequence that kills it.

The program starts up with a Window that occupies the entire screen.

1) select a different screen size2) switch to fullscreen.3) switch back to window mode

The problems start now. Depending on which lines are commented out, several things can happen.

Both lines 107 & 108 are Commented out

The repaint code will nolonger be having any effect on the Window. (its as if the BufferStrategy that was created is in an invalid state).If you then switch back to fullscreen, a low-level exception is thrown (somewhere underneath GraphicsDevice.setDisplayMode(DisplayMode))

Only line 107 is Commented out

Same as above, but if you now stay in windowed mode, and switch to a different resolution (down arrow, then enter) you get a JVM crash in native code that looks something like this :-

An unexpected exception has been detected in native code outside the VM.Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x831F1BB7Function=[Unknown.]Library=(N/A)'

the repaints work, BUT they draw over the top of the Windows decoration (even though the window is decorated). Its as if the Frame is in a Windowed Exclusive Mode (the repaints occur ontop of every other window, even if the Frame is obscured!)Also, any subsequent FullScreen->Windowed mode switches cause a none terminal Exception (originating from the EventDispatchThread)

I will try adding the 2 second delay, and switching to 1.4.1 - see if that improves matters.

I have tried adding the 2 second delay, and it made no difference. (im downloading 1.4.1 as I type)

I now have 1.4.1_01, and the same problems occur , even with the 2 second delay

using 1.4.1_01, i've managed to find a work-around.(im not sure it'll work with 1.4.0 - but its possible it will)

the 3 lines of the work-around are highlighted.

(1) before disposing of a FullScreen window, you *HAVE* to call GraphicsDevice.setFullScreenWindow(null); (line 109)

(2) there is some validation code deep down in Component that needs calling before createBufferStrategy will return a valid Strategy.Both pack() and setBounds(x,y,width,height) call this code, though I havn't pinpointed exactly what code it is.(line 117)

(3) getBufferStrategy will still return an invalid Strategy, until BufferStrategy.show() is called.Once this has been done, any future calls to getBufferStrategy() will return a valid, and fully usable strategy! (line 121)

so, can I have your promise that it'll be working properly by 1.4.1_02

// sets the display mode of this Frame// if the frame is not already visible,// it will also be made visiblepublicBufferStrategysetDisplayMode(booleanfullScreen, DisplayModedm) {System.out.println("Changing to "+ (fullScreen?"Full Screen ":"Window ") +dm.getWidth() + "x" + dm.getHeight() + "x" + dm.getBitDepth());

publicvoidkeyPressed(KeyEvente) {switch(e.getKeyCode()) {caseKeyEvent.VK_ESCAPE: //Escape to kill the Thread (and eventually dispose of the Window)running = false;return;caseKeyEvent.VK_UP: //up arrow to cycle up through supported resolutionsmodeChange=1;return;caseKeyEvent.VK_DOWN: //down arrow to cycle down through supported resolutionsmodeChange=-1; } }

First i create a Frame, make it windowed and use double buffering ( 2 backbuffers ), when i press ALT+ENTER my code switches the frame to Fullscreen and next press on ALT+ENTER toggles it back to windowed.

I have no crash, backbuffers are fine, free reported VRAM is fine, no grpahic glitches, all works fine.

i am now in fullscreen exclusive mode ! the caption is NOT VISIBLE and rendering works fine !

BUT you have to sync rendering with mode switching, i use a mutex for this, i have a variable which enables or disables rendering ( canRender ) and this variable is synced with the mutex ( very important )

i have now a windowed frame WITH CAPTION everything is fine rendering works and available VRAM is now OK ( it happened it version 1.4.1 switching from fullscreen to windowed, i got 0 bytes free from gd.getAvailableAcceleratedMemory() )

the validate helps a lot

P.S.: I use the same Bit Depth in windowed and fullscreen mode ( which is 16Bit )

Toggling decoration on/off when moving between windowed and fullscreen is still broken. (due to buggy code in dispose()

yes this is correct, forget everything is said before. I did some testing and found the following solution.

Use two Frames, one for windowed mode and one for fullscreen exclusive. Switching a Frame from Fullscreen to Windowed is buggy, also the dispose of a Fullscreen Exclusive Frame with Hardware Flipping ( FlipBufferStrategy ) is very buggy, when u dispose such a window it throws exception ( i hope sun will fix this soon).

So with 2 Frames you can switch between windowed and fullscreen without any problem, i use a static variable which gets the current visible frame ( the other one is hidden ).

CurrentJavathread: at sun.java2d.DefaultDisposerRecord.invokeNativeDispose(NativeMethod) at sun.java2d.DefaultDisposerRecord.dispose(DefaultDisposerRecord.java:25) at sun.java2d.Disposer.run(Disposer.java:102) at java.lang.Thread.run(Thread.java:534).....<snip>

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org