Messages

1

The Games and other Sierra Adventure stuff / Re: Rare AGI Games on standard PC DOS

« on: August 05, 2026, 09:41:01 PM »

I just have to reiterate here that the 3.002.097 version of AGI that we have in the source distribution is not "odd" as such. It is a "where"-type interpreter, to be used before the vol files are built. This was a perfectly ordinary dev environment. The "build new vol files every time" that we have now is not what Sierra did. Not in AGI, not in SCI.

2

SCI Syntax Help / Re: Script disposal question

« on: August 01, 2026, 08:39:31 PM »

dispose: is just a method. There is no magic there; it does what it was written to do.

The real magic and the answer to "how come things still mostly work after disposing" is in what the kernel calls do, and I already went through that.

Yeah, but accessing a disposed Script object is only undefined behavior in the case where the Script object is a clone, and it usually isn't. When the Script object is not a clone, this is perfectly well-defined. Which is what I wrote already.

3

SCI Syntax Help / Re: Script disposal question

« on: July 31, 2026, 04:42:48 AM »

dispose: is just a method. There is no magic there; it does what it was written to do.

4

SCI Syntax Help / Re: Script disposal question

« on: July 30, 2026, 04:49:21 PM »

It also depends on whether the script is a clone or not. It is not the usual case - scripts are usually instances for which DisposeClone does nothing. But you can clone script objects in order to use them on several actors, for example. And then there's DisposeScript, which is another thing entirely (but which is also allowed to leave bits and pieces behind in a readable state).

(script dispose:) also has the side effect of resetting some properties, so that the script can be reused later.

5

AGI Development Tools / Re: Getting latest WinAGI studio to work on linux mint

« on: July 26, 2026, 11:15:14 PM »

I would say, as a long-term Linux user, that those OCX's were the most scary things for me. Since I'm more of an SCI guy, I tend to use SCI Compsnion more, and it has a weird effect in Wine, where Companion has this tendency to open panes when any useful action would result. In my case, the code seems to enter into a resize-animate-resize loop, which continues indefinitely.

6

SCI Syntax Help / Re: Stopping IconBar eating mouse events.

« on: July 16, 2026, 04:13:21 PM »

There is a newer decompiler by Sluicebox, which does better. The LSL6 decompilation is here: https://github.com/sluicebox/sci-scripts/tree/main/lsl6-dos-1.000/src

7

SCI Syntax Help / Re: Stopping IconBar eating mouse events.

« on: July 16, 2026, 03:55:12 PM »

Have you looked at LSL6? Does it do what you want?

8

AGI Development Tools / Re: AGI reverse engineering with AI

« on: July 16, 2026, 06:18:02 AM »

The AI work looks interesting, both yours and Peter's, but oh god the terminology is strange (and of course that's because it's working from scratch without the benefit of our collective knowledge).

9

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 14, 2026, 07:44:55 PM »

@pabuslem: The thing is, when we're dealing with the earliest part of the timeline, people don't remember! That the earliest language was called GAL (not AGI), that Arthur Abraham was the lead creator of GAL, and so on. These are things that we (i.e. Lance) have had to dig up ourselves, because the Sierra alumni have forgotten.

10

SCI Development Tools / Re: SCI0: SCI0 Interpreter with added PKWare DCL Implode compression (comp_method=3)

« on: July 13, 2026, 06:28:56 PM »

They had this feature where you could monitor how much hunk was used at any given time. There was also a minHunk= directive in resource.cfg, which was checked on startup. Do some thorough playtesting, and you'll know what to set that value to.

EDIT: but apparently not in SCI0. Sigh, it's been too long since I worked on this.

11

SCI Development Tools / Re: SCI0: SCI0 Interpreter with added PKWare DCL Implode compression (comp_method=3)

« on: July 12, 2026, 08:28:55 PM »

They almost certainly would have on some configurations. I think most SCI0 games required only 512KB of conventional memory? Not everyone had 640KB. And then there's various TSRs.
In fact these games also technically required an 8MHz processor, but I found that they ran passably on our 4.77MHz machine.

12

SCI Development Tools / Re: SCI0: SCI0 Interpreter with added PKWare DCL Implode compression (comp_method=3)

« on: July 07, 2026, 03:46:22 AM »

How much of this memory footprint is in heap, and how much is in hunk?

I don't think I understand the question. The decompressor is not itself a resource, and once uncompressed for use the resources are as big as always. Right?

The buffers can be allocated near (= in the data segment, preventing that space from being used for the heap) or far (= hunk).

13

SCI Development Tools / Re: SCI0: SCI0 Interpreter with added PKWare DCL Implode compression (comp_method=3)

« on: July 06, 2026, 06:57:07 PM »

How much of this memory footprint is in heap, and how much is in hunk?

14

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 06, 2026, 03:22:30 PM »

Sierra had their own rudimentary .EXE file parser. In fact, the GAL version of MAIN.EXE is bigger than those you cite.

30912 bytes according to the directory entry. But the WORDS.BIN file is contained within that, which I had forgotten. That's 3KB right off the bat,. Then you have an object table and a few other things which were separate in later AGI. But they don't amount to much.

15

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 03, 2026, 07:12:13 PM »

Remember that the RAM capacity of typical machines was growing at that time. KQ1 ran in 128K RAM, and was a booter. Even though MAIN.EXE was a .EXE file, it would not run under DOS, because it made assumptions about the memory map that do not hold when DOS is loaded. Sierra had their own rudimentary .EXE file parser. In fact, the GAL version of MAIN.EXE is bigger than those you cite.

By the time AGI ran under DOS, they  could ditch the disk formatting routines, for example. It's not much in terms of size, but letting the OS handle formatting does improve portability. When did they start to write AGI in C? From the beginning?