Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6085 closed defect (fixed)

SCI: LONGBOW: Man with Tuck in camp

Reported by: tsoliman Owned by: bluegr
Priority: normal Component: Engine: SCI
Keywords: script Cc:
Game: Conquests of the Longbow

Description

Step to reproduce:

Start a new game.
Go outside the cave.
Skip dialogue.
Click on map icon to travel.
Click on campfire icon to go back to the camp.
Observe Tuck. There is a man with him that the game doesn't achknowledge.

Ticket imported from: #3540976. Ticket imported from: bugs/6085.

Attachments (2)

longbow.jpg (56.3 KB) - added by tsoliman 7 years ago.
Screenshot
longbow.003 (33.7 KB) - added by tsoliman 7 years ago.
Savegame with the bug present

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by tsoliman

Attachment: longbow.jpg added

Screenshot

Changed 7 years ago by tsoliman

Attachment: longbow.003 added

Savegame with the bug present

comment:1 Changed 7 years ago by wjp

Happens for me too.

Also tried dosbox: there it doesn't behave exactly the same as in scummvm, but it has a similar glitch for a little while at that spot.

comment:2 Changed 7 years ago by bluegr

Resolution: invalid
Status: newclosed

comment:3 Changed 7 years ago by bluegr

In this case, both Friar Tuck and the unknown man belong to the same view (view 168, loop 2). So it's completely logical that the second man can't be interacted with, as the two are counted as the same sprite (friar Tuck). Therefore, this seems like a normal game animation, which is supposed to be shown that way. Closing as invalid.

comment:4 Changed 7 years ago by wjp

Resolution: invalid
Status: closednew

comment:5 Changed 7 years ago by wjp

That doesn't change that the same loop isn't being used in dosbox in that scene, though.

comment:6 Changed 7 years ago by bluegr

Ah, that wasn't apparent from the previous replies.

This is a script bug, game scripts set an invalid cel number for Friar Tuck. In this case, this invalid number gets fixed inside GfxAnimate::adjustInvalidCels() but the original interpreter also sets the loop to 0, which we don't do (thus a wrong loop is shown).

This is just bad design from the original engine. It's not very safe to change this check unless we can absolutely verify it against disasm (and how it has been changed with each SCI version). Alternatively, we could put a game ID/room check for it

comment:7 Changed 7 years ago by wjp

Some experimenting seems to point at subtle numerical differences in GetAngle being responsible for this.

Switching to an atan2-based GetAngle instead of the current approximation makes scummvm behave like dosbox for me.

comment:8 Changed 7 years ago by bluegr

The problem has been narrowed down to our implementation of kGetAngle.

I've added a hack to fix this for now, but kGetAngle will have to be revised so that it's closer to the original behavior after the 1.5.0 release.

comment:9 Changed 7 years ago by bluegr

kGetAngle was changed from SCI1 (QFG2 onwards)

Properly fixed in 9568b78babdbdf350fd6c47b261c3f21902c31fc

comment:10 Changed 7 years ago by bluegr

Owner: set to bluegr
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.