[Freeciv-Dev] Re: sound development

["Sam BC" <sambc@xxxxxxxxxxxxxxxxxxx>]

As far as I can see it would be best to implement the playing of sounds (not
generation of events & in-code function calls) in the same vain as the GUI
clients, selecting one at ./configure time. Then we get the huge benefit of
portability as different C-files can be used for various *NIX sound systems
(OSS(/free), ALSA, various libs, esd, etcetc) & for windows,amiga,BeOS &
MacOS/OS X even.


Just my £0.02

SamBC

> -----Original Message-----
> From: hunter@xxxxxxxxxxxx [mailto:hunter@xxxxxxxxxxxx]On Behalf Of Jarda
> Benkovsky
> Sent: 29 June 2000 10:33
> To: Tuomas Airaksinen
> Cc: freeciv-dev@xxxxxxxxxxx
> Subject: [Freeciv-Dev] Re: sound development
>
>
> Tuomas Airaksinen wrote:
> > And others that are listed on sound development page at
> freeciv.org, yep.
>
> Unfortunately there's not much more than the events atm :(
>
> > > data1 and data2 would be opaque pointers to appropriate data for given
> >
> > Do you mean that all the sounds should be loaded into memory or
> something?
>
> No. The sound() function will select proper sound handle for the action
> and parameters and pass it to actual sound making plugin. The handle
> could be filename.
>
> something like
>
> void sound (pplayer, action, data1, data2) {
>   Sound  snd_handle = get_sound_handle (pplayer, action, data1, data2);
>   sound_play (snd_handle);
> }
>
> The get_sound_handle() selects sound handle based on config file and
> combination of parameters.
>
> The way I want it to work (and the direction in which I am developing)
> is to resemble X resources.
>
> sound_play() is a stub function for plugin's play function. It might mix
> the wave with others, spool it to esd, whatever it needs to do the
> output
>
> > I'm not a specialist but I think we should use some present
> library/mechanism
> > for sounds (I would suggest libesd or libmikmod).
>
> As I have written in other mail, atm I am not interested in actual
> implementation of sound output. I want to do it through plugins,
> however. So there could be plugins for esound and for libmikmod or
> whatever
>
> > > The SOUND would be a macro so it could be disabled during compilation
> >
> > Umm.. Yes, why not. Or simply a function ( sound(params)), which would
> > check if SOUND is defined or not (and select mechanism to use if there
>
> function call overhead (if not optimized out by compiler). But it does
> not matter atm too :)
>
>                               Edheldil
>
>
>