#4147 closed defect (fixed)
AGI GR: Timings not correct
| Reported by: | SF/muyfa666 | Owned by: | sluicebox |
|---|---|---|---|
| Priority: | normal | Component: | Engine: AGI |
| Version: | Keywords: | ||
| Cc: | Game: | Goldrush |
Description
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.
Ticket imported from: #2581253. Ticket imported from: bugs/4147.
Change History (36)
comment:1 by , 16 years ago
| Summary: | Timings not correct → AGI GR: Timings not correct |
|---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
| Owner: | set to |
|---|
comment:4 by , 15 years ago
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.
comment:5 by , 15 years ago
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.
comment:6 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:7 by , 14 years ago
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.
comment:8 by , 14 years ago
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.
comment:9 by , 14 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
comment:11 by , 14 years ago
Are there any updates on this? The latest build with full SCI-support still have timing problems.
comment:12 by , 14 years ago
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.
comment:13 by , 14 years ago
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.
comment:14 by , 14 years ago
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.
comment:15 by , 14 years ago
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.
comment:17 by , 14 years ago
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>
comment:18 by , 14 years ago
Have no idea what it is, but as of the nightly build at this moment, the problem is not fixed.
comment:19 by , 14 years ago
I just tested the daily build, and it is still not right. Don't want to rush or anything, just letting you know.
comment:20 by , 13 years ago
| Owner: | removed |
|---|
comment:21 by , 12 years ago
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.
comment:22 by , 11 years ago
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.
comment:23 by , 11 years ago
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
comment:24 by , 11 years ago
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.
comment:25 by , 11 years ago
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
comment:26 by , 11 years ago
OK. Those MD5sums match my datafiles as well.
I agree that "fast" and "fastest" speeds are very similar, but I still can't see any difference from the original here.
Can you provide a DOSBox configuration showing the original behaviour to differ from ScummVM? If so, please attach the relevant dosbox.conf to this bug.
If not, I'm not sure we are seeing a real issue here, and the bug will be closed as invalid / fixed.
comment:27 by , 11 years ago
I am using a completely default DOSBox v0.74 dosbox.conf, except for the following changes:
[sdl] output=opengl
[render] aspect=true
[cpu] cycles=max
Those are the only changes I made except for the "mount c".
A bit OT, but maybe releated since it's AGI; KQ3 have a ingame timer that does not speed up like in Gold Rush! no matter what speed you set in the game.
comment:28 by , 11 years ago
I forgot; the behavior I get in DOSBox with the game is that "slow, "normal" and "fast" have basically the same timer speed, eg. more or less real time seconds. "Fastest" speeds up the time 5-10 times. This resembles how I remember it from real DOS.
comment:29 by , 11 years ago
So sorry, got it mixed up since I am switching between v3.0 and v2.01 for this testing. I just recently found the old floppies for v2.01. I'd be happy to provide MD5 for this as well.
To clarify: in v3.0 the clock never speeds up no matter what speed you use. In v2.01, "slow, "normal" and "fast" have the same timer speed, "fastest" speeds up the clock.
This is most likely one of the fixes Software Farm did in 1998. My guess is that the game is not supposed to have the clock speeding up as it kind of ruins the game.
comment:30 by , 9 years ago
| Keywords: | script removed |
|---|---|
| Owner: | set to |
comment:31 by , 9 years ago
I can actually reproduce this issue. Happens with my Macintosh copy of the game. Will look into it. I think it's the only AGI bug report left.
comment:32 by , 9 years ago
I think I just got it finally somewhat fixed. Can you please try the latest daily build (must have a timestamp after this message) Commit 34117170f2955e854a93925a652af37575361b44 At least my copy (2.01seems to work fine now, BUT I had to start a new game!
comment:33 by , 9 years ago
I just tried both v2.01 and v3.0 and you seem to have fixed it. :-)
Slow, normal and fast seem kind of equal, working fine. Fastest speeds up approx. 2 seconds per 1 real second, which seem appropriate. Don't know if it's how it is supposed to be, but seems ok.
comment:34 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:35 by , 9 years ago
Fastest means most of the time a game delay of 0, which means normally no delay at all. So games can run insanely fast. There is still a delay in ScummVM AGI in any case of at least 10 milliseconds, otherwise ScummVM would create loads of CPU usage.
Great that this is solved. Closing.
comment:36 by , 9 months ago
| Owner: | changed from to |
|---|
This came up again in #13910.
Fixed in: https://github.com/scummvm/scummvm/commit/77deb41c252305c6f95d4b929aa48deacf63890b
Gold Rush runs a speed test to determine how fast to run the in-game clock at Fast and Fastest speeds. It runs this test at the unthrottled speed, Fastest. We throttle Fastest, and this caused ScummVM to get an artificially poor test result, and that made the clock run too fast.
It looks like there were other AGI timing issues that were discovered and fixed from this ticket, but the problem here was always the speed test.
Could you, please, provide information on how to check the in-game clock? I.e. I need steps to reproduce.