Full-screen behaviour and game documentation

[Guus Sliepen]

On Sat, Jul 02, 2011 at 09:52:46PM +0200, Per Inge Mathisen wrote:

> Thanks for raising this interesting topic. I am in the middle of
> muddling through these issues myself for the Warzone2100 project, and
> recently started a portable library for fullscreen handling for Qt
> (http://gitorious.org/qtgame).

Great!

> Not sure if games should be encouraged to use Xrandr (yet?), but that
> should be considered.

Are there other ways to get the (multi-)screen geometry besides xrandr?

> > Apart from not handling the full-screen situation itself incorrect, when the
> > game uses a different resolution in full-screen mode than the desktop uses,
> > some games do not properly restore the desktop resolution when quitting or when
> > switching back to windowed mode. Sometimes they do when quitting via the main
> > menu, but not when quitting through other means.
> 
> So should games grab various signals to avoid this? Or spawn a daemon
> process to restore the screen if the host process dies? Both
> approaches are ugly as heck and fertile grounds for bugs.

Spawning a daemon goes a little bit too far, I would say. But handling QUIT,
TERM and INT signals would be nice, as well as blocking or handling signals
like HUP, ALARM, PIPE, and handling the case where the user closes the window
through the window manager, instead of clicking on a quit button inside the
game.

> X11 offers no decent API for handling these issues. Windows has a very
> nice API here, where you request screen resolution and fullscreen at
> the same time, and where the OS will clean up after you if the process
> dies, for any reason, and handles resolution changes if you alt+tab
> between applications. I believe MacOSX also has a similar API. X11
> lives in the dark ages here, where each application has to do
> everything on its own and in addition handle a number of window
> managers, each slightly different.

Ah, so perhaps the current APIs to change the screen resolution should be
extended to handle this (except when it is desired, of course, such as when
using the xrandr utility).

> IMHO a game should never block alt+tab, and on alt+tab, resolution
> should be restored and any cursor trapping should be released.
> However, I am a bit unsure how to implement this in a sane manner.

I agree, unless that is a combination that is likely to be used in the game
itself. But it should never be blocked when the game is paused or in a menu.

> > It would also be nice if the game, when running, automatically pauses when it
> > is running windowed and another window gets focus.
> 
> That is fine for single player games. For many multiplayer games that
> is not an option.

That is true. On the other hand, when the game window doesn't have focus
anymore, you cannot continue playing the game anyway. However, in many FPSes,
you can chat with other playeres, and while in chat mode you see a text balloon
over the player's model, or something else to indicate that you're not really
playing at that moment. Perhaps this could be automatically enabled when the
window doesn't have focus.

> > Some games bypass the window manager completely when entering full screen mode
> > (using DGA or other ways).
> 
> This should be strongly discouraged.

So xrandr is the way to request resolution changes?

> > However, most window managers understand the concept of a full-screen window
> 
> Which window managers do not? (I have had some issues with fwvm, but I
> am not sure where the problem resides.)

I don't know, I'm used to metacity and xfwm.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/games/attachments/20110703/f2e94313/attachment-0001.pgp>