AGI: Goldrush timing not correct again (regession?)

[Muyfa666]

I reported this on the old bug tracker, and the issue was fixed, and all was well.

Now I tried to play the game today with the latest daily build of ScummVM, and the timer is very erratic, so the game is hard to play.

Lots of info on the issue here: #4147

The version of the game used is V3.0, from Steam.

[sluicebox]

Thanks for reporting this. There's a lot in that old ticket, and most of the developers who were involved in it are no longer active, so we'll probably need some help from you to narrow this down. In my opinion, there hasn't been significant development on the AGI engine in some time, so you may have to be patient.

The big piece of information we need are steps to reproduce this. Even if you're just repeating some of the previous ticket, that will help whoever looks at this. It can be hard to untangle what happened in an old ticket if you weren't involved.

You may also be able to help narrow this down if you can test with older releases. If you're using Windows, you can often find old ones by changing the digits in the download urls, like ​https://downloads.scummvm.org/frs/scummvm/2.6.0/scummvm-2.6.0-win32.zip . I don't know if there's a better way or if that applies to other platforms. If you can spot where things went wrong, that will be a huge help.

I don't know AGI and I haven't played Goldrush yet, but I hope to play it someday, so I'm rooting for this to be fixed. But there hasn't been a lot of AGI activity in recent history, so this ticket will probably need all the help it can get =)

[Muyfa666]

On DOSBox (and real old hardware), the internal timer in Goldrush is consistant no matter what in-game speed you choose to play at - 1 second in real life equals 1 second in-game. This is important, since many event in this game happens at specific times.

When I play the game in ScummVM, the in-game speed "Normal" and "Slow" seem to be 1/1 in seconds (more or less) while "Fast" translates 1 real life second to 2 seconds in-game and "Fastest" translates 1 real life second to about 4 seconds in-game.

I also checked out King's Quest 3, as it also relies on timed events, and in this game, the timer is consistant, no matter what speed you choose.

In conclusion, the timer in Guldrush is supposed to be consistant with real life time, no matter what speed you choose.

[Muyfa666]

V1.8.0 have the same bahavior as the latest version.

V1.7.0 are super strange. Some speeds work ok, "Fast" jumps like 10 seconds for every second.

Also, the Amiga versions was first reported to work fine, but that's not the case. It has the same timing issues.

[sluicebox]

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! =)

[m-kiewitz]

This would be another reason to finally implement my script patcher for AGI.

[m-kiewitz]

I'm also wondering what got changed that broke this, because some years ago it worked.

[sluicebox]

Yes! You probably saw this too, but it seems like an AGI script patcher could reasonably support injecting bytecode, unlike SCI where there are too many offsets in the script resource. In AGI it's just the initial offset to the message section, and then it would be straightforward to parse the bytecode and automatically adjust the offsets in goto and test opcodes. (Maybe you've already made that!)

Also I'm having a lot of fun learning AGI this year, thanks for the clean codebase! =)

[m-kiewitz]

AGI was rewritten some time ago, was a nightmare, but it fixed so many things, and now it's quite accurate.
And I loved adding support for Hercules, Apple IIgs etc. rendering.
I think I did that all within a few weeks only lol

I wanted to look into pre-AGI in detail, but also into the rare booter AGI releases, that required the user to boot directly from the game floppy. Especially pre-AGI has quite a few things in common, but there are clear differences like with flood fill. Good luck finding the difference(s) though. Maybe that would be perfect for you. I think there is an open bug, I warned in there to just change the code, because that would definitely break regular AGI. Eugene suggested to split up the code base, but I'm not entirely sure.

Back then I already wanted to implement the script patcher in here. Maybe it's overkill, but I don't like If (game=xxx) code either.
Also wanted to improve the SCI script patcher, so it would be possible to add additional code, so we wouldn't have to optimize byte code to squeeze our stuff in.