Recreating complete QFG1 EGA source code

[Charles]

So I've decompiled QFG1 EGA, and am going through trying to replace any proc# or localproc# with actual descriptive names (same for global variables, etc), and it's going fairly well. I'd say I'm learning a lot about SCI scripting in the process, but there are a couple of items/questions that have come up that I'm not sure how to interpret.

1) in script 968 (SmoothLooper) the doit method of the SmoothLooper class decompiles into this:

Code: [Select]

(method (doit &tmp [temp0 2])
CorruptFunction_CantDetermineCodeBounds
)
So clearly something unexpected is going on with the byte-code. I'm not really too keen on understanding the raw byte-code, but at the very least is there a way to force SCICompanion to try converting it to asm?  Unless anybody has an other suggestion?

2) kernel_113 is called in several scripts (1, 255, 202, 32).  Is this an undocumented kernel call?  No clue what it is supposed to do.

3) DoSound. The documentation (http://scicompanion.com/Documentation/Kernels/DoSound.html?highlight=sndCHECK_DRIVER) says that DoSound(sndCHECK_DRIVER) only returns TRUE or FALSE, depending if the sound driver is installed, however there is code in QFG1 to the effect of (DoSound(sndCHECK_DRIVER) == 1), (DoSound(sndCHECK_DRIVER) <= 4), (DoSound(sndCHECK_DRIVER) > 4), implying it is more along the lines of the number of music channels present.

That's about all I have for now. Thanks for reading.

[troflip]

1) Companion currently determines the boundaries of a function by getting the start point (which is known). Then, it walks the code from that point, looking for a ret (return) opcode that is beyond the target of any branch instructions encountered yet. The problem is, the script in question is corrupt (using SV.exe, look at the bnt instruction just after code_01b7) - there is a branch that goes way off into space (clearly it must be in code that is never actually executed at runtime - I wonder how Sierra's compiler generated this byte code though). This confuses Companion, so it can't determine where the function ends (hence not even being able to fall back to asm). You can see a little message about this in the decompiler output window (ERROR: Invalid branch target).

Let me think what I can do about this. I can probably use the starts of other functions to at least know that that branch goes out of bounds. I maybe not be able to produce readable code, but at least it could fall back to asm.

2) That might be Joystick. From ScummVM (unimplemented): // Subfunction 12 sets/gets joystick repeat rate

3) It probably is. Much of the SCI0 documentation was copied from the SCI Studio docs. Indeed, ScummVM calls it "DoSoundGetPolyphony".

[troflip]

I got it to output some source code (attached).

The bad branch instruction got replaced by -17747 in the source code ($baad in hex). So it's not "correct", but that code must never get hit anyway (as it would crash)

[OmerMor]

So I've decompiled QFG1 EGA, and am going through trying to replace any proc# or localproc# with actual descriptive names (same for global variables, etc), and it's going fairly well.

That's a cool project!
Would you be sharing your results when you're done? We could all learn from your work.

2) kernel_113 is called in several scripts (1, 255, 202, 32).  Is this an undocumented kernel call?  No clue what it is supposed to do.

2) That might be Joystick. From ScummVM (unimplemented): // Subfunction 12 sets/gets joystick repeat rate

Actually, kernel 113 is "Intersections":

Code: [Select]

Computes the nearest intersection point of a line segment and the polygon
set. Intersection points that are reached from the inside of a polygon
are ignored as are improper intersections which do not obstruct
visibility
Parameters: (PathfindingState *) s: The pathfinding state
            (const Common::Point &) p, q: The line segment (p, q)
Returns   : (int) PF_OK on success, PF_ERROR when no intersections were
                  found, PF_FATAL otherwise
            (Common::Point) *ret: On success, the closest intersection point


[troflip]

I think that's for SCI1 - this is SCI0, where Joystick is 113 (the parameters also match the signature). Open the game in Scumm, go to the debugger and type "functions" and you'll see.

[OmerMor]

Sorry - you are correct!

[Collector]

I was just looking at the script from Hero's Quest and it seems to be different from that of QfG1EGA.

[Charles]

2) That might be Joystick. From ScummVM (unimplemented): // Subfunction 12 sets/gets joystick repeat rate

Oh yeah, that makes sense... they're setting the joystick repeat rate to 0 before disposing... so that'd make the 12 actually jsCALL_DRIVER.

I got it to output some source code (attached).

Oh, that's awesome!  I've put that code in place.

I was just looking at the script from Hero's Quest and it seems to be different from that of QfG1EGA.

Yeah, I noticed the same thing.  At least HQ v1.000 does.  HQ v1.102 looks more or less identical to QFG1 v1.2.

I just assumed that's the same style as the earlier KQ4 and LSL2 scripts. I haven't looked at those myself.  There's a bunch of differences in HQ v1.000. Like each script starts off with the line (version 2), Includes and Uses have quotes around the filenames, the script number declaration doesn't use the # sign, there are no temp variables created with a procedure (instead there's a var declaration at the start of applicable procedures, public is called exports and its index then name, instead of the other way around.  Oh and it looks like {} are not used on embedded strings.  Dunno if there are any other differences... or what it really means.

[troflip]

I just assumed that's the same style as the earlier KQ4 and LSL2 scripts. I haven't looked at those myself.  There's a bunch of differences in HQ v1.000. Like each script starts off with the line (version 2), Includes and Uses have quotes around the filenames, the script number declaration doesn't use the # sign, there are no temp variables created with a procedure (instead there's a var declaration at the start of applicable procedures, public is called exports and its index then name, instead of the other way around.  Oh and it looks like {} are not used on embedded strings.  Dunno if there are any other differences... or what it really means.

None of this has anything to do with the game itself. It just means you have set the game language to "Sierra Script" as opposed to "SCI Studio" when decompiling (set in Game->Properties).

Things should default to Sierra Script, unless Companion thought you had been editing it in SCI Studio (I think if it detects a game.ini in your game folder that doesn't have an explicit language setting, it might do that).

Some relevant documentation links:
http://scicompanion.com/Documentation/scripts.html#sierra-script
http://scicompanion.com/Documentation/sci_compiler.html

[Charles]

Oh. That explains why the syntax is like a slightly distorted version to what I'm familiar with. Not sure on why it defaulted to that though. I copied the game.ini file from my QFG1-EGA decompile, so I could keep the filenames I'd settled on.

[troflip]

I might be able to be more aggressive about defaulting to Sierra script. I guess I was trying to avoid problems for people with existing games that didn't want to convert their stuff over to the new Sierra script syntax.  Maybe if the language is "unspecified", then I can check and see if there is a Main.sc that is in the old syntax. If not, then I will assume Sierra script.

[troflip]

Let me know if you're interested in trying out a build of Companion that includes a bunch of decompiler fixes. I've been slowly plugging away at decompiler bugs - mainly the insidious ones that silently produce code that is incorrect. So that the "dream" of being able to "recompile all" and expect it to work perfectly is closer...

It's not quite there yet, but I've been able to decompile Laura Bow 1, and recompile all scripts (correcting a few errors that the decompiler can't possibly make sense of, like missing scripts), and it works well enough to to get through all the intro stuff, and walk around a few rooms and talk to people. I just tried QFG1, and there are still about 4 compile errors I get that I should be able to get rid of with a little more decompiler/compiler work.

[Collector]

Thank you. On another note, I would love to setup a repository of the source for official games that will compile without error. Perhaps a repository on the Wiki.

[OmerMor]

Great idea!
But the code better be kept in some kind of source control repository like git or mercurial, so people could work on it in a continuous way.

[Collector]

I use Bitbucket for my projects. It allows 5 users per account with unlimited repos. I would be happy to add a couple more users for this.