Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - lskovlun

Pages: [1] 2 3 ... 33
1
The Sierra drivers start with a jump instruction to the entry point followed by a bunch of data. The actual code is near the end of the file.

I haven't tried Ghidra, so I don't know if it needs to be configured in any way to handle these files. Sounds like it's interpreting the data area as code?

2
SCI Development Tools / Re: Decompilation Archive
« on: May 16, 2020, 03:21:04 PM »
If we could convert all of the fan games to Sierra Script then we could dump all of the backwards compatibility stuff and leave Studio and its script in the past.
The linkage system in original SCI was terrible (it involved a text file on a network drive...). I don't thhk I'd prefer it. And if Companion is able to do a build from scratch, then it doesn't matter anyway. Just put *.SCO in .gitignore and be done with it.

But everyone ships those files, so I'm not sure about that.

3
SCI Development Tools / Re: Decompilation Archive
« on: May 14, 2020, 03:31:47 PM »
I think my question was overlooked. :)
Can anyone here please answer?
Back in the old days I had a tool that created (SCI Studio) .SCO files from script files. That's how I created my first SCI games. The main things they gave you that the script files don't have were the names of exports and variables. I think what they mainly give you nowadays (what with the decompiler and everything) is not needing to do full builds all the time.

4
SCI Syntax Help / Re: Problem recreating QFG2 source
« on: May 09, 2020, 05:03:29 PM »
OK, so I've looked at the attached files. There was a transcription error in your original posting; in sag 'with an argument', the argument would get lost. This sequence of files shows that in the originals, the sag/lag parameters are not shown. In the files compiled by Companion, the parameters do show. But this is disassembling, and a very different thing from actual compiling. Also, the Companion files shuffle objects around in a different order than the original compiler. I don't think it's important.

The lofsa/lofss arguments are relative in both compilers (but because of the reshuffling mentioned about the actual numbers are different).

So we don't really learn much from this.

5
SCI Syntax Help / Re: Problem recreating QFG2 source
« on: May 08, 2020, 03:34:59 PM »
I don't think the problem is with script.002-- that's just the first indication I had there was a problem.  If I run my compiled QFG2 in ScummVM with a stock SCRIPT.002, it still trips up on auto-detecting.
The lofsa/lofss autodetection uses script 994 (aka Game.sc) and the Game class in particular. If the methods of that class do not contain even one lofsa or lofss instruction, it'll throw the warning you're seeing. I've no idea how that could happen. A disassembly of that script might help.

EDIT 1: Or whatever version of SCI is used by QFG2... I always thought it was called SCI01, but I'm seeing different naming conventions in the ScummVM code.
Yes, ScummVM needs to make a lot of fine-grained distinctions in versioning but sticks with a relatively small number of version constants. You can try the version command in a debug console to see just how bad it is.

6
SCI Syntax Help / Re: Problem recreating QFG2 source
« on: May 08, 2020, 01:13:26 PM »
(also doesn't ScummVM keep code and heap separate, and warn if someone tries to write to script memory?)
Also, this is more complicated than that. SSCI made the innovation of separating stuff that needs to be in the heap and stuff that's stored in the hunk. At first, this was done at run time, later (in SCI1.1) at compile time. That is why the SCI01 debugger has those 'es:' and 'si:' displays (ES refers to the x86 segment register and points to somewhere in the hunk, SI likewise is an x86 register). SN stands for 'script number'. ES and SN should change at the same time, and if they go out of whack unexpectedly, that's another clue.



ScummVM actually stores the script in one piece (in the case of SCI1.1, the script and heap resources are concatenated and stored in one segment). Local variables get their own segment (one per script file), and there is one segment for clones (dynamically created objects), lists and list nodes.

I agree with the part about relative/absolute addressing being an unlikely cause.

7
SCI Syntax Help / Re: Problem recreating QFG2 source
« on: May 08, 2020, 10:03:32 AM »
The only warning that ScummVM gives me on my compiled code vs stock QFG2 is:
WARNING: detectLofsType(): failed, taking an educated guess!
This has to do with whether the argument of lofsa/lofss is relative or absolute. It is indeed determined before a single line of script code is run.

8
SCI Syntax Help / Re: Problem recreating QFG2 source
« on: May 07, 2020, 08:52:51 PM »
Which line did your comment out? That could be the clue we need.

9
SCI Syntax Help / Re: Problem recreating QFG2 source
« on: May 07, 2020, 06:59:21 PM »
QFG2 is reading it fine until except until the instruction at  00a7
Instead of reading it as sag $10 it reads it as sati $65.
So, sati is $5a, and both $5a and $65 look suspiciously like ascii characters, so your initial idea about memory corruption seems to be correct. The bytes translate to ascii as 'Ze'.... it doesn't appear in the scripts, so perhaps it's the start of your character's name or something?

EDIT: Wait, no it's not... because the opcodes in ScummVM are shifted one place to the right (operand size in the low bit). Sati would then be either $b4 or $b5. I'll need to think more about this. Memory corruption still seems plausible.

10
I'd say that the choice to compile the parser in or out is largely a business decision. It's not like the choice affects the architecture of the rest of SCI much.
Besides the existence or inexistence of Said spec blocks in script resources. Though I think that was only in SCI11...
True enough. I was thinking of SCI1 and the immediate effect of that decision.

11
I'd say that the choice to compile the parser in or out is largely a business decision. It's not like the choice affects the architecture of the rest of SCI much.

12
SCI Development Tools / Re: Extract all `said` strings from scripts
« on: May 06, 2020, 08:34:29 AM »
And I was thinking that parsing this part of the output would be easier:
Code: [Select]
; Obj type #4, offset 0x10b0, size 0x52:
.said
10b4: search , look , examine [ < at , around ] [ / room , area ] [ / !* ]
10d2: cast >
10d6: crawl , duck
10dc: use , force , pull , move
10e8: / wizard , dude
10ef: / frame , painting
10f6: / path , path
10fd: / staff

; Obj type #5, offset 0x1102, size 0x1c8:
.strings
1106: rm220
110c: Fire Wizard:
1119: Water Wizard:
1127: Earth Wizard:
1135: Air Wizard:
(etc.)

13
SCI Development Tools / Re: Extract all `said` strings from scripts
« on: May 06, 2020, 07:33:16 AM »
I wasn't being sarcastic. The package in Trusty worked for me. It was compiled statically and so ran easily. Building from source is another matter, but I think I actually tried a year or two ago, using my age old DARCS repository.

14
SCI Development Tools / Re: Extract all `said` strings from scripts
« on: May 06, 2020, 06:50:06 AM »
(I didn't think I'd be referring to old FreeSCI binary packages in 2020, let alone that there'd be one in Ubuntu Trusty - released in 2014 - and that it would work...)  ::)

15
SCI Development Tools / Re: Extract all `said` strings from scripts
« on: May 06, 2020, 06:32:48 AM »
I'd point you to scidisasm from the FreeSCI package which does this (it works through the script file block by block, so you'd get the said strings in a block of its own). You may be able to extract the files from here:

https://launchpad.net/ubuntu/trusty/+package/freesci

Pages: [1] 2 3 ... 33

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.122 seconds with 21 queries.