Is there a SCI32 compiler? If not - why?

[ZvikaZ]

As I've been told in other thread, Scicompanion can't compile SCI32 games. Do we have any other tool that can do that?

If not, is there a technical reason for this? Some complexity maybe? Or it's just that noone had the time/interest to write one?

[Kawa]

From a cursory glance at SCI16's opcodes.s and SCI32's optbl.i, then comparing that to SCI Companion, it's nothing about the set of opcodes. 0x7D and 0x7E are bad-ops in one, but tracing tools in the other (filename and line number so the internal debugger can load the original line from source). Both are accounted for in SCI Companion, though it probably doesn't make any trace opcodes so successfully recompiling an SCI32 game may cause those to disappear.

It's also not likely anything with kernel calls, since those work the same as they always have.



Tangent: the SCI32 debugger would show the current source line in a window along the top of the screen. Whenever the file or line changed, it'd search for the source file, then display the nth line. Practical example?

Code: [Select]

SQInvItem::highlight:
_line_ 36 ;--> (method (highlight param1), you'd think, but I'm not sure...
_file_ "sqinv.sc" ;...because *here* it changes the file name...
_line_ 40 ;--> (= cel (* 1 (if argc param1 else 0)))
push1 ;...so that's either not the (method) form *or* there's a couple lines of docs.
lap param[$0]
bnt code_05dd
lap param[$1]
code_05dd: mul
aTop cel
_line_ 41 ;--> "(UpdateScreenItem self)"
push1
pushSelf
callk UpdateScreenItem, $2
_line_ 42 ;--> ")"
ret

[lskovlun]

There are opcode differences in SCI32:

Code: [Select]

#ifdef ENABLE_SCI32
// In SCI32, some arguments are now words instead of bytes
if (getSciVersion() >= SCI_VERSION_2) {
g_sci->_opcode_formats[op_calle][2] = Script_Word;
g_sci->_opcode_formats[op_callk][1] = Script_Word;
g_sci->_opcode_formats[op_super][1] = Script_Word;
g_sci->_opcode_formats[op_send][0] = Script_Word;
g_sci->_opcode_formats[op_self][0] = Script_Word;
g_sci->_opcode_formats[op_call][1] = Script_Word;
g_sci->_opcode_formats[op_callb][1] = Script_Word;
}
I don't think anyone has a ready list of what it would take to make Companion compile SCI32 scripts.

[Kawa]

I stand corrected.

[OmerMor]

As I've been told in other thread, Scicompanion can't compile SCI32 games. Do we have any other tool that can do that?

If not, is there a technical reason for this? Some complexity maybe? Or it's just that noone had the time/interest to write one?

You have Sierra's own compiler (SC.EXE). I *think* I shared various versions of that compiler, ranging from 1988 to 1996.

[MusicallyInspired]

How easy is it to use those Sierra compilers anyway? I assume they won't just straight up work with Companion scripts?

[OmerMor]

How easy is it to use those Sierra compilers anyway? I assume they won't just straight up work with Companion scripts?

No idea...

[Kawa]

How easy is it to use those Sierra compilers anyway? I assume they won't just straight up work with Companion scripts?

Trying to compile the system.sc from The Dating Pool, I find the following issues:

• Must predeclare procedures.
• Object must be kindof RootObj, this is not implied.
• Classes must predeclare methods. SCI Companion ignores this, SC requires it.
• No scriptNumber.
  

I'll not count the missing defines and globals. This was on the latest version in the pack I picked, 4.100 from 1995-01-12.

... Actually using it was easy enough.

[Collector]

And what about the *.HEP resources in Companion? Or *.CSC? For all of that, what about other SCI32 resources like *.V56 and *.P56? Are there enough differences to break Companion's editors?

[lskovlun]

V56/P56 definitely changed. Kawa has some blog entries about it. CSC is the new script format in SCI3. Very different format, the main advantage seems to be that you can have huge scripts in it (> 64K), somewhat counterbalanced by the fact that scripts simply are bigger in that format. Makes you wonder if it was worthwhile to change it. We used to have a complete list of huge scripts (there aren't many) in ScummVM because we couldn't load them.

[Kawa]

As for HEP resources, those are autogenerated by the compiler.

I know this because I just successfully compiled a minimal input on SC 4.100:

Code: [Select]

(script# 42)

; Forward-declare procs -- MUST HAVE!
(procedure
  Sign
  Test
)

; Make sign externally visible
(public
  Sign 0
)

(procedure (Sign x)
  (return (if (< x 0) -1 else (> x 0)))
)

(procedure (Test)
  (Display "Hello, World!")
  ; replaced with (Display 42 0) and spawns a TEX resource in SC 1.001.023 or 2.345.000, remains inline in 4.100.
)

This gave me 42.SCR and 42.HEP. I also just confirmed it's for SCI2 because it has an option to emit trace commands.

V56/P56 definitely changed. Kawa has some blog entries about it.

I do?

[lskovlun]

I was thinking of descriptions here and here (ok, so the latter one is more like an honorable mention...).

[MusicallyInspired]

Well we do have classic tools as well to make SCI32 P56 files. I don't see a tool for V56 though...

EDIT: n/m I see PCXS2V.EXE is there.

[Kawa]

I was thinking of descriptions here and here (ok, so the latter one is more like an honorable mention...).

Ah, I was thinking of views when you meant background pictures.

[ZvikaZ]

V56/P56 definitely changed. Kawa has some blog entries about it. CSC is the new script format in SCI3. Very different format, the main advantage seems to be that you can have huge scripts in it (> 64K), somewhat counterbalanced by the fact that scripts simply are bigger in that format. Makes you wonder if it was worthwhile to change it. We used to have a complete list of huge scripts (there aren't many) in ScummVM because we couldn't load them.

So, now I understand that it's not really SCI32 vs older, but SCI3 vs older?
I'm interested in SCI2 - as I wrote in the other thread, I'm trying to compile GK1 scripts.
How much do they differ from SCI1?