#15732 closed defect (fixed)
SCI: ECOQUEST1: Possible timing glitch when Flesh-Eater is first introduced
| Reported by: | eriktorbjorn | Owned by: | sluicebox |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | Keywords: | original | |
| Cc: | Game: | EcoQuest 1 |
Description (last modified by )
I don't know if this is a timing glitch or not, but it sure looks goofy to me. I'm playing the English CD version of the game, with the current development version of ScummVM.
In the scene where Flesh-Eater is first introduced, Delphineus knocks Adam to get him out of the way. At this point, Adam starts spinning madly, abruptly stops, and gently floats down. Can that really be how the programmer intended the scene to look?
Other parts may be off too (e.g. the shadow covering Adam's face, or Flesh-Eater "slowly" gliding away), but those are a lot more debatable.
I have not tried this in DOSBox, as it's a fair bit into the game. I tried looking up the oldest YouTube playthroughs I could find, but it looks the same there. Of course, even those would be one or two decades more recent than the game itself.
Attachments (4)
Change History (9)
by , 18 months ago
| Attachment: | ecoquest-cd.005.gz added |
|---|
by , 18 months ago
| Attachment: | Flesh-Eater.mp4 added |
|---|
comment:1 by , 18 months ago
| Description: | modified (diff) |
|---|
comment:2 by , 18 months ago
comment:3 by , 18 months ago
There's a similar animation near the end of the game. (I think I saw one elsewhere too, but I didn't pay much attention to it.) I assume the intended speed for both are about the same.
by , 18 months ago
| Attachment: | ecoquest-cd.013.gz added |
|---|
by , 18 months ago
| Attachment: | Endgame.mp4 added |
|---|
comment:5 by , 11 months ago
| Keywords: | original added |
|---|---|
| Owner: | set to |
| Resolution: | → fixed |
| Status: | new → closed |
Fixed in: 576f2cd03325a4bcab429d4ae66bdc288c9830b5
There were two problems:
- The animation speed of Adam's close-up was based on CPU speed, so it ran too fast. I've patched it to be slower and clock-based.
- When Adam gets knocked into the urn, the script set his animation speed to fastest (based on CPU speed) but didn't set his movement speed, so everybody also got different results based on the game speed setting in the control panel. The intent is for Adam to be quickly knocked into the urn, so now the movement speed is set to fast during this part for consistency. (It looked very silly if the speed slider was set to slow)
FWIW I played this in the 90s on my friend's lower-end 486, then later a faster one, and there's no perfect result since everyone got something different, but I think this scene is better now, and as good as it's going to get =)

Here's someting I tried just to see if it would make a difference. It did:
diff --git a/engines/sci/engine/kmisc.cpp b/engines/sci/engine/kmisc.cpp index 5f3d20ce429..bfe9c2def28 100644 --- a/engines/sci/engine/kmisc.cpp +++ b/engines/sci/engine/kmisc.cpp @@ -173,6 +173,13 @@ reg_t kGameIsRestarting(EngineState *s, int argc, reg_t *argv) { } break; + case GID_ECOQUEST: + if (s->currentRoomNumber() == 120) { + s->_throttleTrigger = true; + neededSleep = 90; + } + break; + // Don't throttle SCI1.1 speed test rooms. Prevents delays at startup. // We generically patch these scripts to calculate a passing result, // but each script performs a different test, so to speed them all upBut I don't know if it's correct or not. Most obviously, it presumably adds extra throttling to that room all the time, not just for the cutscene. (And it needs commenting, but I left that out for brevity.)