[CF-Devel] Sounds, continued

Fri Apr 30 01:54:22 CDT 2004

Nicolas Weeger wrote:
>

     >

     >

      Hum, that's what i was using names like goblin_death <- to avoid 

     >

      confusing with orc_death sound, for instance.

  But you could have a case for example like 'apply_armor' or something, which 
could be abit confusing.

  Also be aware that the more sound definitions you have, the larger the sounds 
file, which then means more time it takes for the client to download it.  So 
ideally you want some level or commonality for the sounds, so that each 
archetype doesn't need its own sound definition.

>

     >

      I meant, if there are 10 sound event types, objects have a int 

     >

      sound_event[ 10 ] field. So just map event to sound number.

  Don't want to do that - it doesn't scale very well.  Suppose there are 30 
distinct sound events.  If you say each soudn event is 10 bytes (pointer to the 
sound, pointer to optional parameters, and perhaps a couple bytes for volume), 
that starts to really add up in the space.

  Especially since in probably 99% of the cases, an archetype will have at most 
a couple sounds - most in fact probably won't have any sounds.

  Your much better off using a linked list, like the python events.  If 
performance is an issue, you could have a bitmasks which denotes which events 
are actually being set, eg,

if (op->sound_event & (1<<SOUND_EVENT_DIE)) { then we know we should find the 
die event and play it }

>

     >

      Well, make one .snd file with 3 'sound goblin_death' blocks. Server 

     >

      picks the first one only, client will ready 3.

     >

      But yes, if you want to use one for both orc & goblin, you'll need to 

     >

      add 'sound orc_death' somewhere.

  Well, I don't like the idea of three pieces of data having the same name - I 
think that just opens things up to confusion.

  And logically, the code someplace is going to have to collapse those into the 
same data area (eg, the client sees three different ones, and has to know to 
associated them with each other).

  So if that's the case, it probably makes more sense to collapse all the sound 
info into one area, eg:

sound goblin_death
file goblin_death1 20
file generic_death 10
file goblin_death2 20
text die's a horrible death
endsound

  That is probably easier to parse on the client.  Means you no longer have 
duplicate names, or if there are, it is a real error.  It also is likely to make 
it easier on the developers - don't have to worry about hunting down all the 
possible 'goblin_death' sounds in the arch tree either.

  I'd note that for all purposes, the server cares less about the data between 
the sound and endsound line - it's only the client that uses it.  But I'd 
personally think the above syntax is easier to process for the client - it gets 
all the information related to a sound in one block, and doesn't have to hunt 
its data for other info, make linked lists, whatever else.

>

      Hum, got a point there.

     >

      My idea for multiple sounds was to let client handle all that. Server 

     >

      just sends a sound name, client takes care of the case when multiple 

     >

      sounds match and plays one randomly.

     >

      This also lets easily a player customize a sound - tweak .snd file to 

     >

      add or remove customized sounds, without needing server access.

  True, but how is the soundinfo file getting downloaded?  You'd need to add 
some logic like a sounds directory private to the player that means it always 
uses the sound definition in that file vs the one the server tells the client about.

  I'd also think the above syntax would be clearer for that.  EG, if I know I 
want to change the goblin_death sound, I just need that one entry - I don't have 
to hunt them all down, figure out which ones I want, and don't have worry about 
weird issues of how to deal with multiple entries.

>

     >

     >

      Since my proposal was just to add 'sound xxx' to archetypes, editor 

     >

      would (unless i'm wrong) handle that just right.

     >

      Your block idea is nice too, though.

  I'm pretty sure the editor considers each settable variable as something with 
a space.  So I'm not sure if it saw something like:

sound death ...
sound death ...

  If it wouldn't collapse those into one thing or not.

>

     >

      Right, but then you'd need to actually tweak archetypes, rebuilt files 

     >

      and so on just to add your sound. If with a 'sound_maps', your don't 

     >

      need archetypes - just maps.

     >

      (and in both cases, for now, player needs to manually download sound files)

  No you don't.  If there is a sound_maps, you could do something like 'cat 
sound_maps >> sounds' or whatever - there is no requirement to do a full rebuild 
to add a sound event - you could just modify the file directly.

  OTOH, you may really want to do something like the the treasures file - there 
is a basic version in lib, and the collect process collects the ones it finds 
and basically makes a treasures.bld - takes the lib/treasures and adds on all 
the ones it finds in the collect process.

  Such a format is probably useful for those cases where there really isn't any 
good location within the arch directory for a sound (system sounds for example).

>

     >

      I was more thinking of something like:

     >

      #define SOUND_EVENT_LOGIN    "player_login"

     >

      #define SOUND_EVENT_LOGOUT    "player_logout" <- sound names

     >

     >

      but

     >

     >

      #define SOUND_EVENT_CAST_SPELL    1

     >

      #define SOUND_EVENT_APPLY    2 <- number used on 'sound xxx' lines in 

     >

      archetypes

     >

      ...

     >

     >

      but yes, maybe wouldn't be that nice...

     >

     >

      I think basically we both have our ideas about sounds, and they both 

     >

      have advantages & disadvantages :)

  Using text is probably fine.  Perhaps the advantage of having numbers is you 
could fill the table at initial load (eg, system_sounds[]) and thus save time in 
the future (play_sound(system_sound[SOUND_EVENT_DIE])) or the like, where as if 
it is text, there isn't any quite as efficient startup mechanism (you could 
store the text strings in an array, and associate the sound info with it, and 
then when it comes time to play a sound, it only has to look through that more 
limited array vs all the sounds).

  OTOH, for most of those 'global' event sounds, probably not played so often 
that efficiency is that important anyways.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel