Anonymous's picture

Windowed - Full Screen switching

I'm using GLControl in the project I'm working on; converting my project (Scrolling Game Development Kit 2) from DirectX to OpenGL. Things are going great, but I noticed that GLControl, although it has a windowed property, did not (in the version I downloaded) implement it. I too had a windowed property in my DirectX control, but I left it out when I converted my Display control to use OpenTK because I saw that it already had one to be implemented (I hope) at some point. The IDE is fully integrated with OpenTK now and some aspects of it are working better than they did with DirectX, I think. But as I proceed to carry this conversion into the projects generated by the IDE, I wonder if I will be able to allow the generated games to switch between windowed mode and full screen. Is that supported in any form yet, or will it be soon? Or should I find a way to support that manually.

Although I use GLControl in the IDE, I am considering using GameWindow in the generated projects (I haven't checked yet whether that might have better support for switching between windowed and full screen mode).


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Anonymous's picture

Sorry, I thought I looked for an existing post on this topic and didn't find one, but now after I posted I see it already exists. Feel free to carry on the discussion there instead of here if it's more appropriate.

the Fiddler's picture

No problem about the post. The next version, 0.9.1, will include fullscreen support, however this GLControl property will not be implemented. Even so, it's dead simple to implement fullscreen modes with Windows.Forms and GLControl:

// Place in the the parent Form
public void SwitchToFullscreen(int width, int height)
{
    this.FormBorderStyle = FormBorderStyle.None;
    this.TopMost = true;
 
    // Change the resolution of the primary monitor.
    DisplayDevice.Primary.ChangeResolution(width, height, 32, 60.0f);
 
    // Go fullscreen
    this.WindowState = FormWindowState.Maximized;
}

To restore to windowed mode, just restore the original resolution and window appearance.

The DisplayDevice is a new class that will appear in 0.9.1, while the rest of the code can be used with 0.9.0 as is. Hope this helps a little :)

Anonymous's picture

FYI, in my DirectX implementation, I was using a lot more code than that to support switching between windowed mode and full screen, so I'm glad to see that it will be so simple in OpenTK.

Part of it, however, had to do with the fact that, in the IDE usage of the control, it was embedded in an MDI child (which of course resides in an MDI parent). So using the parent window as the host for the full screen display did not work so well and I ended up actually creating a "Cover Window" (a common practice with DirectX as I understand it) that "hosted" the full screen display when switching to full screen mode. I don't think I will bother this time around because I think I will simply not implement full screen support in the IDE (only the generated game) but it might be an interesting idea if you want GLControl to support full screen mode regardless of where it's used. Did you have a (similar) plan?

the Fiddler's picture

We tried the "Cover Window" approach in one of the earlier OpenTK releases (around 0.3.5). The problem with that was that the opengl context was lost, so you had to reload all resources from scratch, and also created some problems in applications with multiple GLControls.

Peronally, I don't think this functionality is worth the added complexity. GLControl is intended for GUI applications, which generally spend their time in windowed modes and In the unlikely chance that it is desirable to make a GLControl fullscreen, you can do this manually (either be embedding the GLControl directly into a new Form or by attaching a new GLContext directly to a fullscreen Form). For other, non-GUI applications, GameWindow is more suitable (due to memory allocations, and general simplicity/usability).

Anonymous's picture

Makes sense. So I assume the Windowed property will be removed from the GLControl interface eventually, then.

BlueMonkMN's picture

Am I understanding correctly that
1) If you want anything in the main game window besides the bare default frame, you have to use a GLControl instead of GameWindow.
2) If you use GLControl, there's no way to implement true full screen support, which, on Windows platforms at least, gains a significant speed boost?

Ergo, if you want any non-default behavior in the main window's frame, you can't get maximum performance? Or does OpenGL not exhibit the same performance advantage in full screen mode that DirectX did?

the Fiddler's picture

1) GameWindow == plain window. GLControl == Windows.Forms integration. GtkWidget == GTK# integration (not yet released).

There are advantages and disadvantages to each one. GameWindow takes care to avoid memory allocations for maximum performance, but cannot use UI controls. The others are heavier, but much more flexible.

2) Can you point me to an MSDN document that describes this performance boost, and how to obtain it?

I am aware that there are at least two "different" fullscreen modes, but as far as I can see the only difference has to do with secondary monitors: in the first mode (exhibited by GameWindow, the NeHe basecode and several games), the secondary monitor is turned off when going fullscreen; in the second (exhibited by Windows.Forms, Call of Duty 4 and several other games) the secondary monitor stays enabled. In both cases, performance is the same.

BlueMonkMN's picture

1) So would the recommended course of action for an application that wants to support windowed mode (with some control over the appearance of the window) and maximize performance be to manually create a separate GameWindow when switching to full-screen mode? Is there a more straightforward option I should consider that bypasses GameWindow (if I want control of the rendering loop or something)? (Maybe use a GLContext more directly?)

2) This page seems to make a couple mentions of the performance advantages of full screen mode. It's talking about DirectX; I'm not sure if something similar applies to OpenGL. The paragraph at the end explains that it's due to the ability to swap buffers rather than blitting, I think:
http://msdn2.microsoft.com/en-us/library/bb205075(VS.85).aspx#Flipping

the Fiddler's picture

Thanks for the link, interesting read. There are a few missing clues on how to enable this mode through OpenGL though, which likely hold the answer to your question: is it possible to enable "real" fullscreen support for a plain Windows.Forms application?

Judging from the document you linked, it seems likely that we: a) need to switch into a natively supported resolution (this is handled by OpenTK) and b) we need to recreate the window handle and its render context. Note, this is just a untested hunch, but I cannot think any other way to enable this mode.

What can you do at this point?

Create a Windows.Forms + GLControl application (you need a GUI so GameWindow will not work). Then, when switching to fullscreen: a) change to the selected resolution, b) reparent the GLControl to a new, topmost, maximized and borderless Form and c) call the RecreateHandle() method on the GLControl. This should allow the OS/driver to enable the "real" fullscreen mode, assuming the hunch is correct.

As I said, this is untested, but I do have a feeling this will work and would appreciate a quick test of the hypothesis.

If you plan to try this, keep in mind that the latest release can only do (b) and (c). For (a) (resolution changes), you'll need to obtain the code from SVN.

rakkarage's picture

how can i get full screen in quickstart with no control or form? thanks