SCI01 Template Game

[Collector]

Now we need an SCI1 template.

I like how you have included all of the drivers and install related files that Brian deleted from his original template game.

[Kawa]

I must've tried twice but it kept breaking.

[OmerMor]

To make it easier for others to update, I've placed the template game at Github. I think it's mature enough for that now.

Here it is.

Moving to Github is great.
Would you like to take ownership on the SCI01-VGA template as well? I already uploaded it to Github: https://github.com/OmerMor/SCI01-VGA-Template
The only diff so far is the addition of PALETTE.999 and replacing the interpreter.

[EricOakford]

The VGA version is now in its own branch.

[OmerMor]

Thanks!

[EricOakford]

It looks like I discovered a bug in the template. When saving a game, then restoring it, certain things in the menu are messed up. Here are some screenshots of the glitchy behavior. Memory leak? Something wrong with SAVE.SC or restoring of a save? These only happen after restoring a game; they don't happen when starting a new game.

Also, when saving a game, then saving another with the same description, it sometimes doesn't overwrite the previous save, but saves a new file instead.

[lskovlun]

Yes, the saving code seems to be at fault somehow. After saving the game twice in succession I have this in my template directory:

Code: [Select]

lars@starfish:~$ ls -l ~/SCI01-Template/SCI01SG*
-rw-r--r-- 1 lars lars 7771 jan 22 05:06 /home/lars/SCI01-Template/SCI01SG.000
-rw-r--r-- 1 lars lars 7884 jan 22 05:07 /home/lars/SCI01-Template/SCI01SG.213  <- BAD!
-rw-r--r-- 1 lars lars   14 jan 22 05:07 /home/lars/SCI01-Template/SCI01SG.DIR
The Sierra SCI interpreter only supports 20 games. Apparently memory corruption can occur if you try to save a game with number 213 I would guess the actual corruption takes place inside the SaveGame kernel call, which does little in the way of error checking (or else one of the other saving-related kernel functions). So the way forward should be to figure out where that number 213 comes from.

EDIT: Also, it may be a good idea to delete your savegame files frequently while investigating this. The mere presence of a file like the above could be a problem.

[lskovlun]

Also, isn't the behavior of saving two games with the same title wrong to begin with? as though something is compiled or decompiled wrongly. I strongly recall being able to reuse the latest savegame slot simply by pressing <F5> <ENTER>. And if nobody changed it knowingly...

[troflip]

I think you can save multiple games with the same title...

From what I recall, the save dialog and the selector control do some weird things with embedding multiple strings in one string (a double-null terminated list of null-terminated strings). That might a place to look...

[lskovlun]

I think you can save multiple games with the same title...

I was referring to the fact that if you press ENTER without changing the title in SSCI, the latest slot will be reused. Quite handy if you need to maneuver ego along a difficult path, for instance. This is somehow different in the SCI01 template, probably indicative of the corruption. Unless it was changed knowingly, as I wrote.

Hmm, trying it again just now, that effect stops after the second save. Curious. And of course ScummVM is no help here, as it handles saving differently.

[EricOakford]

I was referring to the fact that if you press ENTER without changing the title in SSCI, the latest slot will be reused. Quite handy if you need to maneuver ego along a difficult path, for instance. This is somehow different in the SCI01 template, probably indicative of the corruption. Unless it was changed knowingly, as I wrote.

I didn't change anything in SAVE.SC. It was freshly decompiled from Seasoned Professional. Perhaps it got corrupted during decompilation. I saw similar issues in a QFG1EGA decompile. Maybe if the decompiler gets fixed to better handle break statements (so that there's no assembly in the script), we'd be able to easily fix the issue.

[troflip]

I saw similar issues in a QFG1EGA decompile. Maybe if the decompiler gets fixed to better handle break statements (so that there's no assembly in the script), we'd be able to easily fix the issue.

That is unlikely to happen :-)

A more likely outcome is for someone to reconstruct it from the asm, or borrow code from another game that we know works, or use any source code that has been "leaked" for SCI01.

[EricOakford]

Well, I was able to address the issue with the menu glitching up. I moved the restart, quit, and about dialogs to the Main script as procedures. Apparently, Sierra themselves ran into this problem, as this is exactly the way those dialogs are implemented in QFG2.
Also, I've added some fonts from the game demos! 

[lskovlun]

Well, I was able to address the issue with the menu glitching up. I moved the restart, quit, and about dialogs to the Main script as procedures. Apparently, Sierra themselves ran into this problem, as this is exactly the way those dialogs are implemented in QFG2.
Also, I've added some fonts from the game demos! 

I'd say it's quite unlikely that that is the reason the procedures were in script 0 in QfG2. All you're doing is postponing the problem for someone else to find and scratch their head over.

[EricOakford]

I'd say it's quite unlikely that that is the reason the procedures were in script 0 in QfG2. All you're doing is postponing the problem for someone else to find and scratch their head over.

Then I guess I can't think of anything else, unless somebody fixes the Save script's doit.

Now we need an SCI1 template.

I think I'll start work on that. I've got some leads on possible candidates to use as the basis - the demos for SQ1VGA, PQ3, Conquests of the Longbow... but I think the best demo to use would be Ms. Astro Chicken! It has practically the complete set of SCI1.0 system scripts. Also, the icon bar and the control panel are still intact in the game (just partially disabled for the demo), obviously left over from the full version of SQ4.