[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/scumm script_v6.cpp,1.39,1.40
Max Horn
max at quendi.de
Tue Jan 14 05:26:03 CET 2003
At 2:33 Uhr -0800 14.01.2003, James Brown wrote:
>Update of /cvsroot/scummvm/scummvm/scumm
>In directory sc8-pr-cvs1:/tmp/cvs-serv23804/scumm
>
>Modified Files:
> script_v6.cpp
>Log Message:
>ComI timing hack... very odd.
>
>
>
>Index: script_v6.cpp
>===================================================================
>RCS file: /cvsroot/scummvm/scummvm/scumm/script_v6.cpp,v
>retrieving revision 1.39
>retrieving revision 1.40
>diff -u -d -r1.39 -r1.40
>--- script_v6.cpp 12 Jan 2003 21:13:21 -0000 1.39
>+++ script_v6.cpp 14 Jan 2003 10:33:18 -0000 1.40
>@@ -2236,8 +2236,15 @@
>
> void Scumm_v6::o6_delaySeconds()
> {
>- // FIXME - are we really measuring minutes here?
>- uint32 delay = (uint16)pop() * 60;
>+ uint32 delay = (uint32)pop();
>+ if (_gameId != GID_CMI)
>+ // FIXME - are we really measuring minutes here?
>+ delay = delay * 60;
>+ else
>+ // FIXME - Is this the same in ComI? Seem to need a 1.5 minute
>+ // multiplier for correct timing - see patch 664893
>+ delay = delay * 90;
>+
> vm.slot[_currentScript].delay = delay;
> vm.slot[_currentScript].status = 1;
> o6_breakHere();
>
Sorry, I didn't even see the original patch item. Just to explain a
bit about our timing system:
mainRun() is the main loop for ScummVM. It contains this call:
waitForTimer(delta * 15 + last_time - new_time);
Neglecting the value (last_time - new_time) (it should ideally be 0.
and are there to adjust for the time taken by the "waitForTimer"
function itself, which is our event handler), this means that we are
delaying delta*15 milliseconds. 15 milliseconds correspond roughly to
1/66 second. This is our fundamental timing unit, a "time slice" if
you like.
This explains why in o6_delaySeconds() we delay for 60 frames normal
(although strictly spoken, 66 would be more correct, or alternatively
the 15 should be changed to 16).
Just in case you don'T believe me (e.g. you could say: "Why does this
guy claim 15 ms is the base unit, why not delta*15?"). In scummLoop,
we have this call:
decreaseScriptDelay(delta);
So, we wait for delta*15 ms, then we decrease the script delay by
delta. This is the same as my statement, namely that 15ms is the
fundamental time slice; delta just determines the "granularity" with
which the loop is run; in the case of COMI, that's slices of
5*15=75ms, or 1/13th of a second.
Now, why does the timing in COMI differ so much? I am not quite sure.
It would be interesting to perform some timing tests on different
systems, maybe there is a logical flaw in my explanations above, and
the value should be 90 in other games, too.
Maybe timing issues also come from the difference in o6_delay: in our
current implementation, it directly uses its parameter for the
"slice" count. Remember, one of our slices is 1/66 second. But in the
CMI opcode list
(http://scummrev.mixnmojo.com/specs/CMIOpcodes.shtml), it says:
106 06A O_SLEEP_JIFFIES Sleep for jiffies (10ths of a second)
That's clearly a contradiction - one (or both) have to be wrong.
And as I see it, the script that calls delaySeconds(8) also calls
delay(40). If delay(40) really has 1/10 of a sec as a base, that
would exactly yield us the right 12 seconds (or slightly less, since
we use 15ms, not 16ms, as base slice size).
As a conclusion, it might be good if we check the COMI assembly to
see what are the right values for COMI, in particular:
* What is the time slice size for COMI (length of one jiffie)
* Is my guess for VAR_TIMER_NEXT right at all (i.e. its location in COMI)?
Cheers,
Max
--
-----------------------------------------------
Max Horn
Software Developer
More information about the Scummvm-devel
mailing list