#13477 closed defect (fixed)

AGS: Heroine's Quest intro shows portrait bug

Reported by: i30817 Owned by: criezy
Priority: normal Component: Engine: AGS
Version: Keywords: intro heroinesquest
Cc: Game:


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.

Change History (6)

comment:1 by Crystal-Shard, 21 months ago


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.

comment:2 by criezy, 21 months ago

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.

comment:4 by criezy, 21 months ago

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.

comment:5 by criezy, 21 months ago

Fixed upstream. I will merge this in ScummVM soon.

comment:6 by criezy, 21 months ago

Owner: set to criezy
Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.