SCI: Way too fast color cycling in LONGBOW

[GermanTribun]

Game: Conquests of the Longbow
Version: VGA
System: Windows 10 x64
ScummVM:Newest 2.7.0git

There is a serious issue with the colory cycling in Conquests of the Longbow: it is WAY too fast.

Take a look at this DosBox video and note the speed of the color cycling in the river at the hideout and especially on the navigation map.
​https://www.youtube.com/watch?v=149Ia1cKHSU&list=PL1Be_cMfHOEdLHLRVztZMwlOmT4oSNEFc

If you compare this to the absurdly fast color cycling in ScummVM, it's clear something is not set correctly under ScummVM. Thus it somehow must be possible to adjust the color cycling to its correct speed.

[sluicebox]

Thanks for reporting this. Speed throttling is broken in Longbow map rooms.

This began in release 2.6.1 with: ​https://github.com/scummvm/scummvm/commit/e09010f7d8b7cc30ae3c8477d1a8b61b24d96306

I restricted "fast cast" throttling to the intended targets, and that has exposed that the real speed throttler never worked in these map rooms because they have no cast members. I'll see what we can do about that.

[GermanTribun]

That explains the map. Though the cycling on the river at the hideout is also too fast (even if not as extreme as on the map). Curiously, meanwhile the cycling on the Sierra loga seems as bit too slow compared to DosBox.

I leaves me to wonder if that code in general was not well-programmed by Sierra (and makes me appreciate how through LucasArts was).

[GermanTribun]

I installed the game under DosBox to check directly. Note the cycles settings of DosBox had little effect on the outcome.

-The Sierra logo cycles a bit faster in DosBox than under ScummVM.
-The cycling of the water at the hideout and the Widow's cottage is, by my estimate, almost double as fast in ScummVM than it's supposed to.
-The speed of the cycling on the map is, as mentioned by sluicebox, completely broken in ScummVM and out of control.
-I was unable to check the cycling at the fens, but I bet there is a similar issue. I forgot which other places have color cycling in the game.

[sluicebox]

Map rooms fixed in: ​https://github.com/scummvm/scummvm/commit/e46767b8f8acd7ddcb6a11e4d794d7889c243ca6

Speed throttling is no longer broken on the maps, and I've patched out Sierra's incompatible map throttling script. Without that second part they would go way too slow. It's now the speed I get with DOSBox at 3,000 clock cycles per second.

Yes, timing is "tricky" in SCI, and I don't think it's such a battle for the SCUMM folks. Thanks again for reporting, this has revealed that the 12 year old heuristic code that detects Sierra's speed tests does indeed make mistakes that cause problems. It's mostly obsolete due to improvements from this year, but it wasn't clear if it could be safely removed. Now we can work on figuring that out.

Only the map rooms were broken, the other game rooms that palette cycle are scripted to change once per game cycle with no throttling, and that's what they're doing. There is no original speed for these unthrottled games, they do as many game cycles as the hardware will allow. And Sierra's invisible speed test tweaks individual behaviors based on the result. That particular youtube video is running DOSBox (DOS?) painfully slow, hence the slower animation and long load times when switching rooms. It's hard to reason about this stuff without looking at the scripts because different scenes are programmed differently. (I'm being polite: inconsistently.) They could have used clock time for consistent palette animation speed like in QFG1VGA, but instead they used game cycles for everything. Oops.

Some fun numbers: ScummVM limits SCI games to ~33 game cycles per second. My ~1995 DOS machine gets 176 at the hideout, and so the palette animation screams. The map animates just as fast as ScummVM does now. Unthrottled, ScummVM would do 2,7000 at the hideout on my mediocre laptop. (I modded the game to show speed) Adjusting DOSBox speed affects game cycles accordingly, along with animations tied to game cycles.