SCI Companion V3 - alpha build notes/bugs/feature requests

[MusicallyInspired]

There's always another day. If you don't get time for it now, there's no rush. You're making amazing progress into areas I never thought SCIComp would go!

[troflip]

New version released :-)

[troflip]

And again, small fix.

[gumby]

Just downloaded the most recent version, looking very good.  Still poking around just in the SCI0 space so far.

I do have a feature request, Troflip.  Any thought into implementing asm?  I'd love to be able to use this new compiler for my Zork port, but had to fall back to using Studio because of this (and possibly some other issues, I can't remember specifically).

[Kawa]

Any thought into implementing asm?

You mean like this?

Code: [Select]

        (asm
code_088d:  pushi   #type
            pushi   0
            pushi   #new
            pushi   0
            pushi   #curEvent
            pushi   0
            lag     gUser
            send    4
            send    4
            sat     temp1
            send    4That's from invi.sc, SCI11 template.

[gumby]

Yeah, like that.  I specifically need it to handle labels and jumps, but I couldn't get it working.  From the SCI Studio docs:

Code: [Select]

// the inline assembly is quite versatile. Here's a crafty example:
(if(something)
  (asm jmp _a_goto_label)
)
(asm _a_goto_label: )

Any pointers here?

[Kawa]

I don't know much about the asm block myself, sorry. The only ones I've seen were entire method and procedure blocks that failed to decompile.

[Collector]

Phil can say, but I suspect that he does not want to tamper with the Sierra syntax. Not sure how much you have caught up on developments, but we now have have some samples of the original syntax and the new version can convert scripts form SCI Studio to the original Sierra SCI. You can read the original Sierra internal SCI documentation on the Wiki here: http://sciwiki.sierrahelp.com//index.php?title=Official_SCI_Documentation

Also Phil's SCI Companion documentation: http://scicompanion.com/Documentation/index.html

I have yet to delve into the Sierra scripting, so I cannot say if this can be done natively in SCI or not. Take a look at Phil's "SCI Quest" that shows off some of what we can do now. http://scicompanion.com/download/

[troflip]

The original Sierra syntax didn't have an asm statement at all. I suspect Brian added it because it made it easy to manually decompile piecemeal (just like Companion needs it to decompile everything, since the decompiler isn't perfect).

The Companion asm syntax is a little different than Brian's. Specifically, you can't jmp to labels in other asm blocks, only within a single block (there are other differences too).

How much asm do you have in Zork? And why???

If it's not too much, you could just decompile it to generate Companion-compatible asm (or with any luck it will turn it into readable source code) (and without luck it will crash or do something weird since I suspect you're using asm to do some "creative control flow" with gotos).

[gumby]

Yeah, I'm really behind in what you guys have going with SCI now for sure. 

I've got quite a bit of asm in Zork as the decompiler that I use to decompile Zork's z-machine code generates gotos. To give a bit of background, I'm programatically generating room scripts from the output of the z-machine decompilation.  So potentially one could take any z-machine game and create a SCI game without writing any code at all.  I could manually rewrite/rework the generated scripts and change the gotos to use proper looping constructs (I think, not sure) but I was really hoping not to do that. 

Hoping to get back to Zork eventually and I'd really like to see what it would take to get it compiling under Companion as Studio is unmaintained and crash-prone.  Not to mention I'm maxed out on heap space and I know that Companion typically consumes less heap than Studio.

I mentioned that there are other things holding me up from using Companion, I just don't remember what they are.  If it would be helpful, I can run it through Companion and see what else it balks at besides the gotos and report the findings here.

[troflip]

If it would be helpful, I can run it through Companion and see what else it balks at besides the gotos and report the findings here.

Sure, it would be good to track feature requests. Keep in mind that except for bug fixes and easy/low-risk changes, I probably won't have much time to work on Companion in the future though.

I could manually rewrite/rework the generated scripts and change the gotos to use proper looping constructs (I think, not sure) but I was really hoping not to do that. 

It's not easy to do robustly (speaking from experience working on the decompiler). That's probably why Zork's decompiler uses gotos. Although handling gotos in source code is likely easier than jmps in asm, since gotos always go to a specific statement (whereas jmps can jump into the middle of a group of instructions that might normally comprise a single statement, and so you have to figure out how to decompose that properly).

Not to mention I'm maxed out on heap space and I know that Companion typically consumes less heap than Studio.

Companion generates scripts that use about 10% less heap IIRC. Have you verified that it's due to the size of your scripts, and not because you're forgetting to unload certain scripts on room changes?

Also, SCI1.1 significantly increases the amount of heap available, since the script logic is no longer in the heap (just the local variables, strings, and class/instance properties and method lists). Oh, but of course there is no parser in SCI1.1.

[gumby]

Companion generates scripts that use about 10% less heap IIRC. Have you verified that it's due to the size of your scripts, and not because you're forgetting to unload certain scripts on room changes?

Also, SCI1.1 significantly increases the amount of heap available, since the script logic is no longer in the heap (just the local variables, strings, and class/instance properties and method lists). Oh, but of course there is no parser in SCI1.1.

Oh yes, not much I can do with the heap.  The main issue is the sheer number of global variables used to track the state of objects in the game.

With no parser in SCI1.1, maybe it's time to re-imagine the project.  Might be good just to blow everything up and start over, might be refreshing to take a point-and-click approach.

[Kawa]

Or, god forbid, write your own parser

[MusicallyInspired]

There's always the XMas Card interpreter possibility...

[troflip]

Oh yes, not much I can do with the heap.  The main issue is the sheer number of global variables used to track the state of objects in the game.

Any many of them boolean values? You can store 16 of them in one global variable location, saving a lot of space. Sierra did this.