Possible new version of SCI Companion

[troflip]

Title screen of SQ5 with two menu entries swapped, and the background color of one of them changed.

[MusicallyInspired]

[Cloudee1]

Title screen of SQ5 with two menu entries swapped, and the background color of one of them changed.

So does that mean you figured out the interpreter issue or is this a scumm shot

[troflip]

I figured out the issue, I posted about it in one of the other threads. Looks like many (all?) of the opcodes that don't have "wide" or "short" versions are only valid if they are the "wide" version (e.g. they don't have the last bit set). This is different than SCI0, and might indicate they were making (or made) room for other opcodes?

[Collector]

Have you had to make many changes to the compiler for SCI1/SCI1.1?

[MusicallyInspired]

Awesome to see changes are possible on even a small level!

[troflip]

Have you had to make many changes to the compiler for SCI1/SCI1.1?

Specifically for the code generation for the compiler, I wouldn't say many, no.

I had to add asm support for when the decompiler fails (although that's unrelated to SCI1). A few opcodes changed behavior, so I had to make some small changes there. I had to support using if statements and switch statements as epxressions.

Reading/Writing the script resources is completely different in SCI1.1 though. And there are 9 default properties for a class instead of 4, so I had to change anywhere my code made that assumption. Though it's not strictly related to the compiler, those were a lot more significant changes.

There are still a few more changes to make. Script local variables can contain pointers to strings and objects, so I need to support that in the syntax. And I'd like to do do something about the and/or conditions. SCI Studio ignores all parentheses for grouping and/ors together, but that is counter to nearly every programming language, and the decompiler generates code that relies on those parentheses. This will be a breaking change - I don't know if the SCI Studio template game would be affected or not. Not sure what I'm gonna do about this yet.

[Collector]

If you are talking about Brian's SCI1 template, it is not quite complete anyway. If the SCI0 template what about a new template? Or I suppose you could have two compilers, the old one and the new one and have the GUI call the one that matches the interpreter of the game being compiled. This could give the best backwards compatibility for old projects.

[troflip]

I was talking about the SCI0 template. There's no functioning version of SCI Studio that can compile SCI1, so no worries there.

But yeah, ideally I'd like to keep syntax compatibility for SCI0 as much as possible between SCI Companion and SCI Studio.

In SCI Studio (and SCI Companion, currently) the following code executes the branch and prints "hi".

Code: [Select]

        (= a FALSE)
        (= b TRUE)
        (= c TRUE)
 
        (if (a and (b or c)) // SCI Studio treats this as (a and b or c)
            Print("Hi")
        )

It shouldn't though. And my decompiler will construct compound conditions like that that it expects to evaluate to false.

[troflip]

I was able to compile the main script in SQ5 and it "works"!. That's pretty significant. I say works, because it works until someone calls an export in main and gets the wrong export, since I'm not preserving the "mystery" empty slots in the export table. Assuming that's the problem, it should be an easy fix. But it works enough to be able to walk around in the game a bit.

[MusicallyInspired]

Wonderful!!

[troflip]

I've now compiled most of the "core" decompiled scripts in SQ5 and been able to run the game with no apparent bugs (I'm sure there are still some/many, but they are not apparent in just walking around a handful of screens, using the inventory, bringing up dialogs, etc..).

The decompiler still has some cases where it produces bad code, but I am not going to spend the time fixing it. It's 99% there, and I can keep a small list of places that produce known bad code.

So the next step is to try to distill SQ5 down to a bare-bones template game. I'd rather use the LSL6 interpreter since it's a little newer and we know it supports 16-bit audio. But the bare-bones game is going to include at least some residual "look and feel" (i.e. the UI) code from the game it was sourced from, and the UI from LSL6 seems too stylized. Hopefully the same base code will work on the LSL6 interpreter, we'll see.

[Collector]

I would think that it would mostly be a matter of the graphics that would be the biggest difference. I agree that for a template game the UI should be more generalized rather than stylized.

[MusicallyInspired]

Exciting! To make things possibily easier, I wouldn't mind helping to modify some graphics for a template game for a more neutral/generic style. We're going to need all sorts of VGA things too like Ego, cursors, test inventory object (maybe?), etc. Many of those being outside my skill set. Maybe we could get something similar to the SCI0 template game's Ego (blue shirt, gray pants) but in VGA. Maybe captured somehow? Anyone have a blue tshirt and grey pants? lol

Here's a question, how is the color/style of the GUI windows set? They're not based on Views, right?

[Collector]

I think they are views since they are animated. You could check with SV to be sure. Once we have some VGA tools we can use for the task we could have a community contest for graphics for the VGA template. That could be fun. It wouldn't be so bad to have a few different styles of UI for a developer to choose from depending on the nature of his game. Ego will have to have loops for moving diagonally.