[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