adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Audio update


From: Kai Sterker
Subject: Re: [Adonthell-devel] Audio update
Date: Wed, 21 Sep 2005 14:22:54 +0900

On 9/12/05, Tyler Nielsen <address@hidden> wrote:

Sorry for the long silence, but my business trip to the US left me
much less spare time than I expected. Instead of having the evening
free, I nearly had to spend all time on actual work. At least
everything succeeded in the end ... :-).

Actually right now its not that much better ... I'm on vacation for
the next three weeks (I really needed those ;-)), visiting my GFs
parents in Korea. So I have a lot of sights to see, people to meet,
... etc.. I should be able to check my mails more ofthen though and
there'll be free minutes to answer. So if you would like to ask or
discuss anything, now would be a good time.

Anyway, so much for my current status. On to the audio stuff:

> Well it's me again.  Just letting everyone know that I have simple audio
> working.  I just did the following session:

[snip]

Cool. I hope I can try it once I am at home ...

> Right now I'm starting to look at how to integrate this better with the rest
> of the code.  For example, I know we don't want to be passing full path
> names to load sounds.  

I imagine that we have some directory for sounds and music where the
rest of the gamedata is located. When given a file name, the engine
would then look in this directory and try to load the file from there.
That would be consistent with the rest of the data files. Have a look
at base.paths for some code that handles files in the game directory.


> One, I want to make sure that the end audio API is consistent with the
> "vision" (TM).  I've looked through the wiki and some of the other
> documentation and I haven't found anything specific.  So what I'm heading
> towards is an API that let's you control playing/manipulating sounds. 
> Basically the low-level stuff you would need to implement some of the other
> ideas that are around.  Right now I'm envisioning something similar to
> above, with a few added pieces.  (event at the end of a sound, positional
> location, and a caching mechanism come to mind)  Am I already way off track?

No, that sounds good. Especially the event based playing is something
we really should have. This was how things worked in v0.3. However,
audio events where somewhat different from the rest. For one, because
audio ran as a seperate thread, so we couldn't directly trigger event
scripts from that thread. We had to signal the main thread an trigger
the event from there, otherwise an already running python script would
get screwed. We didn't go so far as allowing multiple python threads.
 

> Two, I started adding an way to hook to an event on the end of the sound.  I
> found to base event classes.  one in event/event.h and one in input/event.h.
>  I wasn't sure if I was supposed to use the one in event, or do the same
> thing input does and create my own event base class.
 
The event base class (and manager_base) class in the event package
would be the right thing, I think. The others are for user input
events. There is also the eventtest script in the test/ folder that
explains a little how the stuff might be used.

Hope that answers your questions, otherwise please ask!

Kai




reply via email to

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