[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Full-screen behaviour and game documentation

On Sat, 2 Jul 2011 21:52:46 +0200
Per Inge Mathisen <per.mathisen@gmail.com> wrote:

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

Nice! Do you want to start one for SDL games too? ;)

> On Sat, Jul 2, 2011 at 9:04 PM, Guus Sliepen <guus@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).

Sad but true :(

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

Is Xrandr supported on other platforms? (eg the bsds).

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

> X11 offers no decent API for handling these issues. [...]  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.

While Xorg must be aware of the problem, is there any official tracking
of it going on? (eg, bug reports). Would having X handle this stuff
mean games could cut any large chunks of code out of their codebases?

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

I like the idea, especially if it can be disabled somehow (incase
you're clumsy :)).

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

And in some cases not relevant - turn based games (i'm thinking
freeciv) can be left at any arbitrary point and nothing will happen.

Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
No, I won't join your social networking group

Attachment: signature.asc
Description: PGP signature

Reply to: