Menu
▾
▴
#4162 GOB: Minor sound glitches in Gobliins 2 (CD/DOS English)
closed-fixed
2
2014-08-15
2009-02-15
No
Hello,
I just ran through Gobliins 2 CD version and completed without any major issues, but I did encounter a few minor glitches. It's possible that these occured in the original interpreter as well, but they do stand out a bit.
1) The video during the introduction lags behind the sound towards the end; this happens consistently. I think a similar thing used to happen in Woodruff.
2) There are two places (that I noticed) where the speech in the CD version hangs up. It's entirely possible this isn't even a bug, but I figured I'd mention it anyway. The first place is the time where you have Winkle enter the big lizard statue to scare the guard in the "Well" screen, Winkle's speech will cut off partway in. The second is when you use the crown on the knight in the "Armor" screen, the knight's speech will cut off partway. Neither of these are in any way game crippling or cost you any hints. Just polish really.
Sorry, forgot the version info:
ScummVM Windows, 0.13.0 pre (Feb 9th 2009 22:46:28)
Gobliins 2 (v1.000 CD/DOS English)
1) There's sadly nothing I can do about that. Woodruff uses a VMD in the intro, which can be properly synced. Gob2 however starts the CD track and does the graphic with normal game sprites, without any sync whatsoever. The waiting between "frames" is simply done within the normal game opcodes and there's no way to distinguish between "normal" uses and uses in the intro.
For waiting between frames, the original used "busy-waiting", i.e. doing useless stuff on the CPU until the waiting time's finished. That way, you can stop waiting at exactly the desired time, but this also uses 100% CPU time. Which is bad and you don't want that on modern computers where there's more than one program running. Instead, ScummVM does a sleep, i.e. tells the operating system to wait for a specific time before the program is continued. The operating system then can let a different task run at the mean-time. Unfortunately, this is not completely precise, but instead has a certain granularity. Waiting may be a few miliseconds too long or too short and since there's no way to resync the graphics with the CD audio in the intro, these differences add up and result in the drifting out of sync you noticed.
2) Hmm, I'm not sure about that one. Could you attach a save where this can be noticed?
Attached a save game. Send Fingus through the hole, then Winkle into the door on the lizard statue. For me, the speech seems to skip a bit and then hang up before I remember the actual line ending.
It's possible that my cd audio tracks are a bit corrupted due to my game disc being scratched up and old, and having transferred the files between HDDs, but it only happens at a couple of places so I'm not sure.
File Added: gob2cd-us.s01
Save before the first line mentioned, at the big lizard statue.
DrMcCoy, I know little about the gob engine, so the following might be nonsense, but: In SCUMM (and other places), we make up for the impreciseness of the delay functions by recording the time (using OSystem::getMillis) at certain times. Then if you notice you are lagging (or too fast), the duration of the next delay is adjusted based on that. Wouldn't something like that be possible for gob, too? It still wouldn't be perfect (esp. if the to be synced sequences are very like), but at least for SCUMM it works well enough.
Hmm, you're right, I don't need to base the re-syncing on the actual start of the sequence if I only want to compensate for small time differences. Me stoopid *g*
1) This one should be better now in the SVN trunk (I myself compiled never got that problem that strongly. I guess it's because I compiled my Linux kernel with a high-resolution timer *g*). I think the Windows daily builds are from that trunk again, so could you please test it with the next daily build?
2) I don't get any skippings are cut-off endings there. Could be your scratches CD then, sorry.
Retested Gobliins 2 (and Gobliiins) on the Feb 22nd SVN and it seems to sync up a lot better now. There's still a couple spot where it seems to fade out of sync a little bit, it quickly recovers.
Should we close this bugreport then?
Yeah. The sync is, I think, as good as I can get it.