[Scummvm-tracker] [ScummVM :: Bugs] #13910: AGI: Goldrush timing not correct again (regession?)

[ScummVM :: Bugs]

#13910: AGI: Goldrush timing not correct again (regession?)
---------------------+--------------------------
Reporter:  Muyfa666  |       Owner:  sluicebox
    Type:  defect    |      Status:  closed
Priority:  normal    |   Component:  Engine: AGI
 Version:            |  Resolution:  fixed
Keywords:            |        Game:  Goldrush
---------------------+--------------------------
Changes (by sluicebox):

 * keywords:  goldrush =>
 * owner:  (none) => sluicebox
 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in:
 https://github.com/scummvm/scummvm/commit/77deb41c252305c6f95d4b929aa48deacf63890b

 The Time Has Come! I'm learning AGI this year, so let's get to the bottom
 of Gold Rush time.

 Muyfa666, thank you for your patience and persistence. 15 years ago you
 opened #4147 and kept checking back in with what worked and what didn't.
 It set off a lot of discussion and led to some good AGI timing fixes, but
 the real problem went undiscovered until now. If you hadn't opened this
 ticket, who knows how long it would have taken.

 I'm going to write this up in detail because there's a lot to untangle.

 Gold Rush Time (GRT) is driven by game cycles, and game cycles are driven
 by the speed setting. GRT only advances when you're playing the game, as
 opposed to in a menu or in a message box. There is also a flag that
 scripts can set to pause GRT during a scene.

 GRT *appears* to be real time, like the system clock, or the KQ3 clock,
 but it's not. The game runs a speed test at the start to see how fast your
 CPU is. The results determine how many game cycles it takes to advance GRT
 by one second at Fast and Fastest speeds. From the calculations in the
 scripts, and the results in DOS, I can see that the goal was for the in-
 game clock speed to approximate real time. That implementation was so
 successful, that Muyfa666 believed it really was real time.

 The ScummVM incompatibility has always been that we throttle Fastest
 speed, but the speed test runs in Fastest and expects to run as fast as
 possible to measure the CPU. We've always gotten a poor result on this
 speed test, and the game has compensated by speeding up GRT at Fast and
 Fastest speeds. This also means that different users might get different
 results, and that any change in ScummVM timing has affected this, possibly
 coincidentally making it better, but this problem has never been really
 solved because according to the discussion on #4147, no one knew about the
 speed test.

 The speed test result gets stored in saved games, so that's added to the
 confusion. If a developer made a change to ScummVM and tested with a save
 game, they'd get different results than when starting a new game. Users
 would have the same problem when testing or upgrading.

 Further confusion: Gold Rush 3.0, released in 1998, adds a tweak to the
 speed test. If it thinks you're really fast, then it silently disables the
 Fastest speed option. Selecting Fastest will really just get you Fast.
 That makes sense, because by 1998, Fastest (unthrottled) was unplayable on
 modern computers.

 Further Further confusion: The cracked version of Gold Rush 2.01 skips the
 speed test, leaving the results uninitialized, and that prevents time from
 advancing at Fast and Fastest speed. I saw a long FAQ document that starts
 out by claiming this is a bug in the game, so everyone is confused.

 The fix is to do what we do in SCI, which has lots of these speed tests:
 override the results for consistent game play. My fix does this when
 starting the room 1, so it will affect new games and restarts.

 You can fix an existing save game using `bird man` + `set var` debug
 commands, or ScummVM's `vmvars` debug command. Set variable 165 to 20 and
 variable 167 to 40.

 Confirmed that this fixes: PC 2.01, PC 3.0, Amiga, Atari ST, Mac

 This does *not* fix the Apple IIgs version, the clock on it is also wrong
 but for different reasons. It will require a separate fix. That version
 only had one speed, so Sierra removed the script that synchronized the
 clock-speed variable to game speed. We add the ability to change the speed
 in that version, so we will also need to implement synchronizing that
 variable. It's on my list! =)
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/13910#comment:5>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM