From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Re: Weird fuel behavior
Date: Tue, 20 Jul 2004 23:12:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.44.0407201743370.7628-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <l03130302bd232c1c91d6@[212.181.162.155]>
On Tue, 20 Jul 2004, Hans Ronne wrote:
> at first. However, Stan long ago pointed out that professional games almost
> never use multiple windows since "users don't like Office-type
> applications".
I think this is true for 3D shooters (such as Unreal) or
some simple (many things are highly automated) realtime strategy
games (such as Warcraft), but not necessarily true for
strategy games where there are multitudes of forces of different
kinds to track and manage, and there is not heavy automation of
their actions.
>And I think he has a point here. You can go a long way with
> just one screen and panes instead,
Well, I think even panes should be kept to a minimum. Believe me,
I like the "clean rectangle" concept that SDL offers, but there
can (and should, IMO) be windows that can be popped up demand to
display various useful summaries and sets of details. The Tcl/Tk
interface is way too cluttered and some things, such as the unit
list, have minimal usefulness (construction and change-type
selections should be done through a popup dialog window, and not
through the unit list).
The driving concept should be: which info is so useful that it
should always be displayed, and which info is only occasionally
useful (but useful nonetheless) so that it should be kept in an
on-demand display?
> What you can do with SDL, I believe, is transparent overlays and such. Not
> the same thing as a floating window but a decent alternative.
This might be acceptable for a pure SDL implementation, if someone
felt like taking the effort to make such "windows". My guess is
that true popup windows could be much more rapidly implemented
(with expected UI components) using something like GTK.
Eric
next prev parent reply other threads:[~2004-07-20 22:07 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-17 9:50 Robert Goulding
2004-07-17 9:57 ` Hans Ronne
2004-07-17 14:16 ` Robert Goulding
2004-07-17 20:06 ` Hans Ronne
2004-07-17 20:31 ` Robert Goulding
2004-07-17 21:13 ` Hans Ronne
2004-07-17 21:31 ` Robert Goulding
2004-07-18 13:07 ` Hans Ronne
2004-07-18 20:20 ` Robert Goulding
2004-07-18 22:14 ` Hans Ronne
2004-07-18 22:16 ` Eric McDonald
2004-07-19 2:50 ` Hans Ronne
2004-07-20 8:05 ` Jim Kingdon
2004-07-20 13:38 ` Hans Ronne
2004-07-20 19:19 ` Jim Kingdon
2004-07-20 19:50 ` Hans Ronne
2004-07-20 21:36 ` Eric McDonald
2004-07-20 22:07 ` Hans Ronne
2004-07-20 23:12 ` Eric McDonald [this message]
2004-07-21 0:32 ` Stan Shebs
2004-07-21 0:47 ` Eric McDonald
2004-07-21 1:11 ` Hans Ronne
2004-07-21 1:33 ` Eric McDonald
2004-07-24 23:19 ` Action-Notices list Elijah Meeks
2004-07-26 1:31 ` Eric McDonald
2004-07-21 0:55 ` Weird fuel behavior Hans Ronne
2004-07-24 20:50 ` Eric McDonald
2004-07-20 15:17 ` Eric McDonald
2004-07-20 15:40 ` Jim Kingdon
2004-07-19 3:07 ` Robert Goulding
2004-07-17 12:47 Hans Ronne
2004-07-19 8:07 Robert Goulding
2004-07-19 18:14 ` Hans Ronne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44.0407201743370.7628-100000@leon.phy.cmich.edu \
--to=mcdonald@phy.cmich.edu \
--cc=hronne@comhem.se \
--cc=xconq7@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).