Author Topic: SCICompanion compile issues with LB2CD  (Read 4994 times)

0 Members and 2 Guests are viewing this topic.

Offline doomlazer

Re: SCICompanion compile issues with LB2CD
« Reply #15 on: October 09, 2025, 10:04:46 PM »
This order switching seems to happen with other files as well. in rm710 ramse_a & ramses_b get flipped, but that seem benign.Here's a list Avo gave me of scripts that seem to do this:

ClickMenu.sco
Gauge.sco
InvI.sco
Lesbian Flapper.sco
Lo Fat.sco
O'Riley.sco
Talking Bear.sco
Main.sco
rm220.sco
‎rm240.sco
‎rm260.sco‎
‎rm280.sco
rm710.sco
rm770.sco
« Last Edit: October 10, 2025, 10:34:50 AM by doomlazer »

Offline lskovlun

Re: SCICompanion compile issues with LB2CD
« Reply #16 on: October 09, 2025, 11:03:06 PM »
Talking Bear.sco
I find that rather hard to believe. Talking_Bear.sco contains only one object, and it's an instance, not a class. It doesn't have a class number of its own. Similar for some of the other talkers.

Offline doomlazer

Re: SCICompanion compile issues with LB2CD
« Reply #17 on: October 10, 2025, 10:37:23 AM »
oops that was a list of files to check for the problem. I assumed they all did as rm710 has the ramses a & b swap.

Offline doomlazer

Re: SCICompanion compile issues with LB2CD
« Reply #18 on: October 10, 2025, 03:53:27 PM »
As I'm looking at the byte code, I notice recompiling might be making some small instruction changes. Like from 0x00 to 0x01 and 0x02 to 0x03. This reference seems to show there are many duplicate instructions that take the same number of bytes as parameters.

Code: [Select]
  op 0x00: bnot (1 byte)
op 0x01: bnot (1 byte)
Binary not:
acc ^= 0xffff;
  op 0x02: add (1 byte)
op 0x03: add (1 byte)
Addition:
acc += pop();

So why all the duplicates? Place holders? 

Offline Kawa

Re: SCICompanion compile issues with LB2CD
« Reply #19 on: October 10, 2025, 04:25:24 PM »
It's like the reference says right at the section you linked: the lowest bit of the opcode byte species the operand size. So an opcode can take either a byte or a word, right? But when it takes no operands like bnot, that just makes both of them do the same thing.

You can tell from ScummVM's interpretation, they take the opcode byte, remember the original value for later, then shift it right to get the final opcode. So 0x02 and 0x03 are effectively both add, sharing a single handler.

What I'd like to know (not really) is when they changed that to having the "duplicates" be error-raising dummies, as seen in the SCI11 source code. That has a full 256 items worth of jump targets. With the above behavior, you might think they could've made do with only 128. But what do I know.

As for minor recompilation code changes in general, I've seen and documented some benign differences before, like "do I push1 (one byte) or do I push 1 (two bytes)?" where IIRC the original SC compiler at the time picked the latter, but SCI Companion picked the former.

Offline doomlazer

Re: SCICompanion compile issues with LB2CD
« Reply #20 on: October 10, 2025, 04:35:30 PM »
I guess it does explain that right in the notes above the instruction list. Makes sense now. ty

Edit: SC also seems to like to replace whitespaces in instance names; such as changing 'Talking Bear' to 'Talking_Bear'
« Last Edit: October 10, 2025, 09:37:18 PM by doomlazer »


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.035 seconds with 22 queries.