Menu
▾
▴
#4147 AGI GR: Timings not correct
I tried this with both V2.01 and V3.0 of Gold Rush!
The in-game clock is way off. On Normal and Slow speed, the clock is too slow, and on Fast and Fastest speed, the clock is way too fast.
This is a big problem since there are many timed events in the game.
I confirmed that in DOSBox with V3.0, the different speeds does not have any effect on the in-game timer.
In V2.01, only the Fastest setting speeds up the timer somewhat, but still not as much as in ScummVM.
I am using the latest build.
Could you, please, provide information on how to check the in-game clock? I.e. I need steps to reproduce.
In the game (when playing), press F6 to get elapsed time. AFAIK, the clock are not supposed to be affected by what speed you chose.
I don't know if anyone still is looking on this, but I can confirm that the latest SVN (as of today) still have the bug.
I was running the game for about 4 minutes, and the time matched NAGI pretty much. Perhaps one of the previous updates fixed it. Please test.
Nope. Still the same. I'm not sure what you are looking for, but on "fast" speed, 1 real second is like 10 in-game.
Reopening this
Are there any updates on this? The latest build with full SCI-support still have timing problems.
As far as I know, nobody worked on this issue recently. And the SCI engine has nothing at all to do with the AGI engine, code wise.
Anyway, while I don't know the AGI engine much, I think the cause of the issue could be due to the following: The method AgiEngine::updateTimer() seems to take care of updating the internal game time. This function increments a counter until it reaches TICK_SECONDS (= 20). Then, it increments the internal time.
Only, the method updateTimer is not called a specific times per second or anything like that, but rather at somewhat irregular intervals. As a consequence, the time is increased irregularly. No surprise it runs too fast...
I am not quite sure how to interpret TICK_SECONDS = 20; maybe this means that every 1/20 real second an "in-game" second should happen (so in-game time would be 20 times as fast as real time). The factor could also be 20/60=3, or several other values; somebody who knows the engine better should check. I guess looking at the original Sarien code, or at the NAGI code, would also easily reveal this, but I am currently on a train and can't check.
So a proper fix would replace the "_clockCount" by a millisecond timer indicating when the internal game time was last updated. And of course, it has to consider the effect of pausing the game, etc.; but all of this is routine.
If it offers some kind of help, King's Quest 3 also have a in-game clock that works properly under ScummVM, no speedups or delays.
If it works in KQ3, then that is either due to chance, or because they use a different "clock" there.
Anyway, I just had a look at both the Sarien and the NAGI code. Sarien doesn't seem to have handled the time properly, either (and since our code is based on Sarien, this bug looks like it simply carried over from there).
NAGI seems to do what I described, more or less, but regarding the time one "cycle" should take, its code and the comments in it seem to contradict each other, and I am not sure which is correct (if any). But maybe I am reading it wrong... here is the relevant excerpt from NAGI's time.c:
// it's in 1/20's of seconds
time_counter += (sdl_tick - sdl_tick_prev) ;
while (time_counter >= 20*SDL_TICK_SCALE)
{
time_counter -= 20*SDL_TICK_SCALE;
state.var[V11_SECONDS]++;
So the comment seems to indicate that a cycle is 1/20th of a second. However, note that sdl_tick is given in miliseconds, and SDL_TICK_SCALE=50. Thus, they increment the game clock by one second whenever 20*50=1000 milliseconds = 1 "real" second passed... I am tempted to think that the comment is actually right, however, unless the game time is really meant to pass in "real time".
I also looked at unofficial "Sierra Adventure Game Interpreter specifications", specifically <http://www.agidev.com/articles/agispec/agispecs-3.html#ss3.3>, but that didn't really settle it, either... I guess we could simply try both ways, and then playtest to figure out which one is correct.
Well, in DOSBox, the game time is equal to real time, no matter what speed you run the game in. Just tell me when you need me to test the changes.
Thanks. We'll let you know :).
The following commit may be of relevance (it may even have fixed the issue? I wouldn't be able to tell / test): <https://github.com/scummvm/scummvm/commit/69a026192e30c544379cf938efa6b545a62e3a08>
Have no idea what it is, but as of the nightly build at this moment, the problem is not fixed.
I just tested the daily build, and it is still not right. Don't want to rush or anything, just letting you know.
Not really bumping, but rather reporting that the in-game speeds and clock are now really messed up. Fastest does not even speed up the game properly, only the clock speed changes. I am using the daily build of today. I realise this is no big issue, but it would be nice to see it solved.
I think the game is messed up due to the copy protection routine. Some years ago, I talked to a AGI enthusiast, and he wrote me long text on why the pirated version that's been circulating to death on the internet differs from the legal version in terms of intro sequence. It's a rather lengthy text, but I did save it and just stumbled upon it when I was cleaning up the hard drive today. It goes to explain how the copy protection calls on the a routine that affects the in-game timer. If anyone is still interested in working on this title I'd be happy to share the text. It should provide some insight to the timing problems with this game.
Information about the timing issues can be found here:
http://www.sierrahelp.com/Misc/GoldrushCopyProtection.html
For the moment, I can only try the 3.0 version as I have lost the manual for the old version long ago, making that version basically unplayable due to the copy protection.
Now I know that it is the cracked version that messes up the timing, but there must be some coding mistake in ScummVM, because the 3.0 version have the copy protection removed by the author, hence no ugly crack that messes up the game.
The "new" legit version is still fairly easy to come by:
http://www.softwarefarm.com/gr_home.htm
I can not replicate this problem with the latest version of ScummVM on Linux x86_64 i.e.
ScummVM 1.7.0git5180-g8964097-dirty (Jan 24 2014 18:05:53)
Features compiled in: Vorbis FLAC MP3 ALSA SEQ TiMidity RGB zLib MPEG2 Theora AAC FreeType2 JPEG PNG
The game clock seems to be fine at normal, matching real elapsed time and speeds up when you change the speed setting in the AGI menu as does the game speed i.e. character walking, NPC events.
I am using the new Software Farm version:
Gold Rush! (3.0 1998-12-22 3.5"/DOS/English)
Emulating Sierra AGI v3.002.149
muyfa666: Please detail your current ScummVM version, Operating System and version of Gold Rush. It would also be useful if you attached MD5sums of your GR datafiles as a text file to this bug to check against my version.
I see what you mean, but while "fastest" are supposed to speed up the clock significantly, "fast" is not. I played this on my old 386 in MS-DOS many times years ago and I am 99,9% certain that timings of "fast" was very close to "normal". This also goes for most Sierra AGI games. "Fast" was always very much like "normal".
I am using Win 8 Pro and ScummVM 1.7.0git5179-gce383ac (Jan 24 2014 13:36:27)
I am using game version Gold Rush! (3.0 1998-12-22 3.5"/DOS/English)
MD5:
ce6d51ac9a48a7eb0a2aa94827b9e850 AGI
940144fea8dce843eb56e61f1793ca9f AGIDATA.OVL
dbf46c59c825dd160c523497efb90dd9 CGA_GRAF.OVL
931a099c9c2325ffbc1c4b89349884bb EGA_GRAF.OVL
041ea3e2ec7f369b8c6415d166214d9f GR.COM
8e796a2bc0d01615fefc6409fc5dcb5b GR.ICO
6882b6090473209da4cd78bb59f78dbe GRDIR
0f76db16c1440554d55a8f02df5075b6 GRVOL.0
9aee80918a52e135cc7556eddf6c0d7a GRVOL.1
7024e75c7290c03d49b6cbca9bd9da47 GRVOL.2
c12f3c4cc0a11230c126d0de4c35c293 HGC_GRAF.OVL
38bd521db6e73a0960b5bc77bb19f2d8 JR_GRAF.OVL
9fa64d3f27c489933c6d9700e94f1791 OBJECT
0bb47020c3601686526c000aef21b2e5 README.TXT
e99aba825bf3545a113c3fde619f98f6 VG_GRAF.OVL
ce085fc2ef513d084c4396d29ab5086b WORDS.TOK