[CF-Devel] About sounds

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:

>
     
     
     >
     
      I was thinking something like 'position, propagation direction'. This 
     
     >
     
      way, client could apply doppler effect, so player knows which way the 
     
     >
     
      spell is going. Ie hear it getting closer, or away, or in a different 
     
     >
     
      direction. Imagine hearing a big fireball coming towards you ^_^
     
     
  Well, that could certainly be done - in addition to relative position of the 
sound, the direction it is heading could be included in info sent to the client.

  I do have to admit that I don't know enough about sound processing to know how 
trivial/hard it would be to do those doplar effects.

  The thing you'd really want to do, which is perhaps harder, is for the sounds 
to change intensity as they move.  But this then requires knowing how fast the 
object emanating the sound should be move.

  For example, that lightning bolt should be getting louder as it gets closer. 
However, the problem is that if the sound is played when cast, it gets played 
from where it is cast - so to know it is getting closer gets trickier - you only 
want to play that sound once.  This gets even more complicated as the player 
himself may be moving, which should effect the accoustices (if the player is 
moving away, the sound shouldn't be getting louder).



>
     
      That sounds like a nice idea.
     
     >
     
      But that means we need a sound list (to match filename/name, duration) 
     
     >
     
      and link it to archetypes.
     
     
  A sound list can easily be generated as part of the arch collection, just like 
the images are.

  After all, no place in the arch's are image numbers referenced - just names. 
during the collection, it then maps the names to numbers, and within the server 
itself, numbers are used for everything.

  Same can happen equally easily with sounds - it can generate a list of all 
referenced sound names, and writes out a file with numbers.


>
     
      Agree there on pushing. But still we could find a way to let the client 
     
     >
     
      download from server. Maybe something like: client asks for sound file 
     
     >
     
      fireball.raw, bytes 2000 to 2999, and server sends that back? This way 
     
     >
     
      the client would have the responsibility of downloading (and adjusting 
     
     >
     
      speed, 100b or 1000b at a time, with a cap), server wouldn't care. But 
     
     >
     
      it'd require opening/closing the sound file often for the server.
     
     
  The open/closes get to be a problem (note that for the images, it loads them 
all into memory).  I suppose if all the state is stored on the client side, not 
a big deal, but seems to add a lot of complication.


>
     
     
     >
     
      Now that'd be a great idea, to have different sounds for same effect.
     
     >
     
     
     >
     
      Though I'd rather see some archetype lines line
     
     >
     
       sound_event apply name volume duration <and so on>
     
     >
     
      instead of
     
     >
     
       sound_apply name <...>
     
     >
     
     
     >
     
      Makes it easier to add new events without having to change parsing logic.
     
     
  Doesn't really make any difference.  If now sound_events are added, the parser 
has to get updated to know that there is a 'spell_expire' event or whatever.  So 
whether it is listed as 'sound_spell_expire' or 'sound_event spell_expire', the 
parser still has to deal with that to convert that to the proper numerical data.

  After all, within all the code itself, there will be various known events, eg, 
apply, spell_cast, object_activate, etc, which are mapped to various things.

  Also, look at how the body_ stuff is handled in the client - very simple and 
could be done the same way with the sound stuff.

>
     
     
     >
     
      In the same topic (but different thing), I'm thinking of tweaking the 
     
     >
     
      loading parser to be able to write 'type KEY' or 'type DOOR' instead of 
     
     >
     
      'type <number you always foget>'.
     
     
  I take it be able to ready those type of things, not write them.

  I'm much less concerned about the write logic (although the write logic is 
easier).  However, for some aspects, like temp maps, you probably want the 
format that is faster to parse, which is integer.  So for the write logic, 
probably want a flag like 'write as numeric values (which would be used for the 
swapped out temp maps)' and 'write as text', which might be used for things like 
player files.

  However, if I was going to choose the one thing to convert to string form, it 
would be the attack types and spell paths.

  Figuring out those bitmaps is non trivial in most cases (even if you look at 
attack.h, you typically need to do some math to know what attacktype 391 really 
is).  For the basic types, that's much easier to look up - no math required.




_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel