AGS: Heroine's Quest intro shows portrait bug

[i30817]

Midway through the intro, Thrivaldi shakes his fist in the foreground. A second after, his portrait appears as if he was talking (without text) and travels over the screen, apparently on top of the thrivaldi sprite.

The upstream doesn't do this, but this sounds like a compatibility bug that was hardcoded to be 'fixed' for certain game or 'engine version before some version number' as is the normal procedure for upstream AGS so maybe there are some clues on the commit messages.

[Crystal-Shard]

Analysis:

Normally, AGS characters have walking animation in four directions. If the character moves diagonally (e.g. southwest), the interpreter picks either the south animation or the west animation. Expectation: if horizontal distance to destination is greater than vertical distance, play the west animation; otherwise, play the south animation. I confirm that this works normally when playing the game through AGS.

Relevant code is MoveCharacterBlocking (THRIVALDI, character[THRIVALDI].x - 185, character[THRIVALDI].y + 100, 1);
In this case, AGS picks the west animation (loop 1) and SCUMMVM picks the south animation (loop 0). It so happens that loop 0 contains portraits, since this is a special animation view and not Thrivaldi's normal walking view.

This will very likely affect other AGS games as well.

[criezy]

I have just verified that current upstream AGS actually has the same issue, but that indeed AGS 3.5 works properly. So this is not a bug specific to ScummVM but a regression in upstream AGS. I will open a bug with them.

[criezy]

​https://github.com/adventuregamestudio/ags/issues/1698

[criezy]

So the issue is that AGS added a check on the frame in CharacterInfo::UpdateMoveAndAnim(). If the frame is greater than the number of frames for the requested loop, it looks for another loop. In the case of this animation the frame is 19, while the number of frame is 7.

Will wait to see what upstream developers have to say as I don't know if that check was added in the code by mistake, or if this is an issue with the frame having an incorrect value.

[criezy]

Fixed upstream. I will merge this in ScummVM soon.

[criezy]

The fix has now been merged in the ScummVM code (both in master and branch-2-6).