Messages

16

SCI Development Tools / Re: SCI0, SCI1 command-line tools to extract resources?

« on: January 31, 2024, 01:02:58 PM »

Also there's a lot of official interpreter source code, plus scummvm, to use as reference for re-writing resource extraction tools. Most of the formats are very simple.

17

AGI Community How To's & Tutorials / Re: Is there any way to do a "for" loop in AGI?

« on: January 29, 2024, 01:14:33 PM »

Looks good although in most languages the body won't execute at all if the condition fails initially, so you probably want to move the "statements to repeat in each loop" to be inside the condition

Otherwise for things like  for(i = 0; i < count; i++), if the count is 0 your template still executes the body once

18

SCI Development Tools / Re: Can SCI script be modernized into the current age of programming languages?

« on: January 25, 2024, 12:56:05 PM »

I've long dreamed of getting access to SCI scripts in a modern programming language.

Can you elaborate? What is the end goal here, there are some specific game or system SCI scripts that you really like, but you'd like to be able to use them from another language? I'm pretty sure all of the SCI scripts are readable, either the original Sierra version has been leaked, or the decompilers are good at reconstructing the original code. Which scripts do you want to use elsewhere, it seems like it wouldn't be a hard task to rewrite them in a different language?

...what I don't like is reading an old Small-talk, Lisp style language with a bajillion parenthesis and prefix-notation for expressions. It makes my eyes bleed.

I think it would be pretty easy to take SCI source and convert it to a different style using pretty simple pattern matching. For example, "(+ a b)" turns into "(a + b)" and "(obj x: 12)" turns into "obj.x = 12" or "(obj.x(12))" depending on whether "x" is a property or method...

I guess I don't really see the utility in trying to get an embeddable SCI interpreter to be able to call into SCI scripts. Of course, that's not really a super hard task (I rewrote the SCI interpreter from asm->C++ for The Realm, it was a pretty mechanical process and it resulted in PMachine.cpp being around only 1800 lines of code)

19

SCI Development Tools / Re: Brackets Bracket and more Brackets errors

« on: January 14, 2023, 12:51:43 AM »

It doesn't look like you have a closing bracket for the (method or the (instance

20

SCI Development Tools / Re: Can method parameters alias temporaries?

« on: November 24, 2022, 01:50:01 PM »

Oh I see. I think that?s largely impractical. There is a lot of Realm-specific C++ code in the interpreter (virtually all of the user interface) that would have to be untangled and separated such that you could use an alternate SCI interpreter. We?re also close to finishing a rewrite of the graphics engine to replace the SCI software drawing routines with D3D, which will help us put more, higher quality stuff on-screen, and relax the palette restrictions that really impede our artwork.

I think it would be good to add networking support to an open SCI interpreter, though, if it doesn?t support it already? Does it run the INN client? Would mostly be useful for hobbyist creators, though.

21

SCI Development Tools / Re: Can method parameters alias temporaries?

« on: November 24, 2022, 01:59:26 AM »

Hmm, I'm not sure I understand how ScummVM could benefit? Or, which part sounds interesting? The main reason for us to do this is to increase the number of available handles to us, but I would expect the existing games to largely fit within the original handle budget. Or is the preservation of int/id type information interesting? Are there many bugs in games that you all are trying to fix?

22

SCI Development Tools / Re: Can method parameters alias temporaries?

« on: November 22, 2022, 04:16:52 PM »

Interesting, thanks. Yeah, no immediate plans to rewrite all of the SCI scripts in C++.

I'm fine with our implementation being more strict - we have the advantage of being able to recompile all of the SCI scripts, and even make modifications to the script compiler itself, so we don't have backwards compat to worry about. So far I haven't made compiler modifications while in this transition period. Had to do some redesign to handle the script fixups.

I also went a step further in my re-implementation, to try and catch more bugs. SCI values carry around type information ('id' or 'int'), and will assert if you try to execute a math op on an id (like op_add), or try to op_send to an int. This extends to all of the kernel functions, too - if we try to fetch an int out of an id, we will crash. In fact, even though the values are 64-bits wide, the int type is still restricted to 16-bit. That's because it's unclear whether loading $FFFF as an immediate should be sign extended as -1 or is meant to be the unsigned int 65535. This will require some script compiler modification to catch all of these cases so we can inspect them all and decide what to do. But I was able to widen handles to be 32-bit and that all seems to function fine, after fixing up a lot of places in the interpreter to not confuse ids with ints.

It's funny you mention planeId because I think that's the one place in the engine where planeId can either be a handle, or just some integer, so it caused a little bit of grief.

23

SCI Development Tools / Re: Can method parameters alias temporaries?

« on: November 22, 2022, 11:31:54 AM »

Ah yes, right, so that's another potential issue, is that temporaries aren't zero-initialized. Would have to check scripts to see if any of them read from temps before assigning to them. Would be an easy runtime check to implement in the interpreter. And again, I wonder if any scripts end up somewhat relying on this behavior.

24

SCI Development Tools / Can method parameters alias temporaries?

« on: November 22, 2022, 12:18:20 AM »

Hi,

I'm one of the developers still working on The Realm, which as you know uses the SCI engine. The PMachine implementation we have was adapted from the 16-bit interpreter to work on a 32-bit machine. All of the SCI values are still 16-bit, but the interpreter itself is written in 32-bit x86 asm.

I recently reimplemented the PMachine in C++ and removed all of the inline asm from our codebase. Further, I widened the SCI values to 64-bit, including the memory manager handles. We often hit the 64K handle limit, so this removes that limitation from us.

In doing so, I believe I discovered a bug in the way that function parameters and temporaries are laid out on the SCI stack, and was wondering if this was noticed in Sierra's implementation, and was just curious to know if this caused any bugs in real Sierra games.

When a method is called, the argc is pushed on the stack, followed by the parameters. After entering the function, if the function uses any temporaries, there is a 'link' opcode at the beginning of the function that indicates how many temporaries the function uses. Now, there isn't ever any validation performed on the number of arguments passed to a function. This is a 'feature', in that all functions are 'vararg' functions, and the &rest feature can be used to forward function arguments along. However - if, say, you have a function that expects 4 parameters, but you only pass 2, this is sometimes expected - SCI scripts can check 'argc' and realize this, and behave differently. But you're also allowed to -assign- to parameters. What I believe might happen, if you have a function that takes 4 arguments, and also declares two temporaries, but the -caller- only passes you two arguments, is that the memory for the two non-passed arguments and the temporaries are at the same location on the stack, and assigning to a parameter will change the value of the temporary, and vice versa.

Just something that came up while I was debugging my rewrite and thought you all would find it interesting.