Hi,
> > > One of the main things that's bothering me with FreeSCI at the moment (aside
> > > from the save game stuff) is timing.
> > >
> > > 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.
>
> > There are no timers.
>
> There definitely are :)
OK, you're right, of course. FreeSCI may not provide "timer"
functionality (which is what I meant), but it requires the OS or libraries
to do some timing of their own.
> The last "optimization" I made that really helped things was to increase
> the resolution of the time calls. It appears that FreeSCI gets the current
> time, compares against the last gotten time, to see if 20ms (or howlever
> long)
I was wrong again the last time, it's 16.66... ms (one tick happens 60
times per seconds in regular intervals).
> has gone by. Whenever the initial few compares are off (because of
> lack of timer precision, or whatever), this seems to cause all kinds of
> events to go slowly, not just sound.
The gettime functionality uses a different mechanism; I used to believe
that the slowdown was caused by the FreeSCI spending vast amounts of time
in waiting for SDL events (back in the 100% CPU usage days), i.e. a
performance issue.
> Alex: one thing we could do is to try and use a real win32 event loop
> where the OS will call a function every X number of milliseconds. This
> might help eliminate these kinds of problems. I think Sarien does
> something like this in their win32 gfx driver, if you'd like a
> reference.
This sounds like a promising approach- it's essentially what Sierra did,
and if Win32 provides better timer resolution this way, it should do just
what we need.
llap,
Christoph
