Hi,
> One of the main things that's bothering me with FreeSCI at the moment (aside
> from the save game stuff) is timing.
>
> Using LSL3 as my example, sound timing is an obvious problem. The Win32
> optimisations have helped a fair bit to get the timers working correctly
> from the start so sound is OK but a little flaky. After coming back to it
> after leaving the main titles running for an hour however, sound timing has
> deteriorated hugely.
>
> Also, screen wipes are usually normal speed, but sometimes very slow. Once
> the timers have gone crook, it can take ages for the LSL3 titles to move
> past the 'Sierra Presents' screen.
>
> How are these timers implemented and is there any way they can be improved?
There are no timers.
Sound is played in an asynchronous process (or thread with the SDL sound
server). IIRC Matt pinpointed the sound server performance problems to the
means of communication between the threads used in the SDL sound server;
this is where most of his optimizations come in.
The basic idea is that the sound server main loop identifies the number of
'ticks' (20 ms intervals) it has to wait, and calls a functon of the
specific sound server implementation to wait until one of two things
happens:
a) The time interval has passed
b) An event has been received from the main process (start song, stop
song, set volume etc.)
On the UNIX sound server, this is implemented with select() on pipes or
local sockets, which seems to work fairly well. The SDL sound server uses
its own signal-based mechanism, though, and this appears to be where the
problems come in.
I'm not sure whether it's a bug in our code, a problem with SDL, or a
weakness in the underlying kernel.
llap,
Christoph
