Hi,
> > The approach you're suggesting would actually allow usage of the resource
> > manager (by locking the song/unlocking it when a different song is
> > activated); that's pretty much the only point where pointers would come
> > into play.
> > Songs should be locked before their pointers are sent, and only be
> > unlocked if a 'SOUND_UNLOCK_SONG' (or whatever) message sent from the
> > sound server to the main thread.
>
> OK, I'll also read up on how the resource manager works.
Not in the online docs yet (they probably mention findResource()), see
sci_resource.h under "new resource manager". scir_find_resource() and
scir_unlock_resource() are the functions to use.
> To see if we can get the best performance, I'll compare using the Windows
> timer I mentioned with the QueryPerformanceCounter() function in a separate
> thread. The latter gives a resolution of 3579545 counts per second on my
> machine, which is a lot better than 1000!
That sounds a bit better, yes. But won't there be some sort of price to
pay for this?
> [snip]
> > > else if (&msg.message == UWM_SOUND_COMMAND_SET_VOLUME)
> > > {
> > > master_volume = &msg.wParam * 100 / 15; /* scale to % */
> > > midi_volume(master_volume);
> >
> > I'd vote against distinguishing messages on this level; let's just pass on
> > every message to a snd_process_message() function after converting it to
> > a FreeSCI 'sound command' or 'sound event' or whatever.
>
> That sounds OK, but how will we know if it's a sound command or event
> without comparing it with each possible message? Are you suggesting only two
> basic messages (apart from timers) with the command stored in wParam and
> data in lParam?
There are actually three parameters that have to be transferred, although
we should be able to encode it in the 64 bits we have available if we
wanted to.
Anyway, IIRC the 'message' is a char pointer typecasted to a 32 bit
integer value to achieve some sort of uniquity. By making the text string
it points to sufficiently long, we can map the commands to the addresses
of individual text string characters (note that we must ensure that none
have a negative value), so that we can use simple pointer arithmetics to
encode and decode them.
> Will that be too restrictive and will we be able to carry
> enough data through?
We will be able to do that. Also, since we're sharing the address space,
we could just use sound server instruction queues, at least for handling
commands to the server (not for handing down cues, though, although
global variables could be used for this).
llap,
Christoph
