Problem recreating QFG2 source

[Charles]

Oh, that's brilliant.  The code/heap seperation would also explain why ScummVm appears to be unaffected, while SSCI is having trouble.

The only warning that ScummVM gives me on my compiled code vs stock QFG2 is:
WARNING: detectLofsType(): failed, taking an educated guess!

Which happens before Trial:init, based on where I placed my SetDebug breaks. Also before Trial:play... which I thought was supposed to be the first thing called?

[lskovlun]

The only warning that ScummVM gives me on my compiled code vs stock QFG2 is:
WARNING: detectLofsType(): failed, taking an educated guess!

This has to do with whether the argument of lofsa/lofss is relative or absolute. It is indeed determined before a single line of script code is run.

[Charles]

Hmm... So that's a ScummVM function... I see here that it depends highly on the getSciVersion function.

So ScummVM doesn't detect it as SCI_VERSION_01 (which is what it should be), but has to guess... looks likeit picks either SCI_VERSION_0_EARLY or SCI_VERSION_1_MIDDLE.  I'm guessing SciCompanion's compiling it as SCI_VERSION_0_EARLY... but ¯\_(ツ)_/¯ -- still, this kinda circles back to it being a bytecode discrepancy.

Can I force SciCompanion to compile scripts under a different version?

[troflip]

You can with Game -> Version Detection. It'll let you reload the game with overridden behavior, including "LOFSA Absolute". But you have to do it each time you load the game - it was only meant to debug version detection issues, and I never got around to persisting the version settings in a file somewhere.

But if the problem was lofsa absolute/relative, the game would crash almost instantly, so i kind of doubt that's the issue...

[lskovlun]

(also doesn't ScummVM keep code and heap separate, and warn if someone tries to write to script memory?)

Also, this is more complicated than that. SSCI made the innovation of separating stuff that needs to be in the heap and stuff that's stored in the hunk. At first, this was done at run time, later (in SCI1.1) at compile time. That is why the SCI01 debugger has those 'es:' and 'si:' displays (ES refers to the x86 segment register and points to somewhere in the hunk, SI likewise is an x86 register). SN stands for 'script number'. ES and SN should change at the same time, and if they go out of whack unexpectedly, that's another clue.



ScummVM actually stores the script in one piece (in the case of SCI1.1, the script and heap resources are concatenated and stored in one segment). Local variables get their own segment (one per script file), and there is one segment for clones (dynamically created objects), lists and list nodes.

I agree with the part about relative/absolute addressing being an unlikely cause.

[Charles]

I'm not necessarily suggesting the SSCI problems I'm having with QFG2 are because of lofsa, but I am thinking more generally that SciCompanion is having a problem compiling SCI01-compatible scripts [see edit 1].

A problem that is just subtle enough it's not outright crashing in SSCI, but is causing ScummVM to detect the SCI version as > SCI_VERSION_01 and < SCI_VERSION_1_1.  So one of: SCI_VERSION_1_EGA_ONLY, SCI_VERSION_1_EARLY, SCI_VERSION_1_MIDDLE, or SCI_VERSION_1_LATE.

I don't know what the differences are in compiling for any of those, but that's the only conclusion I'm able to draw.

I don't think the problem is with script.002-- that's just the first indication I had there was a problem.  If I run my compiled QFG2 in ScummVM with a stock SCRIPT.002, it still trips up on auto-detecting.

I'd try stepping through ScummVM to see what exactly is causing that detectLofsType warning, but I haven't gotten scummvm to compile on my machine yet.

EDIT 1: Or whatever version of SCI is used by QFG2... I always thought it was called SCI01, but I'm seeing different naming conventions in the ScummVM code.

[lskovlun]

I don't think the problem is with script.002-- that's just the first indication I had there was a problem.  If I run my compiled QFG2 in ScummVM with a stock SCRIPT.002, it still trips up on auto-detecting.

The lofsa/lofss autodetection uses script 994 (aka Game.sc) and the Game class in particular. If the methods of that class do not contain even one lofsa or lofss instruction, it'll throw the warning you're seeing. I've no idea how that could happen. A disassembly of that script might help.

EDIT 1: Or whatever version of SCI is used by QFG2... I always thought it was called SCI01, but I'm seeing different naming conventions in the ScummVM code.

Yes, ScummVM needs to make a lot of fine-grained distinctions in versioning but sticks with a relatively small number of version constants. You can try the version command in a debug console to see just how bad it is.

[Charles]

EDIT: I posted the two full dissessemblies, but they were too big.

I see a bunch of lofsa commands in each.  I'm assuming the line "01d6:72 0b3b          lofsa $0d14 // cast" means QFG2 uses relative addresses for lofsa commands -- starting at address $1d6, add 3 bytes for the lofsa command (plus arguments), then jump $b3b bytes, ending up at address $d14.

Other than the order of the classes and instances being different between the two versions, I can't see anything odd.

EDIT 2: Added a recompiled SCRIPT.994 from QFG1EGA.  ScummVM does not flag any detectLofsType() warnings in that recompiled game, and again I can't see any significant differences between it and QFG2's.

[lskovlun]

OK, so I've looked at the attached files. There was a transcription error in your original posting; in sag 'with an argument', the argument would get lost. This sequence of files shows that in the originals, the sag/lag parameters are not shown. In the files compiled by Companion, the parameters do show. But this is disassembling, and a very different thing from actual compiling. Also, the Companion files shuffle objects around in a different order than the original compiler. I don't think it's important.

The lofsa/lofss arguments are relative in both compilers (but because of the reshuffling mentioned about the actual numbers are different).

So we don't really learn much from this.