New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to toggle full screen using WindowsGL #1754

Closed
klutch opened this Issue May 26, 2013 · 7 comments

Comments

Projects
None yet
4 participants
@klutch
Contributor

klutch commented May 26, 2013

I want to have an options screen in my game that will allow the user to toggle full screen and change resolutions, but I'm running into problems.

I'm using the WindowsGL build on Windows 7, and am using Visual Studio 2010.

To test the issue, I created a new MonoGame project, and in Initialize(), set

graphics.PreferredBackBufferWidth = 1366;
graphics.PreferredBackBufferHeight = 768;

and then made the spacebar toggle full screen in Update() by doing

if (newKeyboardState.IsKeyDown(Keys.Space) && oldKeyboardState.IsKeyUp(Keys.Space))
  {
    graphics.IsFullScreen = !graphics.IsFullScreen;
    graphics.ApplyChanges();
  }

Pressing space the first time successfully switches to full screen. Pressing it again exits full screen, but leaves my screen's resolution the same size (1366x768 instead of 1680x1050):

fullscreentest

That was using the MonoGame.Framework.dll that's located in C:\Program Files (x86)\MonoGame\v3.0\Assemblies\WindowsGL

I've also tried cloning the develop branch and compiling the WindowsGL project. Using that MonoGame.Framework.dll, pressing space the first time gives me the result as the image above, and every press after that does nothing.

I apologize if this issue has been mentioned before. I used search and couldn't find anything.

Here is the complete code I'm using to test this: https://gist.github.com/klutch/5652781

Thanks

@flibitijibibo

This comment has been minimized.

Show comment
Hide comment
@flibitijibibo

flibitijibibo May 27, 2013

Contributor

For others with this problem (I've already given this to klutch), MonoGame-SDL2 should be able to run this test app:

https://github.com/flibitijibibo/MonoGame

Contributor

flibitijibibo commented May 27, 2013

For others with this problem (I've already given this to klutch), MonoGame-SDL2 should be able to run this test app:

https://github.com/flibitijibibo/MonoGame

@flibitijibibo

This comment has been minimized.

Show comment
Hide comment
@flibitijibibo

flibitijibibo Jul 10, 2013

Contributor

Wanted to see if this was still a problem in MonoGame. I have this fix that I want to pull for MG-SDL2->upstream...

https://github.com/flibitijibibo/MonoGame/compare#L19R677

I think this was the issue that sparked it? I swear there was another Cornflower Blue issue that was related to this...

Just need to be sure that I'm referencing the right issues when I submit this block of code to the core team.

Contributor

flibitijibibo commented Jul 10, 2013

Wanted to see if this was still a problem in MonoGame. I have this fix that I want to pull for MG-SDL2->upstream...

https://github.com/flibitijibibo/MonoGame/compare#L19R677

I think this was the issue that sparked it? I swear there was another Cornflower Blue issue that was related to this...

Just need to be sure that I'm referencing the right issues when I submit this block of code to the core team.

@klutch

This comment has been minimized.

Show comment
Hide comment
@klutch

klutch Jul 12, 2013

Contributor

Sorry it took me a few days to respond. Yea, this is still a problem.

Contributor

klutch commented Jul 12, 2013

Sorry it took me a few days to respond. Yea, this is still a problem.

@flibitijibibo

This comment has been minimized.

Show comment
Hide comment
@flibitijibibo

flibitijibibo Jul 13, 2013

Contributor

This issue may apply to this pull request:

#1860

I don't think it actually fixes it, but it does change behavior that's worth looking at. We'll probably still need to apply my changes.

Contributor

flibitijibibo commented Jul 13, 2013

This issue may apply to this pull request:

#1860

I don't think it actually fixes it, but it does change behavior that's worth looking at. We'll probably still need to apply my changes.

@klutch

This comment has been minimized.

Show comment
Hide comment
@klutch

klutch Jul 15, 2013

Contributor

For anyone interested, I think this might be two separate issues. The first issue is toggling full screen does nothing after the first toggle. The second issue is not restoring the resolution when exiting fullscreen.

I was able to fix the issues with subsequent toggles not working by adding this line to the bottom of OpenTKGameWindows's ToggleFullscreen method:
window.WindowState = windowState
I suppose that's kind of hacky, since it looks like the window state should be updated in the UpdateWindowState method.

For the second issue, I think it's a bug in OpenTK. I ran into this forum post which seems to describe the exact problem I'm having: http://www.opentk.com/node/2840

The ResetWindowBounds method in OpenTKGamePlatform makes a call to OpenTK.DisplayDevice.Default.ChangeResolution if graphicsDeviceManager.IsFullScreen is true, and makes a call to OpenTK.DisplayDevice.Default.RestoreResolution if it's false.

ChangeResolution correctly sets the current display resolution to a variable called original_resolution before changing, but when RestoreResolution is called, original_resolution is always null... which means the original resolution never gets restored.

Contributor

klutch commented Jul 15, 2013

For anyone interested, I think this might be two separate issues. The first issue is toggling full screen does nothing after the first toggle. The second issue is not restoring the resolution when exiting fullscreen.

I was able to fix the issues with subsequent toggles not working by adding this line to the bottom of OpenTKGameWindows's ToggleFullscreen method:
window.WindowState = windowState
I suppose that's kind of hacky, since it looks like the window state should be updated in the UpdateWindowState method.

For the second issue, I think it's a bug in OpenTK. I ran into this forum post which seems to describe the exact problem I'm having: http://www.opentk.com/node/2840

The ResetWindowBounds method in OpenTKGamePlatform makes a call to OpenTK.DisplayDevice.Default.ChangeResolution if graphicsDeviceManager.IsFullScreen is true, and makes a call to OpenTK.DisplayDevice.Default.RestoreResolution if it's false.

ChangeResolution correctly sets the current display resolution to a variable called original_resolution before changing, but when RestoreResolution is called, original_resolution is always null... which means the original resolution never gets restored.

@flibitijibibo

This comment has been minimized.

Show comment
Hide comment
@flibitijibibo

flibitijibibo Jul 15, 2013

Contributor

The ToggleFullscreen issue might just be the fault of how we do ToggleFullscreen in develop. The only real change I needed for MG-SDL2 was to add Enter/ExitFullscreen in that method:

https://github.com/flibitijibibo/MonoGame/compare#L48R373

The second issue... yeah, good ol' OpenTK. Though if we don't need the Game.cs changes for this stuff to work properly in MG-SDL2 that'd be one less thing for us to pull into upstream. I was mostly worried about this just being a general issue.

Contributor

flibitijibibo commented Jul 15, 2013

The ToggleFullscreen issue might just be the fault of how we do ToggleFullscreen in develop. The only real change I needed for MG-SDL2 was to add Enter/ExitFullscreen in that method:

https://github.com/flibitijibibo/MonoGame/compare#L48R373

The second issue... yeah, good ol' OpenTK. Though if we don't need the Game.cs changes for this stuff to work properly in MG-SDL2 that'd be one less thing for us to pull into upstream. I was mostly worried about this just being a general issue.

@xanather

This comment has been minimized.

Show comment
Hide comment
@xanather

xanather Jul 15, 2013

Contributor

WindowsGL has always had windowing problems due to OpenTK. Switching to MonoGameSDL2 under flibitijibibo's MonoGame fork fixed all WM problems for me.

Contributor

xanather commented Jul 15, 2013

WindowsGL has always had windowing problems due to OpenTK. Switching to MonoGameSDL2 under flibitijibibo's MonoGame fork fixed all WM problems for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment