Messages

1

SCI Development Tools / Re: Copyright state with games created in SCICompanion

« on: January 31, 2026, 03:18:02 AM »

He still uses the PMachine, with only a few more opcodes (some of them also available in SCI11+ for that matter). As I understand it, it is an SCI interpreter running in Unity with extra features bolted on. That's why his personal branch of SCI Companion has things like a particle system renderer that generates view resources.

2

SCI Development Tools / Re: Copyright state with games created in SCICompanion

« on: January 30, 2026, 09:59:52 AM »

Yeah, selling the games would muddy the waters a bunch. With freeware at least you have the excuse that, well, it's free, and it's a 30-something year old system.

Roland may be proactive about their ROMs, but until Sierra or whoever holds the rights at this time start making requests I'd just stick with freeware distribution.

(Besides, you don't need MT32 ROMs to play. Whatcha gonna do, include a copy of Munt? A shortcut to an eBay search for real MT32? I'd say just offer General MIDI and keep the MT32 as a bonus for whoever already has the ability to play that.)

3

Everything-Else / Re: What's up peeps!

« on: January 28, 2026, 08:28:45 AM »

Well, there's one or two features for SCI Companion that've been requested, but I really don't see myself implementing scaler support for the picture editor's fake ego so make of that what you will. I really ought to continue working on my SCI game too, but the only work recently done on that was to begin reworking the you-know-what at the end of the day, while the rest of the game remains unwritten.

I have non-SCI/AGI projects to work on too, but you didn't ask for any of those.

So yeah, it's been a time.

4

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: January 17, 2026, 05:53:52 AM »

I thought the source code of SV was lost and unrecoverable?

True enough. But who was talking about SV?

5

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: January 17, 2026, 05:22:18 AM »

The relevant checkbox has been added to the Preferences dialog box that defaults to "true". Barring unforeseen consequences this feature should be available in the next nightly build.

6

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: January 17, 2026, 03:35:18 AM »

Can't quite imagine how it'd be an issue but it's reasonable and doable.

7

SCI Development Tools / Re: snd to wav ?

« on: January 15, 2026, 05:53:06 PM »

SV, the SCI Resource Viewer. Great tool. Available in Win32 GUI and CLI flavor, and despite the name also works on AGI.

8

SCI Development Tools / Re: snd to wav ?

« on: January 15, 2026, 05:04:52 PM »

SV can do it. In fact...

9

SCI Syntax Help / Re: SCI0 setFlag procedure

« on: January 12, 2026, 10:39:32 AM »

The flag array is just a global, and having more than 16 just means making it an actual array so the memory works out. For the original leaked games, that's defined in game.sh but doesn't use any array syntax. Perhaps SC's global handler couldn't do that... but it does allow enum blocks inside of global. Wow. For us commonfolk, it's all in main.sc's local block which is very confusingly named.

The difference being, SC's global block uses a "name number" syntax and needs to initialize any non-zero values on startup, while our local block (which isn't local if it's script 0) is much more flexible: "name", "name = value", "[arrayName size]", and "[arrayName size] = [values]" are all allowed, but we can't say a given global must be this index.

So if you look at the original LSL1, 3, and 5 code's game.sh, you get stuff like this:

Code: [Select]

gameFlags 111 ; bit flags start at 111 and end at 118.
endGameFlags 118 ; This gives a maximum of 128 (8*16) flags.Followed by an enumeration of flag names, split into groups of sixteen. LSL3 helpfully adds the running global number in a comment to the first of each group.

That is, global111 is gameFlags, while global112 to 117 aren't named at all and can only be accessed as [gameFlags i]. This is effectively identical to having [gFlags 8] in an SCI Companion game.

And as such my own game has this in main.sc: [gFlags 14] ;Start of bit set. Room for 14x16 = 224 flags.... which is way more than I need right now.

There's no further setup needed.

So if your flags break the game when you use one too big, you might want to check if your flags global is big enough to fit that many, as you may be clobbering the next global in the list.

10

SCI Syntax Help / Re: SCI0 setFlag procedure

« on: January 12, 2026, 08:03:24 AM »

Assuming your gFlagArray is big enough (two items for 32 bits/flags) I see no reason why the last two of 19 would break. Of course, I've only gone up to nine myself even though I reserved 224. This requires scientific testing!

Code: [Select]

(procedure (TestFlags &tmp i)
(DbugStr "Clearing 4*16 flags...")
(for ((= i 0)) (< i 4) ((++ i))
(= [gFlags i] 0)
)
(DbugStr "gFlags should be cleared. Checking...")
(for ((= i 0)) (< i 4) ((++ i))
(if [gFlags i]
(DbugStr "[gFlags %d] is NOT zero: %d" i [gFlags i])
(DbugStr "Returning early.")
(return)
)
)
(DbugStr "Setting 32 flags in order...")
(for ((= i 0)) (< i 32) ((++ i))
(Bset i)
(DbugStr "%d = %d" i (Btest i))
)
(DbugStr "Clearing flags in order...")
(for ((= i 0)) (< i 32) ((++ i))
(Bclear i)
(DbugStr "%d = %d" i (Btest i))
)
(DbugStr "Test complete. Now let's see what the log has wrought...")
)

Code: [Select]

Clearing 4*16 flags...
gFlags should be cleared. Checking...
Setting 32 flags in order...
0 = -32768
1 = 16384
2 = 8192
3 = 4096
4 = 2048
5 = 1024
6 = 512
7 = 256
8 = 128
9 = 64
10 = 32
11 = 16
12 = 8
13 = 4
14 = 2
15 = 1
16 = -32768
17 = 16384
18 = 8192
19 = 4096
20 = 2048
21 = 1024
22 = 512
23 = 256
24 = 128
25 = 64
26 = 32
27 = 16
28 = 8
29 = 4
30 = 2
31 = 1
Clearing flags in order...
0 = 0
1 = 0
2 = 0
...
29 = 0
30 = 0
31 = 0
gFlags should be cleared. Checking...
Test complete. Now let's see what the log has wrought...
Ho, isn't that interesting? Btest returns the actual power of two for a set bit, which makes the 16th negative because it's a signed value. Now, it's still a truthy value because only zero is false.

Interesting, but ultimately it doesn't answer the question. I see no dummy guard rail entries in LSL5 at least, though it does say "(presently can't be more than 64)" at the end. Let me re-run my experiment with more than the 32 I did just now. 128 should do... and the result is the same.

11

SCI Syntax Help / Re: solitary vaules in QfGIV changeStage switch statement

« on: January 10, 2026, 04:33:56 AM »

I just tried it myself. A switch instead of an if gave the expected, similar results, just with the PMachine equivalent of a switch.

Code: [Select]

(ListAll
  1 2 3
  (switch gTest
    (0
      ; Left blank for fun
    )
    (1
      4 5 6
    )
  )
  7 8 9
)Always seven values, and the fourth is either 6 or leftovers.

12

SCI Syntax Help / Re: solitary vaules in QfGIV changeStage switch statement

« on: January 09, 2026, 04:33:57 PM »

Just for fun, I replicated the basic premise in isolation:

Setup

Code: [Select]

(procedure (Test)
  (TestHelper
    1 2 3
    (if (== gTest 2)
      4 5 6
    )
    7 8 9
  )
)

Code: [Select]

(procedure Test
  pushi 7 // argc
  push1 // push the first three values to the stack
  push2
  pushi 3

  lsg gTest // push gTest
  ldi 2 // load 2 to acc
  eq?
  bnt nope
  ldi 4 // load to acc, not push
  ldi 5
  ldi 6

nope:
  push // push acc to stack

  pushi 7 // push the rest
  pushi 8
  pushi 9
  call TestHelper 14
)
Result from TestHelper
When the test fails:

Code: [Select]

0 = 1
1 = 2
2 = 3
3 = 0 <-- ?
4 = 7
5 = 8
6 = 9When the test succeeds:

Code: [Select]

0 = 1
1 = 2
2 = 3
3 = 6 <-- !
4 = 7
5 = 8
6 = 9
Takeaways:
1. We try to supply either six or nine items, but only ever push seven values. argc being 7 and the call looking back 14 bytes says as much.
2. If the test fails, we still push whatever is in acc! Values 4 and 5 are wasted.
3. This is not only Technically Valid code, but also even more hilariously broken at runtime than I expected!

13

AGI Development Tools / Re: WinAGI Version 3.0.0 Progress Updates

« on: January 09, 2026, 03:56:30 PM »

If a C# WinForms application does not use any DLL calls ("P/Invokes"), it should work just fine via Mono. You wouldn't even need Wine.

Source: I have made things in C# that have been confirmed to run just fine on Linux via Mono.

14

SCI Syntax Help / Re: solitary vaules in QfGIV changeStage switch statement

« on: January 09, 2026, 12:40:02 PM »

All I have is Larry, and I'm pretty sure they don't.

The first instance with the same intent as the Longbow example would be LSL1 room 320, where the dancers or comedian and drummer are loaded along with the rest. But those are separate LoadMany calls with some distance between them. Same deal in rooms 350, 370, and 390. Then in LSL5 I see similar constructs all over.

If I were to ascribe to the "silly interns" theory, I'd say they misunderstood how sub-expressions (putting an if or switch in the middle of the argument list for OneOf or LoadMany) works. Clearly, Brian K. Hughes, Juan Carlos Escobar, and John Hartin knew what they were doing (except for BKH messing up the Hollywood sign feature in room 190 lol)

15

SCI Syntax Help / Re: solitary vaules in QfGIV changeStage switch statement

« on: January 09, 2026, 05:47:53 AM »

Load all of these, and in this particular case also these? Forget the PMachine, that's a script-level mistake.