#8154 closed patch
CMI: Delay tweaking (experimental)
| Reported by: | eriktorbjorn | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
CMI uses o6_delaySeconds() with a delay factor of 8 to make the first chapter screen show until the music has ended. When running it under WINE this translated into a delay of 11-12 seconds. With ScummVM, it's much shorter.
I don't know how this patch affects other games that use this opcode.
Ticket imported from: #664893. Ticket imported from: patches/259.
Attachments (1)
Change History (6)
by , 22 years ago
| Attachment: | comi-delay.diff added |
|---|
comment:1 by , 22 years ago
This patch DOES seem to make the timing pretty much perfect... but I too wonder about the effect on other games.
Anybody else have any comments on this one? Maybe some timing checks with other games using this opcode, or CMI on a real windows system?
comment:2 by , 22 years ago
As nobody else seems to have any opinions, I've commited a ComI-specific version of this patch, with a comment regarding its.. er.. oddness :)
comment:3 by , 22 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:4 by , 22 years ago
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)?
comment:5 by , 6 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Monkey Island 3 |
Patch against a January 8 CVS snapshot