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 ... 34
1
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: Today at 06:52:25 AM »
I've made a test harness for SaveGame/GetSaveFiles. The 'prepare' menu option will make 20 saved games, and the two other options print the information returned by GetSaveFiles. After setting the stage in this manner, you can use the ordinary Save/Restore functionality to stress-test the related code. You just dump the attached file in a newly created game, it should be self-contained.

2
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: July 09, 2020, 02:18:31 PM »
@Kawa and I were referring to a fix for escape sequences and the use of '\\' for a path separator in particular. sciAudio wants to create a file in a subdirectory of the main game dir, and therefore failed. It manifested differently in SCI0 somehow.

The thread is here.

The second issue, which may be more relevant, took some digging to find, but it's here. It seems it was never resolved properly, only worked around.

3
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: July 09, 2020, 06:27:55 AM »
@EricOakford had some problems with the saving code when he was doing the SCI01 port a while back. I don't know what came of it, but I think it was some sort of corruption bug. Another corruption bug (or perhaps the same one) came up with his port of sciAudio recently. At least some of that was due to a parsing bug in Companion (didn't like backslashes), which @Kawa fixed.

4
SCI Syntax Help / Re: Old SCI0 Template Save Bug
« on: July 06, 2020, 06:13:20 AM »
I don't think the problem in in this procedure. It just calls save:doit to do the heavy UI lifting, and then SaveGame (a kernel call) to do the actual saving.

5
SCI Syntax Help / Re: Converting sciAudio to Sierra Script
« on: June 24, 2020, 02:26:07 PM »
@Eric: My main concern with that would be not finding the root cause (in the compiler) and therefore still risking problems with local variables elsewhere. The manifestation of such problems would be highly variable (hah) and difficult to diagnose. Also, if everything is in temporary vars (on the stack), there's the risk of stack overflows.

@Kawa: Thanks for looking into this and fixing it!

6
SCI Syntax Help / Re: Converting sciAudio to Sierra Script
« on: June 22, 2020, 08:29:09 PM »
Well, the globals are being overwritten because the compiler is somehow mistaking a local variable (array - msgBuf) for a global one. It happens to be caught early, because userFont gets blown away too and Print needs this.

PART 2:

That was SCI0. Now in SCI01, this problem doesn't occur. Instead, the conductor filename is somehow bugged. The default name contains a backslash, and I've never had to use one before in SCI code. The backslash causes SCI to create a file named MMAND.CON instead of COMMAND.CON. You could sidestep this problem entirely by running SciAudio and SCI from the same directory, or you could try to figure out how backslashes work in Companion's string handling code. Or do it on the ScIAudio daemon side of things (command line?).

7
SCI Syntax Help / Re: Adding a room to Quest for Glory 1 (VGA)
« on: June 21, 2020, 11:06:35 AM »
I have to admit I didn't look at the SCI Companion screen. So there's two issues here: The channel numbers are off by one in comparing ScummVM with Companion, this is purely aesthetic as long as you account for it. The second issue is that the MIDI streams corresponding to each channel are not necessarily the same for every hardware device. You can see this if you pay close attention to where the check marks are in Companion; the two tracks labeled 11 are never active at the same time on the same device. Similarly, channel number 10 is listed at most once in ScummVM per hardware device, but there's one version of it for Adlib/SoundBlaster and one for Tandy/CMS, as can be seen from the offsets. The curious thing is that there is only a control channel (15/16) present for MT-32 (the same one as for all the others).

I don't think this is the bug you're looking for ... unless your setup is an MT-32 or an MT-32 emulator.
In that case, could you try Adlib/SB instead and see if that works?

8
SCI Syntax Help / Re: Adding a room to Quest for Glory 1 (VGA)
« on: June 21, 2020, 05:50:34 AM »
This is the channel list for song 99 as included in my QFG1VGA (from GOG); the ScummVM console window was just barely big enough to screenshot, but I can't see any problems of the sort you describe? But it is clear that some devices have only channel 10, some have both 10 and 11, and some have neither. Which device driver is your SSCI set up to use? You might want to try a different one. What's not working, what do you expect to happen?

Of course, the file could still be bugged in other ways (I can't see from the code that it was used at all? so maybe it was meant for a different SCI version).

9
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?

10
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.

11
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.

12
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.

13
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.

14
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.

15
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.

Pages: [1] 2 3 ... 34

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

Page created in 0.12 seconds with 20 queries.