the Fiddler's picture

0.9.1 progress report: Fullscreen support round 2

After a long fight with cryptic Xlib documentation, OpenTK gained the ability to change display resolutions under Linux. The current implementation uses XRandR, so it will only work on fairly new distributions, but fallbacks will be added in later versions to improve compatibility.

This means that fullscreen modes and resolution changing are now supported under both Linux and Windows. There are still a few rough edges (gnome panels stay in front of the window on x86_64 linux, but work correctly on x86), but these will be ironed out gradually.

So what else to expect in 0.9.1? Inertia has written a few OpenAL and GLSL examples which will show up in Examples.exe; JTalton's double precision math routines are slowly being merged; the AudioContext class will take over ALC and ALUT (these will not be publicly available anymore); multiple contexts will share resources by default; a few namespaces will change slightly; and several parts of OpenTK will attain beta status.

Wait, what? (read more)

Yes, that's correct. From 0.9.1 onwards, no breaking changes will happen in the core OpenGL, OpenAL and GLControl API, unless they are fixing bugs. A more complete list with "stable" and "unstable" parts will be published soon.

Last, but not least, a question: how should GameWindow.Fullscreen = true work? Should it only change GameWindow.Width/.Height to make it cover the whole screen, or should it change the monitors resolution too?


Comment viewing options

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

First of all, awesome news about full screen support in Linux! One question though, will this work with Xgl as well? I've noticed that full screen, for many games, does not work well when running Xgl.

And to answer your question. It seems more intuitive to me that "GameWindow.Fullscreen = true;" should mean, "expand this window so that it covers the full screen." Instead of, "change my screen resolution so it matches the size of this window." So basically, I think that it should only change the width/height of the game window. If the programmer wants to change the screen resolution, he/she should do that separately.

kanato's picture

I think the way to go would be have something more like GameWindow.SetFullscreen(int width, int height, int bpp) (or maybe a function taking a structure describing a display mode obtained from an EnumerateDisplayModes or SelectClosestDisplayMode function).

Changing the monitor's resolution with a property seems like a bad interface, because if your window is a strange size it would have to be resized to cover the area correctly, which may mean a change in aspect ratio, so the projection matrix has to be recalculated, etc.

Edit: Oh, the other reason I think this should be a method is because what if you want to change full screen resolutions, without going to windowed first? Another call to SetFullscreen would be all that is required with a method. But if you change width/height through properties, then you'd have to either update the resolution each time a property changes, which would result in multiple resolution changes, or change properties and do something else to trigger a resolution change, which could result in values read from the properties of the GameWindow being inconsistent with the actual values used.

the Fiddler's picture

@Stevo14: I do not use Xgl, so I can't say whether it works, but I wouldn't be surprised if it doesn't. Fullscreen is one of these "implementation defined" X11 parts (which basically means it depends your window manager's version, revision, buglist and time of day). Yes, I'm a bit fed up with this overengineered X11 madness :) I'll make sure it works with Aiglx though, if that's any consolation, and we can always beat Xgl into submission if it starts misbehaving.

Btw, it would be great to have some feedback on Xgl, so if you use that grab a copy off SVN and try running a few examples (you'll need either nant or monodevelop - cd to Build/ and type "mono Build.exe mono debug").

@kanato, Stevo14: ok, it seems changing the monitor res on a boolean property is not a good API. A function it is, then.

Btw, you can already query the list of supported resolutions per monitor (returns a list of DisplayResolution structures). I'll also add a function to match a custom res to the closest available one.

@kanato: GameWindow's properties are only updated when the relevant message arrives from the window manager, so they shouldn't fall out of sync. This part isn't 100% complete though, e.g. it doesn't detect state changes due to alt-tabbing or minimizing yet.

One more question: Should the window position be queryable/changeable?

Stevo14's picture

I grabbed a copy of OpenTK from subversion and the basic story is as follows:
Everything works great as long as you stay in windowed mode. Switching to full screen mode (via. alt-enter) causes the content to be offset from the center of the screen for several seconds. After which it re-centers itself and continues normally. Xgl also completely crashed about every third time I switched to full screen (by crashed I mean the screen blinked, blacked out, did some flickering thing and came back up at the login screen).
This, however, is about how things go with every other 3D application I use under Xgl. The solution is to simply stay in windowed mode and maximize the window to increase the viewing area.

EDIT: Forgot your question.

Yes I think it would be handy to be able to get/set the window position, although I can't think of a use for it right now.

Inertia's picture

After giving it some more thought, I believe it'd be best to use the terms "maximize" and "fullscreen" to be more explicit what we're talking about. A game typically will be fullscreen, to increase the player's immersion into the game. I don't really see any use for a command to maximize the window without hiding the borders (in GameWindow that is, if you want to use forms GLControl is the better choice), can someone give an example scenario where it would be desireable to maximize the form with a command? (Imho there's the maximize button at the top-right for that)

It might be nice to add a "minimized" property though, so an app can check for that and pause the game.

lubos's picture

im sorry to post it here, but what about forum for off-topic? or where should one posts his own project using opentk, for example?
and the last idea, sending PMs would be cool, too:)

the Fiddler's picture

[Off-topic forum]
Good idea.

[Personal Projects]
Working on it ;) There will be a project gallery, too.

Good idea - give me half an hour and I'll cook something up.

lubos's picture

that was damn fast :D

GOoOGle's picture

This is a really good news !
But i think i have a different way of thinking about the fullscreen mode.
When i play to a game, like bubble frozen under linux, i have to choose a resolution, and i have to choose the windowed/fullscreen mode.

What happens when i take the 800x600 resolution by example is :
windowed mode :
i have a small window on my desktop.
fullscreen mode :
When i switch to the fullscreen mode, the real change is the change of resolution for the game. In fact, when i do this switch, the resolution still stays to 800x600 pixels but on my screen it's on the whole screen. So when you pass to the fullscreen mode, nothing is changed for the glOrtho and so far, because of it's only the window's manager which adapt the window to the fullscreen.

So i can change also the resolution of my game, and this change only the number of pixels in width and height. if i am in windowed mode, on game pixel is one pixel for the current resolution of your desktop, so if the game resolution is less than your desktop resolution, you can see just a window on your desktop. if you are in fullscreen, you have to choose exactly the same resolution than your desktop resolution to still keep one game pixel = one desktop pixel.

So if you want the width and height change, it's should be a special intent from the developer to do this when you ask maximise.
By example, if i develop a game which works exclusively for 640x480 resolution, because of i prepare my texture only for this resolution, i would like to be able to pass through a fullscreen mode which still keep my 640x480 resolution, but which just increase the size of my game pixel. Like this, i will see in fullscreen a pixelized render, but in fullscreen mode.

I hope you will understand my explanations, or if not just ask me again !

zombo09's picture

Fantastic blackjack learn forex online craps online roulette online bingo