Complete.Org: Mailing Lists: Archives: freeciv-dev: August 1999:
Re: [Freeciv-Dev] Sound support
Home

Re: [Freeciv-Dev] Sound support

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: joelh@xxxxxxx
Cc: freeciv-dev@xxxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Sound support
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Thu, 19 Aug 1999 14:41:31 +1000 (EST)

Joel Ray Holveck <joelh@xxxxxxx> wrote:

> However, because of the resource file change, then perhaps you could
> recommend a (post-change) date that has a relatively non-buggy version
> of Freeciv.  Since I haven't been following the tree, I also don't
> know how frequently bugs make it in, or how major they are.

The cvs version is free of serious bugs most of the time; 
I can't think of any particular dates that would be better 
than others.  Though be aware the cvs version is currently
occasionally breaking network game-play compatability (in a 
controlled way).  

> * In favor of the server-side configuration:
> 
> ** Modpack support
> 
> Without server-side configuration, if the server has a fairly
> different modpack that the client doesn't have, then the sounds played
> will be utterly inappropriate for the game.

Right.  Modpacks don't exist much in practice now, but it
would be nice to support them as well as feasible.

> * In favor of the client-side configuration:
> 
> ** Bandwidth
> 
> Sending the sounds over a link can be very slow. 

Ouch, no, I wasn't suggesting that.

> ** Configurability
> 
> A user should be able to select his own look & feel.  I prefer one
> tileset over the other.  I've already heard from people who have made
> other soundsets from other proprietary games.  (Okay, one person.)
> Unix has a fine tradition in which everything is configurable on a
> per-user basis, and I like it.

Yep.  Of course if a user wants to hack freeciv and/or move sound 
files around, it can be infinitely configured :-)  But its nice to
make it easier.

> -----
> 
> Now, we could get around the bandwidth and configurability problem by
> sending tokens instead of sound filenames. 

Yes, this is my preference, and basically what I'm doing
with tilespecs.  Though since sounds seems to be one per
file (unlike graphics), then it may be fine to send the 
filenames themselves as the tokens.  The important thing as 
far as I'm concerned is that the _server_ read the tokens/
filenames from the ruleset, and send the tokens/filenames 
to the client.

>  Then, you still have to have a sound token -> filename
> mapping back on the client side, and end up with something no
> different than reading the filenames out of a file mapping
> units -> filenames to begin with.

Well, there is a difference whether the server reads them out,
or whether the client reads them out.  You may have a modpack
which shuffles some of the units around and changes some of their
names (eg, Civ1/Civ2-specific rulesets or similar), but still 
re-uses the same sound files as normal freeciv.

>  2) You haven't downloaded the modpack.  Your tileset shows alpine
>     troops, but the server is talking about an orcish mob.  Now, do
>     you want the sounds to be coherent with the tileset, or with the
>     unit name strings?  If you use tokens (filenames or another
>     abstract token) instead of sending the sound data, then the
>     problem is exacerbated: you don't even have the sounds that the
>     server is referring to (since you didn't download the modpack), so
>     you will be playing without any sound at all.

In this case, it seems to me that not playing any sound may
indeed be the correct behaviour, rather than playing inappropriate
sounds.  Or, have the ruleset specify, and the server send, 
multiple alternative tokens, where the first is a specialised 
sound the client will have if it is using the right sounds, 
and the second is a fallback which should be a sound all 
clients are expected to have.

Actually, with tilespec changes, in the above case the client 
probably _won't_ show an alpine troop in this situation, and will
have no reason to think "alpine troop" at all, since U_APLINE will
have gone away, and all the client knows about the unit is what
the server tells it.  (What graphic _will_ it show?  I guess either
nothing (just the national flag and a hp bar), or a fallback graphic
depending on the ruleset, or it would be nice to have a further
fallback to some generic unit icon, eg a box.)

Of coure tilespec stuff is also open to suggestions, once I
release some more information on what I've done so far :-)

Its fair to say that currently its up to the user to make sure
they're using an appropriate tileset if the server is using
some non-standard modpack.  For graphics its somewhat hard to
do this better, since currently the client loads all its graphics 
before it even connects to the server to find out game information.

> I'll look for the tilespec stuff.  I haven't been following the
> mailing list very closely, either, I'm afraid, but my machine keeps it
> archived for a few weeks.

I only just posted a short note, and the list is currently slow...

Regards,
-- David

[Prev in Thread] Current Thread [Next in Thread]