On Sat, 2 Jul 2011 21:04:47 +0200
Guus Sliepen <guus@debian.org> wrote:
> Hello,
>
> I would like to raise two issues that have recently been discussed at
> the #debian-games meeting[0] at June 26th. In both cases we would
> like to know the answer to this questions: What is the recommended
> behaviour/best practice for upstream developers? Please comment.
Thanks for taking this up.
> 1. Full-screen behaviour of games
[...]
> 1.3. How should games enter and leave full-screen mode?
>
> Not all games (or other applications for that matter) handle
> full-screen correctly in all situations. The first problem is that
> "non-standard" aspect ratio (ie, not 4:3. 16:10 or 16:9) are
> sometimes not supported. Second, the actual screen size is sometimes
> not supported, either because there is a hardcoded list of
> resolutions to choose from, or that libraries such as SDL report more
> possible resolutions than fit in an array with a hardcoded size (and
> consequently some are then ignored by the game). Third, setups with
> 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.
I'm amazed there aren't libraries to link against which handle all/most
of this. Is it much much harder then i'm imagining it is to do this
generically, or is it simply that no one has tried to do it like that
before?
> 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.
> 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.
>
> It would also be nice if the game, when running, automatically pauses
> when it is running windowed and another window gets focus.
Isn't this affected (at least in part) by the problem in 1.3, where
games don't exit full screen cleanly?
> 1.5 Interaction with the window manager
>
> Some games bypass the window manager completely when entering full
> screen mode (using DGA or other ways). However, most window managers
> understand the concept of a full-screen window, and they might have
> hotkeys or menu options to toggle the full-screen state of arbitrary
> windows. Games should honour the window manager hints, and possibly
> always request full screen through the window manager.
sounds reasonable.
> 2. Game documentation
>
> 2.1 How to make game documentation available in the desktop
> environment
>
> What is the recommended way to register documentation for games so
> that desktop users can easily find it? Debian uses the doc-base[1]
> system to have applications register their documentation, which is
> similar to .desktop files, allowing documentation browsers to find
> out what is available. There is no way to reference documentation
> in .desktop files as far as I know, and I do not know of any other
> standard to keep track of documentation.
Would it be worth using doc-base (or something like it) as the
recommended way to handle it?
> 2.2 How to make documentation available from within the game
>
> Not all games have in-game documentation browsers, and one can argue
> that in most cases it would just be a duplication of work, since
> there are already many stand-alone documentation browers that one can
> use. What is the recommended way to request a documentation browser
> to be started given a filename or (local) URL to the documentation?
Yelp can take a file on the command line, perhaps other DEs have a
similar tool that could be used. (I'm thinking something like xdg-open
but to launch {html,xml,???} docs from games).
> Of course, the game should properly switch to windowed mode while the
> documentation browser is running.
yup
> 2.3 What is the preferred format of documentation?
>
> There are many different documentation formats (HTML, PDF, text,
> manpages, info manuals, et cetera), but what format should be
> recommended, such that the user has the best experience?
html is probably easiest for upstreams - they can stick it on their
websites or in the release tarballs and have browsable docs,
while building from the same source.
What about games which handle doco in completely different ways?
Freeciv has a help browser modeled after Civilization IIs Civilopedia.
> 2.4. What should the preferred hotkey be to get help?
>
> It seems F1 is commonly used to bring up help, so games should use
> this too if possible.
As long as its optional - F keys are commonly used for other purposes
in games.
> That's it, please comment! After discission, I will put the resulting
> recommendations in freedesktop.org wiki pages.
Thanks for doing this!
kk
> [0]
> http://meetbot.debian.net/debian-games/2011/debian-games.2011-06-26-09.57.html
> [1] http://wiki.debian.org/doc-base
>
--
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group
Attachment:
signature.asc
Description: PGP signature