Re: Binary standards for images and sounds

[(Raphael Quinet)]

A few words about the sounds...  IMHO, the binary transfer for the sound files
should be used as a last resort only.  Yes, keep this feature available in the
protocol, but I hope that most clients won't use it.  There are several
reasons for that:

- Different players may like to customize the sounds for different events in
  the game.  The server (during the game) should only send the events names
  or numbers, not the sound file name.  Thus every player would be allowed to
  have a table that binds a sound name to every event.  This table could be
  built from X resources, .INI file, or anything that suits the OS of the
  client.  Naturally, there should be default entries in this table (taken
  from the server when the game starts), but we must allow for customization.

- Most sound files are huge.  It will save a lot of time and bandwidth if they
  are already on the client machine when the game starts.  When the game
  starts, the server sends the default values for the table.  These are event
  numbers or names followed by a sound name.  If the file is not available
  at the client side (and not overriden by user's customization), then the
  client will ask for it.  But not necessarily using an internal protocol...

- The current implementation of the sounds in CrossFire uses the rplay library.
  This library provides automatic sound file fetching if a sound file could not
  be found in the local server.  If this feature is available (I understand
  that some clients won't use rplay), it should be used...  And it has some
  advantages over an internal protocol: it is handled by another process so
  it won't slow down the game, the rplay daemon can get the file from several
  rplay servers (and one of them could have a faster net connection than
  between the CrossFire client and server), it keeps the sounds in a temporary
  cache, etc.

- The latest release of rplay (in beta at the time of this writing) supports
  various sound file formats: .au, .aiff, .wav, ... at 8, 11, 22, 44 KHz, mono
  or stereo.  If a player can have CD-quality sound on his machine, he will
  certainly want to use it instead of the 8 KHz mono sounds.  No problem if
  the files are local and referenced through an event table, but we will loose
  this advantage if the CrossFire protocol wants to use fixed file names or,
  even worst, directly sends its low-quality sound files no matter what the
  client wants.

Most of these ideas also apply to the images.  Why not have a reference table
for the images, so that one client may be able to use different pictures for
some objects, and only use the ones provided by the server if there is no
picture available locally (on the client side) for one object?

Well, actually the images don't need to be as easy to customize as the sounds
should be.  It's easy to change a sound because each sound can be played
regardless of the others.  This is not the case with the images: I don't want
to have a Chinese dragon with the head of a beholder, etc.  Anyway, the
important thing is that we should allow for easy customization on both sides
(client and server).

BTW, this makes one more point in favor of a binary protocol which uses
reference numbers in dynamic tables instead of ASCII commands and file
names...  :-)

-Raphael