Opened 13 years ago
Closed 16 months ago
#6085 closed defect (fixed)
SCI: LONGBOW: Man with Tuck in camp
| Reported by: | tsoliman | Owned by: | bluegr |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | 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)
Change History (14)
by , 13 years ago
| Attachment: | longbow.jpg added |
|---|
comment:1 by , 13 years ago
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 by , 13 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:3 by , 13 years ago
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 by , 13 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → new |
comment:5 by , 13 years ago
That doesn't change that the same loop isn't being used in dosbox in that scene, though.
comment:6 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
kGetAngle was changed from SCI1 (QFG2 onwards)
Properly fixed in 9568b78babdbdf350fd6c47b261c3f21902c31fc
comment:10 by , 13 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:11 by , 16 months ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
This is still an issue. Current behavior might be different than back when this was reported, but Tuck still changes loops in ScummVM instead of staying seated as in the original.
I agree that the issue is probably in the kGetAngle calculations, but the script is doing something weird.
On day one, Tuck is sitting and eating fish. The script tuckAlone calls the Face function to make Robin face Tuck, and then it also calls Face to make Tuck face Robin. That second call doesn't make sense, because Face is for actors who are standing up so they can change directions. The Tuck actor always has a looper (tuckGrooper) so changing his heading, etc sets off a series of events that *could* change his loop, depending on the angle values returned from the kernel.
In the original, this second Face call has no visible effect. In ScummVM, it changes Tuck's loop.
comment:12 by , 16 months ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Closing this again; what I'm seeing is original behavior. I was testing a different version in DOS earlier.
The Sheriff flicker when Tuck stands is original behavior introduced in version 1.1. That's when they added the Face calls I described above. It's behaving the same in both interpreters.
Screenshot