Messages

1

SCI Development Tools / Re: Is it possible to know selector's type?

« on: January 24, 2022, 07:35:36 PM »

Twenty very specific problematic values out of 64k, assuming there are twenty string literals in the string pool for the script resource currently being decompiled (noting that it only decompiles one script at a time), which includes class names.

I don't math well, but according to this percentage calculator I found, 20 out of 65535 is only 0.03%.

2

SCI Development Tools / Re: Is it possible to know selector's type?

« on: January 23, 2022, 05:44:13 PM »

The script resources are subdivided into a few different blocks, such as local variable storage (including initial values), class and instance definitions, actual script code, a pool of string literals, a pool of said specs, and probably one or two other types I forgot.

The decompiler can tell that the lookStr value is a pointer because it's a fairly high value (same way Print can tell a string literal from a text resource tuple), and it can tell that it's a string because said value matches a location in that resource's string literal pool. By the same token, it can recognize said specs. If it's none of those kind of thing even if it's a sufficiently high value, it's probably an integer constant.

In the later versions with the split SCR/HEP resources, all of those things went into the HEP resources except for the actual script code, which went in the SCR resources, while the said spec block was removed.

Certain later versions of Sierra's compiler allowed lackluster type tagging, where a selector was tagged as an int or an id. I'm not sure how much the compiler actually cared.



And you're right to think it might mistake a value for a string! I'm not sure what would happen and would like to find out. I'll get back to you.

Test results
(= test $02BD) where $02BD is also a string literal's location doesn't break much because that would emit an LDI opcode (Load Immediate), while assigning a string pointer would use LOFSS (Load OffSet to String?) and the decompiler knows what to do here.
However, as I expected, changing one the test room's cardinal exits to $02BD does confuse the decompiler into thinking it's a string.
HOWEVER HOWEVER, changing it to $02BE, just one byte off, made it an integer again! Apparently the decompiler is smart enough to check if it's the very start of a string. So no such risk.

3

AGI Development Tools / Re: LucasFilm development machines ; and some Sierra influence

« on: January 19, 2022, 08:20:07 PM »

I don't know how much clearer I could make it that "deleted" files are just an example of something similar but apparently this wasn't clear enough.

Oh well.

4

SCI Community How To's & Tutorials / Re: Extracting from Macintosh resources?

« on: January 19, 2022, 03:01:24 PM »

From a cursory look at Freddy Pharkas in ResEdit, it seems these are basically the same as in the DOS games, but as Macintosh resource forks. That is, you'll find they contain, for example, "MSG ", "SCR ", and "P56 " resources, with the same numbers they'd have in the DOS version, and some form of compression on each that may be the same as in DOS. Some other things like cursors, inventory items (because at least Freddy has a Mac-specific icon bar), and the sounds you mentioned are stored in a Mac-native format.

5

SCI Community News / Re: "Microsoft to acquire Activision Blizzard" (and Sierra...)

« on: January 18, 2022, 12:19:17 PM »

6

AGI Development Tools / Re: LucasFilm development machines ; and some Sierra influence

« on: January 16, 2022, 08:54:50 AM »

Doesn't need to be a particularly old version of MS-DOS. Or even MS-DOS. Leftover data on disks Just Happens.

For example, deleting a file in DOS is very fast because instead of actually wiping the data, it just sets the high bit in the first character of the file name, marking that entry in the file allocation table as free for reuse. All the other information (until you alter the disk any further!) is still right there, allowing you to undelete the file. This is obviously not what happened with these disks, considering they all have perfectly readable file names, but I feel it'd add a bit of perspective on how easily these things can happen.

7

SCI Development Tools / Re: SCI32 Templates

« on: January 11, 2022, 09:48:52 AM »

It seems like the reason the views tend to be garbled when edited may be related to SCICompanion not properly modifying RESOURCE.MAP.

That's interesting. The more details you can get me and/or Phil, the better.

8

SCI Syntax Help / Re: SCI0 - Pic Size Maximum?

« on: January 10, 2022, 09:04:39 AM »

I'd need an old system to test that on. Though I wouldn't call it stressful; it's mostly just hoping that the raw picture resource fits into memory so it can be rendered into the static screen buffers. The raw resource can then be freed. All that just means the bigger the picture resource (the more commands), the longer it'll take to render.

If my fantasy computer (which runs a 68020 at 16 MHz) can render the SQ3 robot freighter pilot screen (8.43 KB) in less than three seconds using only C code... I would bet actual money that the cave entrance, the new and pretty version, could fit in less than 10 KB if you properly hand-traced it just for the dithering, and render on the same order of magnitude on an old system.

Also, *undue.

9

SCI Syntax Help / Re: SCI0 - How to check if right-click on a control color?

« on: January 05, 2022, 05:42:28 AM »

That's exactly it! Now, if you want to check the same click for a bunch of different colors, you might want to do the OnControl call once, stuff the result in a temporary variable, and then compare that variable against all the different colors.

10

SCI Syntax Help / Re: SCI0 - How to check if right-click on a control color?

« on: January 04, 2022, 02:20:44 PM »

I also tried

Code: [Select]

(if (pEvent onControl: ctlFUCHSIA)and

Code: [Select]

(if (== (pEvent onControl: ctlFUCHSIA) TRUE)But both crash the game because I clearly don't know the proper syntax for this.

It's not a syntax thing, Event has no onControl no matter how you try to invoke it.

What you want to use instead is the OnControl kernel call. Pass it the x and y from your event and you're set.

11

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: December 22, 2021, 08:57:26 AM »

I am ready to make what modifications are needed to build in Unicode support.

If it's .Net, you basically already have Unicode support.

12

The Games and other Sierra Adventure stuff / Re: So You Thought You Were a Hero? Development Journal

« on: December 13, 2021, 12:54:00 PM »

But one drawback to SCI32 is that SCI2 pics do not appear to support controls; where actors can go is determined by polygons instead. For this reason, I will try to only use polygons instead of control colors.

This is true. While later 16-bit SCI merely deprecated the control screen, SCI32 outright removed it and took the vector drawing commands with it. Basically the only drawing command still allowed is Image, which has been extended to also specify a priority level.

13

SCI Syntax Help / Re: SCI0 - Pic Size Maximum?

« on: December 10, 2021, 12:31:12 PM »

So if someone were to play the game on era-appropriate hardware, it would cause a slower load time for that screen?

Absolutely certainly.

14

SCI Syntax Help / Re: SCI0 - Pic Size Maximum?

« on: December 10, 2021, 12:02:29 PM »

It's accurate because it's doing a crap job lol. Sounds like a paradox, but it's true.

But really, what do you expect? For the bitmap importer to recognize line art for what it is? To have an AI take your bitmap and redraw it in proper lines and fills? Get real.

15

SCI Syntax Help / Re: SCI0 - Pic Size Maximum?

« on: December 10, 2021, 11:52:08 AM »

Besides unintended details, the main problem with the bitmap converter is that it doesn't do dithering. Those rocks are painted in dot for dot for dot with individual Pen commands. No wonder the result is absurdly big in storage requirements!

Also, fills. Just plain solid-color fills. Nope, you get lines. And then if the fills aren't solid those lines get a crapton of pen dots on top.

(All of this will also affect load and offscreen-drawing time which might not seem quite so bad on a modern system but oh boy.)