Opened 4 years ago
Last modified 3 years ago
#11773 new defect
CINE: OS (Atari ST) - Incorrect intro speed
Reported by: | laenion | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | Engine: Cine |
Version: | Keywords: | ||
Cc: | Game: | Operation Stealth |
Description
When testing the game I had the impression that the game's introduction sequence took way too long. And indeed: When playing the game on the Atari ST I discovered several inconsistencies.
Examples:
Code card introduction text (from cursor appearing to OK button):
Atari ST: ~ 14 seconds
ScummVM: ~ 29 seconds
Delphine logo (from first shapes appearing to logo faded out):
Atari ST: ~ 13 seconds
ScummVM: ~ 22 seconds
All in all ScummVM requires 2:34 minutes until the briefing, the real hardware requires 2:00 minutes - and that is even though on real hardware the loading times are way longer than on a modern PC, for example 10 seconds for the transition between the hangar / airfield scene in the original vs. 0 seconds in ScummVM.
The problem is that sometimes the speed is mostly correct, sometimes it takes twice as long as the original, and everything in between. I have uploaded a ScummVM recording of the introduction to http://digitalimagecorp.de/files/ScummVM_OperationStealthIntroSpeed.ogv, the correct speed can be seen in https://www.youtube.com/watch?v=tDmLJ2V697s (the video is matching the speed of my Atari ST except for loading times).
The ingame speed seems to be correct.
Change History (2)
comment:2 by , 3 years ago
Thank you for looking. Another reason could be an endianness issue since Atari is BE. We will test it on Amiga and see if we can replicate it there and if we do, then there is a better chance for deeper analysis where Raziel could help.
Just to let anyone know who might be looking into this ticket:
I tried a similar approach as for fixing #4213 by removing doubled BREAK opcodes during the copy protection scene and introduction but it didn't fix the speed (See FWScript::o1_break()).
I have no idea what else could be making the speed difference unless it has something to do with perhaps different vertical retrace speed (50Hz vs. 70Hz or something like that). That alone wouldn't make a 2:1 difference though but perhaps combining the removal of duplicated BREAK opcodes with fixing vertical retrace speed could make a difference? Or it's still something else.