[Scummvm-tracker] [ScummVM :: Bugs] #17306: MADS: ROTP: animation glitch

[ScummVM :: Bugs]

#17306: MADS: ROTP: animation glitch
----------------------------------+------------------------------------
Reporter:  VonKossa               |       Owner:  (none)
    Type:  defect                 |      Status:  new
Priority:  normal                 |   Component:  Engine: MADS
 Version:                         |  Resolution:
Keywords:  Return of the Phantom  |        Game:  Return of the Phantom
----------------------------------+------------------------------------
Comment (by fusefib):

 We can get here via `teleport 104 301`. It appears to be an engine-wide
 scheduling bug.

 Debug decorations confirm how it can be triggered after selecting
 conversation options:

 * Tick 2556: Parser trigger 71 (`ROOM_104_ME_TALK`) arrives while Daae's
 invisible animation is at frame 1, due to advance. Room 104's daemon is
 skipped because the active trigger belongs to the parser.
 * Tick 2559: The animation reaches frame 2 without being reset to frame 0.
 The entire walking animation continues despite `daae_walk_action == 0`.
 * Tick 10585 onward: Trigger 81 initiates the legitimate departure, with
 `daae_walk_action == 1`.

 There is no problem with the room translation itself. The underlying
 problem seems to be the interaction between `game_main_loop()`,
 `kernel_process_all_animations()`, and the Room 104 animation handler. The
 room code expects to inspect frame 1 before the animation advances, but
 the shared engine can advance it on a loop iteration where the room daemon
 isn't called.

 In `engines/mads/core/game.cpp`, the room daemon only runs if there is no
 active trigger, or the trigger is daemon-directed:

 {{{
         // Execute daemon code, and do system maintenance
         if (!kernel.trigger || (kernel.trigger_mode ==
 KERNEL_TRIGGER_DAEMON)) {
                 game_daemon_code();  // interface, room,sect,global daemon
         }
 }}}
 https://github.com/scummvm/scummvm/blob/master/engines/mads/core/game.cpp#L1742-L1745


 But later in the same loop, the engine calls:

 {{{
 kernel_process_all_animations();
 }}}

 In `kernel.cpp`, that function permits animation advancement during parser
 triggers unless the animation is at its final frame. Daae is at frame 1 of
 138, so that protection doesn't apply.

 An engine-level fix seems easy, but might break other timing stuff. It may
 be safer to do workarounds in affected rooms such as this one (room104),
 potentially 113 and 204...
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/17306#comment:2>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM