Author Topic: Possible ScummVM bug?  (Read 1755 times)

0 Members and 1 Guest are viewing this topic.

Offline troflip

Possible ScummVM bug?
« on: June 11, 2015, 11:03:31 AM »
I've been playing around with the polygon editor in the SQ5 code (via the SCI1.1 template game), and it crashes in Scumm with a "signature mismatch" for kPrevNode when adding the second polygon point.

PolyEdit::saveForUndo passes a node value to the prev method of a List, which then calls PrevNode with the node value (instead of the node handle). It looks like Scumm expects only a node handle.

From the code in PolyEdit, it seems that PrevNode (et al) in Sierra's interpreter must have been able to handle node values in addition to node handles? I'm not sure how, since if the same value appeared in different nodes, how could it do the reverse mapping? Nonetheless, that's what the code does (it also expects a node value returned from PrevNode, instead of a handle). The code in LSL6 is identical too.

Actually, come to think of it, it just may be a bug in Sierra's code - as long as the bad code didn't crash the interpreter (it doesn't), it's possible it might not be terribly noticeable - it just breaks the undo functionality of their polygon editor.

[edit:] Also, the polygon editor code calls the Atan kernel, which is unimplemented in Scumm. Sierra's interpreter freezes when I try to exit and save the polygon, and I'm trying to debug it - but I'm having trouble doing that with Scumm because I can't even get that far :P. I'll remove the Atan call (which appears to be part of validation) and keep trying...

« Last Edit: June 11, 2015, 11:11:48 AM by troflip »

Check out my website:
Groundhog Day Competition

Offline lskovlun

Re: Possible ScummVM bug?
« Reply #1 on: June 11, 2015, 12:16:54 PM »
There are many ways to write code that will silently fail in Sierra SCI. I've been looking at some code in Conquests of the Longbow which looks like it was written by someone who didn't understand the semantics of the SCI language (an intern, perhaps?). The code runs but clearly doesn't do what was intended; from the looks of it, the worst consequence would be an occasional graphical glitch. Kernel calls often fail silently, too. We've even stumbled upon a piece of code in LSL5 which only happened to work because of a lucky coincidence with memory and class layout. Any small change in that class could have led to a very insidious bug in the original interpreter (as it was in ScummVM).

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.078 seconds with 23 queries.