This isn't finished, but I've been sitting on it for awhile. Any help with completing it would be appreciated, as would general feedback.
Thanks! ----- Inspecting objects in SCI interpreters In this example, we will look at bug #310. This is more about eliminating possibilities and providing valuable information to FreeSCI developers than tracking down the real problem. Hopefully this tutorial will be updated at some point with how to further investigate to find the real problem. In bug #310, ego is drawn in front of a tree when approaching it from behind. This can seem like the same problem in the previous tutorial on control map debugging, but looking at the control map you will notice they are the same in Sierra SCI (SSCI) and FreeSCI (FSCI). If the control map isn't the problem, what else could it be? Well, the priority of the tree could be wrong, or the calculated priority of ego could be wrong for the coordinates it is at, ego didn't stop when it was supposed to, or any number of other reasons. Let's go through each one of these things and eliminate possibilities. First, let's figure out at what coordinates ego stops behind the tree in SSCI. This is pretty easy, walk up behind the tree in SSCI and break into the debugger. Once in the debugger, press "i" for Inspect. You can press "?" to get a list of basic commands. We use the inspect functionality to view the attributes for objects, like the superclass they are derived from, their x and y coordinates on the screen, which view they are, which cel in the view is currently displayed, etc. In this case, we are going to inspect ego to get it's current coordinates on-screen; specifically, the y coordinate and the priority. After pressing "i" for inspect, enter the object name you want to inspect. In this case, "ego" (without quotes) and press enter. You should now see a screen list this <INSERT SCREENSHOT OF KQ4 EGO INSEPCT>. I like to take a screenshot of the object inspect because I almost always have to keep referring to it, just like we will later in this tutorial. We see that the y coordinate is 84 and it's priority is 5 <NEED TO VERIFY THIS>. Now we need to compare the same values in FSCI. We should try to get ego at approximately the same x coordinate in FSCI as it is in SSCi just to be exact. In FSCI, get ego to the tree and approach it from behind after ego stops, it should display the tree just behind ego. This is the bug in FSCI. At this point, break into the FSCI debugger by pressing Control+~. In FSCI, we have to inspect objects by their address in the SCI heap instead of using the name. First, we have to get a list of the current objects in the heap by typing "objs" and pressing enter. You will see a long list containing things like this: "%Chase @8d46 %Avoid @8eaa cast @5a5c sounds @5a78 regions @5a94 addToPics @5ab0 controls @5acc timers @5ae8 ego @5b04 %Game @6084 %Rgn @619a" The name of the object is on the left, the heap address off that object is on the right. After hunting through the list, we see that the object named ego is at address 5b04 (note that this is not static and may change between runtimes!). Now we have to inspect that heap object; we do this with the "heapobj" command, which takes the heap address as it's parameter. So, in this case, we type "heapobj 0x5b04" and press enter. Prefixing the heap address with "0x" is necessary so the debugger knows you are specifying a hex value (base 16), which is what is given to us in the list of objects. After performing the object inspection, we get a long list of properties for that object. We are first looking for the x coordinate to make sure we're at the same place as in SSCI, then the y coordinate to see if FSCI isn't stopping ego soon enough, and the priority value to see if FSCI isn't caluclating the priority of ego the same as SSCI. If your x coordinate isn't the same, resume the game by typing "go" at the FSCI debugger prompt, moving ego a little, break into the debugger, check the x coordinate, and repeat as necessary until it's right. Sometimes using the mouse cursor to click on a specific pixel can help get this right, and/or slowing down the animation a lot. Once ego in FSCI at the same X coordinate as ego in SSCI, go straight down and run into the tree. Now we break into the debugger and figure out at what Y coordinate ego has stopped, and what ego's priority is at that coordinate. Let's take a look: " y[0006] = 0054 (84) x[0008] = 0013 (19) yStep[006e] = 0001 (1) view[000a] = 0002 (2) loop[000c] = 0002 (2) cel[000e] = 0005 (5) priority[007e] = 0005 (5)" The y coordinate and the priority appear to be correct. What else can we look for? We can also see if the rectangle draw on the screen for the object is the same since that is often used for collision detection. <INSERT BIT ABOUT CHECKING brRECT and/or nsRECT> <INSERT BIT ABOUT DISCOVERING THE TREE IS A PIXMAP> -- http://www.clock.org/~matt
