ScummVM 0.11.0svn (Jul 1 2007 08:51:56)
Features compiled in: Vorbis FLAC MP3 zLib MPEG2
The Intro has two parts were video and audio is
skipped partly (just a few seconds).
The scene were Jerrod's portrait is centered and the
four main parts of the game ought to "raise" from
behind to slowly scroll out and fill the screen
"jump" out skipping part of the background music.
This also happens some seconds later when the GoldRush
logo shows up and again seconds later when Jarrod
enters the first frame to make fire.
English
Amiga Floppy
AmigaOS4
gcc version 4.0.2 (AmigaOS build 20051012)
Logged In: YES
user_id=1803212
Originator: NO
Either ScummVM is playing the music too slowly and/or
showing the animations too fast as it never gets to
quite finish the song before entering the first screen
of the game (i.e. the bridge in Brooklyn Heights).
I tried running the Amiga version of Gold Rush under
WinUAE and yep, there's some animation that is shown
there but skipped practically totally in ScummVM.
Same goes for the PC version under DOSBox 0.70.
Amiga version had a different kind of an effect for
changing pictures though, it changed them by
changing small random parts of the picture at a time
until the picture had changed entirely from picture
A to picture B.
I'll probably take a look at the PC version's logic files
to see how the animation thing is done and see if I
can figure out what's making it to be skipped in ScummVM.
Logged In: YES
user_id=1803212
Originator: NO
Using the PC-version's data files here:
The intro's logic files are executed in this order:
73 (The SIERRA-logo etc),
191 (The portrait of Jarrod & the text)
196 (The appearance of the four part screen),
199 (Until the Gold Rush logo),
200 (After the Gold Rush logo has appeared).
The animation in the intro where the four
part image with the protagonist's head in the
middle appears is done by showing pictures 196-199
and it's done in the logic resource 196.
Looking at logic file 196 the animation is
done by (room_no = 196 here):
<code>
v220 = 197;
v221 = 198;
v222 = 199;
draw.pic(room_no);
show.pic();
draw.pic(v220);
show.pic();
draw.pic(v221);
show.pic();
draw.pic(v222);
</code>
I've taken out some add.to.pic-commands,
load.pic-commands etc from around the pasted
commands here but that's the basic animation
part right there. There's no waiting anywhere
to be seen... don't know if show.pic or
draw.pic should incur some waiting by
themselves...
Logged In: YES
user_id=1803212
Originator: NO
I'm not currently working on this so
I put this back to the pool.
P.S. I'm not that sure how to approach this bug
either, possibly by disassembling the pertinent
parts of the Amiga version but that might be
quite a bit of work.
Well, as i said some time back on IRC it is most surely done using
the delay the floppy disc access brings while loading the next
frames/pictures (on the classic amiga).
Both cases i mentioned have a floppy disc access right before
loading the pictures (zoom effect)
So, maybe adding a delay to the script between (if possible)
should do the trick?
Thanks for taking a look
Yes, delays on picture loading, as well as proper set of screen updates fixed the bug for me.
In many places AGI game designers cleverly relied on the fact that both machines and floppies were slow at the time.