SCI engine bugs - an inquiry of sorts

[Kawa]

I'm wondering, since that's what got me to find that other weird thing yesterday, what are some actual engine bugs in SCI that might be worth looking into?

• SCI0 can't draw custom windows the way SCI1 can - Not actually a bug, just a missing feature.
• Window ports cut off Views - even if they're regular SysWindows. That's yesterday's weird thing. Known to happen even in KQ4-88.
• SCI11 Messages: hex numbers in escapes are misread - introduced in .069, the list goes 01234567890ABCDEF. Already fixed in SCI11+.
• SCI11 1.001.100 has a broken pathfinder - not in FPFP (.095) or LSL6 (.113), but ultimately already fixed in SCI11+, which is based on .100.
• SCI11 1.001.100 can't show color 255 in views or backgrounds - might be introduced in .094, which added color remapping but used incorrect logic. Already fixed in SCI11+.

And... that's all I know of from the top of my head. All the rest I can find is script stuff. Anyone else?

[lskovlun]

I'm wondering, since that's what got me to find that other weird thing yesterday, what are some actual engine bugs in SCI that might be worth looking into?

• SCI0 can't draw custom windows the way SCI1 can - Not actually a bug, just a missing feature.

I think we can strike that one off the list, there are other problems with running CB1 under the LSL3 terp (vocab.994 is different).

And... that's all I know of from the top of my head. All the rest I can find is script stuff. Anyone else?

Might I suggest you look at the changelog? Also, every time a new terp was shipped along with a patch, there must have been some problem with the terp by definition. Now some of those would be hardware-specific, but not all.

[Kawa]

1. I wasn't specifically talking about running LB1 under the LSL3 terp, considering a new blank game on 0.000.572 also didn't handle SCI1-style custom windows.
2. I'm mostly looking for things that could apply to 1.001.100, since that's the only terp I have the source for and can build.

Assuming the log is contemporaneous to the INTERP folder, most of the stuff in there should already be fixed by then. If I had a log that goes up to 2.100.002 that certainly might have something though.

Upon checking, Run_Time_System_Changes.pdf goes up to 1.001.097, so just after FPFP and the PQ4 demo... and the entry for .094 reminded me of another bug that's already fixed.

[Kawa]

I'm gonna have to upgrade that thing about color 255.

Did you know, besides not being defined in 999.pal, you can't use color 255 in Larry 6 either? I just made a patch view that adds some splotches in that color to a random easily-seen view and hello what's this then? It came out as transparent! And Larry 6 happens to not have a kernel name vocab.
Indeed, even though Freddy Pharkas' 999.pal does have a pure white 255, it too won't actually show that color outside of system windows, Graph, and text. Anything involving views, which includes background bitmaps, shows nothing for that color, even when the cel's skip color is completely different.

RemapColors was introduced in version 1.001.094. Freddy is .095 and Larry 6 is .113. I'm willing to bet both of them supported color remapping all along, in exchange for that logic error, and simply never used it.

[lskovlun]

The PMachine prev register is stored in a CPU register, at least on x86, and is not protected in any way. This happens to be fine for its one original use (switch statements), but use it for anything else, and you're likely to see its contents destroyed. This is what hit me with the pair code. It was fixed in SCI32 (and in ScummVM).
EDIT: AND of course, I have a patch for that if you want it

[Kawa]

Could you show me that patch please? I can see how to not make it use the cx register for stuff like pprev but the comparison operators got to me.

[lskovlun]

Here you go.

[Kawa]

As usual, it's That Simple. Thanks, I'll merge it in right away.