[Reality] Color

[Glyph Lefkowitz]

On Tue, 17 Aug 1999, Phil Christensen wrote:

> "Hold up, hold up!"
> 
> Here's yet another reason why we should use a Java client. The action
> box could be converted to a JTextPane which can interpret HTML
> automatically. No further modifications to the software is needed.

And here's another reason why we should use a GTK+ client -- gtkxmhtml.
It's also a good reason *not* to use an HTML-parsing widget though,
because we need those colors to update w/ theme changes, and it could be
pretty obnoxious to have to re-fill that whole buffer from scratch each
time the theme changes!! (w/ GTK, at least, I believe we can keep a record
of all the styles used and change that and post a redraw event... or
something... one day there will be docs for GTK...)

> I'm still not clear on why we're dead set to lose the Java client
> anyways, but then I'm a fanatic.

Well, I figure some other java people are probably wondering that too, so
here's the skinny:

It's slow.  It's ugly.  It takes up a lot of memory.  It requires the user
to have a Java VM installed and know how to use it.  It supports media
other than text poorly, and that can't be fixed in a cross-platform way.  
It is big to download.  Focus management / windowmanager interaction is
broken on most platforms.

Basically, the AWT sucks so bad that it's only really useful for
applications... not games.  The java Faucet is not what I'd call
"immersive" by any stretch of the imagination.  Of course, the GTK+ faucet
isn't that great by those standards either, except that it's fast, light,
easy to install, interacts correctly with all windowmanagers, and gives
users the impression that we support their platform and are "cool".  Java
seems trendy, but not to games folk.

Alternatives to AWT (especially for games) are broken or
non-cross-platform, and usually both. A set of Java wrappers to SDL might
be interesting, except for the fact that then we'd *still* need a JavaVM
and we'd have the cross--platform headaches of dealing with a native
library interacting with different VMs (and different VERSIONS of VMs).

The reasons we keep a java client at *all* are
	
(a) For a reference implementation ... it's easy to keep in sync with the
changes to NetClientUser, and it's easy to manipulate.  Anything native is
going to require GC code and more work.

(b) To allow users of multiple platforms to browse the game, even if the
experience isn't as good as it could be

(c) because James is mostly maintaining it now, and hell, it's free code.  
I'm not gonna complain :-)

Ideally, we should eventually have a full-screen client at a fixed
resolution (640x480 would probably be more than sufficient).  That way
we'd know how exactly how big our descriptions, etc, could be.  It should
be cross-platform, use a solid image rather than a texture for a
background, support sound-effects and music (hopefully both in MP3 format)
and run on Linux, *BSD, Solaris, BeOS, MacOS, and W2k.  SDL is looking
like a good option right now.  It's the Simple DirectMedia Layer (Loki
used it to port Myth and Civ) and it runs on almost all of the above
platforms, although some of the ports aren't finished or supported yet.

Hopefully it would be pretty enough to compete with screenshots from
other, graphical games.  I don't want it to look laden with interactive
graphics -- just polished and professional.  Most importantly, I'd like
something that goes fullscreen.  (Does anyone know of a library like the
one used for Warcraft or Myth which actually includes a widget set along
with a low-level graphics implementation?)  While authoring on such a
client would be impractical, (hence the necessity of the GTK+ client, and
either the java client or lots more native ports) it seems somewhat
unproffesional to have other stuff on your screen at the same time as an
'immersive' game.

Finally, I would also like to learn to work with some funky graphics
stuff.  I'd like to see some nifty effects with text fading in and out and
sliding around as well as the features that I've described.  It's probably
possible to do what I want to w/ the Java version, if we really set our
minds to it -- an xp native plugin for the client which causes the screen
to switch to 640x480, then bring up a Window at 640x480, and put a
JDesktop into that Window, then put a Faucet JInternalFrame into that
JDesktop.  We could then remove the divider-panes, hard-code the pixel
values of the text-boxes, draw some spiffy looking background pictures and
display them using the same JBackgroundThingy (or whatever we're calling
it) that we're using now ... then make calls to external programs to do
the music & sound effects. (a combination of ESD and MPG123 on UNIX would
do fine -- other platforms would have some interesting mixer issues)

Doesn't that sound like a hack though?

> Also, speaking of the same, could we maybe get the ConsolePanel fixed?
> Right now, when you use any arrow key, you need to press the next key
> twice to get it to type correctly (I've encountered this on my PC and
> my Mac)....

I'm thinking that replacing it w/ a JTextField might be a good idea, at
least to demo the performance.  James, how about it?  Put it in there,
release one, use it for a while?