Full-screen behaviour and game documentation

Per Inge Mathisen per.mathisen at gmail.com
Sat Jul 2 12:52:46 PDT 2011


Hello,

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).

On Sat, Jul 2, 2011 at 9:04 PM, Guus Sliepen <guus at debian.org> wrote:
> 1. Full-screen behaviour of games
>
> 1.1. Should games, by default, start in windowed mode or full-screen mode?

When fullscreen works out of the box almost all the time, games should
start fullscreen, since this is how gamers intend to play the game.
(This applies to most games that can be fullscreen, but obviously not
all.) However, since fullscreen on Linux is a sorry mess, my opinion
is that games should start windowed on Linux for the time being (and
start fullscreen on other platforms).

> 1.2. What should the preferred hotkey be to switch between windowed and full-screen?
>
> There are various hotkeys used to switch between the two modes, some more
> common ones are F11, F, Ctrl-Enter. F11 seems to be used in many
> window-managers and non-gaming applications.

Alt-Enter is also frequently used.

> multiple screens are often badly supported, resulting in the game running
> stretched across all screens when this is not desired, or the game running in
> the resolution of one screen but "centered" in the middle of two screens.

Often seen with the Nvidia binary blob driver, which does not support
Xrandr and does its own thing instead. Hopefully Nvidia will fix this
soon.

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

> 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.

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.

> 1.4 Windowed behaviour
>
> When windowed, it is expected that the game plays nice with the other
> applications that are running on the desktop.  When the game grabs the mouse
> and/or keyboard input for itself, the user cannot interact with other
> applications anymore.  Some games only grab the input when you are actually
> playing the game, and release it when paused or in menu screens.  This should
> be recommended behaviour.

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.

> 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.

> 1.5 Interaction with the window manager
>
> Some games bypass the window manager completely when entering full screen mode
> (using DGA or other ways).

This should be strongly discouraged.

> 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.)

  - Per


More information about the Games mailing list