Community
SCI Programming => SCI Development Tools => Topic started by: EricOakford on November 26, 2018, 10:21:07 PM
-
After a bit of work, here is my SCI01 template game!
I based it off the QFG2 demo, and used the interpreter from the EGA 1990 Christmas Card.
The choice of the interpreter was an important one - it's the last pre-1991 interpreter, and still has its internal debugger on top of that!
11/27/2018 EDIT: I solved the problem with the game not recognizing new words -- SCI Companion thought the parser vocab was 000 instead of 900. To fix this, I went into the version detector and set the parser vocab to 900. Now it recognizes new words!
1/16/2019 UPDATE: The template (https://github.com/EricOakford/SCI01-Template) is now on Github! From now on, you can get it there and make updates to it.
TODO
Work on R44Q SCI01 remake (I can do the scripting, but I can't do the graphics all that well).
-
After a bit of work, here is my SCI01 template game!
I based it off the QFG2 demo, and used the interpreter from the EGA 1990 Christmas Card.
One problem I came across was the fact that when adding new words to the vocab file, the compiler works fine with the new words, but the game doesn't recognize them. A problem with the vocab editor?
Could be a problem with VOCAB.901 ... ScummVM refuses to load the demo at all, complaining about a problem with said resource. Perhaps the reading and subsequent writing by Companion silently exacerbates this somehow. Or more likely, SSCI lets this pass because the parser isn't really used in the demo. Of course if any of this is the case, taking the VOCAB files from a different (SCI01) game ought to work.
-
Nice! Now I gotta migrate KQ2SCI to SCI01. ;)
-
Nice!
Would it be possible to also support the VGA SCI01 version of the 1990 Christmas Card?
That would allow for developing VGA parser based games.
See here for troflip's proof of concept: http://sciprogramming.com/community/index.php?topic=1553 (http://sciprogramming.com/community/index.php?topic=1553)
And some history: http://sciprogramming.com/community/index.php?topic=27.0 (http://sciprogramming.com/community/index.php?topic=27.0)
-
Then we would just need an SCI1.0 template.
-
Then we would just need an SCI1.0 template.
On it.
Edit: aaaand the interpreter is convinced I want the invalid language code -10031.
-
Then we would just need an SCI1.0 template.
Nah, SCI32 is missing too.
-
I wish I could translate assembly. I just cannot do it. I've made a lot of progress modifying KQ5floppy, but I can't alter the Main script for this reason.
-
Redid the thing, up to the point where it broke last time. Made a backup, and a backup of the backup. So let's see what we can whittle off next, hmm?
-
Then we would just need an SCI1.0 template.
Nah, SCI32 is missing too.
Of course, but since Companion does not support anything higher than 1.1, so I was not considering anything higher. Not sure if its compiler would have any issues with 0.1 or 1.0 games, either. As fantastic as it would be to have Companion fully work with and create all SCI versions we cannot count on anything higher than what we have now.
-
I give up. I try to remove all but one of the inventory items, game won't start -- get either an invalid language code (whaaat?) or Oops 4. I don't edit LLinvItem.sc at all and merely recompile it, I get error 4. Which is weird cos I've recompiled all of this several times before?
So I figure I'll go edit rm100.sc instead, turn the polygons into a .shp file so the editor and my &getpoly command can handle them. This after removing events like the cop, clap, cab, and cars. That worked fine.
Oops, error 4.
So fuggit, you figure it out.
-
Here's the new version of the SCI01 template! It fixes a few bugs (such as GetNumber not working properly) and I have gone through most of the system scripts! They now closely match that of the SCI16 scripts (taking into account the SCI01 differences, of course) Everything seems to compile and play fine now.
-
...Maybe I'll try another game...
-
I'm definitely going to look into migrating my KQ2SCI project over to this at some point if the kinks have all been worked out. It's been so long, I can afford to start from scratch on a few things. I really want those moving screen transitions.
-
Eric, I managed to easily convert your template to VGA SCI01.
I created a github repository for it here: https://github.com/OmerMor/SCI01-VGA-Template
Now we can start making parser-based VGA games! 8)
-
:O
-
Y'know what? I think the one thing better than a VGA SCI01 template to make parser-based VGA games in is one that's based on SCI11, considering the different levels of support in SCI Companion and certain runtime stability issues I've noticed when I first hacked The Seasoned Professional.
There's a folder in SCI16-master named NL. It is clearly parser code, but I have little to no clue how to integrate it into SCI11. I could study it a whole bunch and give it my best shot, of course.
The other option depends on the availability of SCI01 source code. After all, if it's already integrated into the one engine, it'd be almost trivial to get it in the other. Okay, maybe not that trivial, but certainly compared to figuring out the NL folder, I'd bet.
-
You're gonna have at least one problem: Where to place the said strings. Remember, the script format was redesigned in SCI1.1; you could place them with the strings and hope that nothing else breaks, but I'm not sure about that.
-
You're gonna have at least one problem: Where to place the said strings. Remember, the script format was redesigned in SCI1.1; you could place them with the strings and hope that nothing else breaks, but I'm not sure about that.
... fffffffuuuu-
I ain't even mad.
-
The other option depends on the availability of SCI01 source code.
Unfortunately I have not managed to get SCI interpreter source earlier than SCI16.
-
I've completed the death handler! Here is the procedure. None of that "Order a Hintbook" nonsense, and all of the Sierra Script.
(procedure (Die message &tmp buttonPressed)
;This procedure handles when Ego dies. It closely matches that of QFG1EGA.
;To use it: "(Die {death message})". You can add a title and icon in the same way as a normal Print message.
(LockEgo)
(curRoom setScript: 0)
(Wait 100)
(SFX stop:)
(music number: deathSound play:)
(repeat
(= buttonPressed
(Print message
#button {Restore} 1
#button {Restart} 2
#button {__Quit__} 3
&rest
)
)
(switch buttonPressed
(1
(if (!= (theGame restore:) 0) (return))
)
(2 (theGame restart:) (return))
(3 (= quit TRUE) (return))
)
)
)
-
You'll probably want to change the code so it accepts far strings at least, or maybe both. Having to put death messages on the heap could become a memory drain if you plan on having as many deaths as usual in a Sierra game :)
-
It's that repeat statement that messes up so many functions, isn't it?
-
It was at one point. I'm not sure whether it still is.
-
One way to find out.
*decompiles QFG1 script 0*Decompiling script 0
WARNING: ::proc0_1: Analyzing control flow: Expected node with two successors (then/else): 1 at 1121
Falling back to disassembly for proc0_1
WARNING: ::proc0_31: Analyzing control flow: Inconsistent then/else branches. Possible "continue" statement?: 1 at 1835
Falling back to disassembly for proc0_31
Generated c:\users\kawa\documents\scicompanion\quest for glory 1 ega\src\Main.sc
Decompiled 60 of 62 functions successfully (96%).
Overall bytecount success rate: 95%.
Fell back to assembly for the remaining functions.And blam.(procedure (proc0_1 param1)
(asm
pushi 0
call proc0_5, 0
pushi 1
pushi 100
callk Wait, 2
pushi #setCursor
pushi 2
lsg global20
pushi 1
lag gGame
send 8
pushi #eachElementDo
pushi 1
pushi 132
lag gSounds
send 6
lag global325
bnt code_10da
pushi #number
pushi 1
push
pushi 63
pushi 1
pushi 15
pushi 87
pushi 0
pushi 42
pushi 0
lofsa music
send 20
code_10da:
pushi 11
&rest param1
pushi 70
pushi 250
pushi 81
lofsa {Restore}
push
pushi 1
pushi 81
lofsa { Restart_}
push
pushi 2
pushi 81
lofsa { Quit_}
push
pushi 3
calle proc255_0, 22
push
dup
ldi 1
eq?
bnt code_110f
pushi #restore
pushi 0
lag gGame
send 4
jmp code_112f
code_110f:
dup
ldi 2
eq?
bnt code_1121
pushi #restart
pushi 0
lag gGame
send 4
jmp code_112f
code_1121:
dup
ldi 3
eq?
bnt code_112f
ldi 1
sag global4
jmp code_1133
code_112f:
toss
jmp code_10da
code_1133:
ret
)
)
-
Here's the actual EgoDead procedure from QfG2:
;*****************************************************
;
; EGODEAD PROCEDURE -- to kill ego off
;
(procedure (EgoDead useRandomIcon &tmp printRet)
(HandsOff)
(Wait 100)
(= normalCursor ARROW_CURSOR)
(theGame setCursor: normalCursor TRUE)
(sounds eachElementDo: #stop:) ; Stop any other music
(if deathMusic
(miscSound
number: deathMusic,
priority: 15,
loop: 1,
play:
)
)
(repeat
(cond
((not useRandomIcon) ; Specfic icon being used
(= printRet
(Print
&rest
#width: 250
#button: {Restore} 1
#button: {_Restart_} 2
#button: {_Quit_} 3
)
)
)
((or (== sillyClowns clownsOff)
(and (== sillyClowns clownsOtto) (not (Random 0 1)))
)
; Give a serious death icon
(= printRet
(Print
&rest
#width: 250
#button: {Restore} 1
#button: {_Restart_} 2
#button: {_Quit_} 3
#icon: vStaticIcons 2 0
)
)
)
(else
(cIcon
loop: (Random 0 1),
cel: 0,
cycleSpeed: (if (== loop 1) 20 else 10)
)
(= printRet
(Print
&rest
#width: 250
#button: {Restore} 1
#button: {_Restart_} 2
#button: {_Quit_} 3
#icon: cIcon
)
)
)
)
(switch printRet
(1
(theGame restore:)
)
(2
(theGame restart:)
)
(3
(= quit TRUE)
(break)
)
)
)
)
-
Just casually drop that procedure in there like no big deal ::)
-
Here is the third release of the SCI01 Template!
Various bug fixes (thanks to my work on R44QSCI, which revealed some scripting errors when changing rooms), more original Sierra names for procedures, and the death message procedure are all here.
-
Wicked.
-
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 (https://github.com/EricOakford/SCI01-Template).
-
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.
-
I must've tried twice but it kept breaking.
-
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 (https://github.com/EricOakford/SCI01-Template).
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 (https://github.com/OmerMor/SCI01-VGA-Template)
The only diff so far is the addition of PALETTE.999 and replacing the interpreter.
-
The VGA version is now in its own branch. (https://github.com/EricOakford/SCI01-Template/tree/SCI01-VGA)
-
Thanks!
-
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.
-
Yes, the saving code seems to be at fault somehow. After saving the game twice in succession I have this in my template directory:
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.
-
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...
-
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...
-
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.
-
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.
-
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.
-
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! :D
-
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! :D
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.
-
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.
-
Why use a demo or minigame at all? The SCI0 template game used LSL3 as a base, IIRC. The SCI11 template game is based on a stripped SQ5. I don't see the issue with basing it on a full game, unless you're just thinking it would be easier to start with less and not have to strip stuff out?
Either way, I'm really looking forward to a SCI1 template game!
-
Okay, I've fixed part of the issue with saving games. Based on what I did for the QFG1VGA decompile, I managed to replace the SRDialog doit with that from SCI16, adapting it for SCI01. Now, the interpreter no longer creates duplicate saves with the same name. But the graphical issue with the menu after restoring a game remains, though. It's probably some kind of buffer overflow.
UPDATE 3/5/2019: And now I've managed to address the graphical issue! What I did was put a space before each menu item in the AddMenus. This was done in KQ1SCI and Codename Iceman.
-
Nice!
-
Quick question. I just opened up the template game and have a question.
There appears to be duplicates of resources, like views. When I rebuild resources, they persist.
I'm not used to this and I don't know if it has advantages, disadvantages, or is completely neutral.
What's the purpose?
-
I assume there'd be a hint in the table view? A bunch of patches lying around would be the most likely.
-
I assume there'd be a hint in the table view? A bunch of patches lying around would be the most likely.
That is the case. Suppose I edit a patch. Will that be a problem?
-
I don't think so. I think it just saves over the patch file.
-
Why use a demo or minigame at all? The SCI0 template game used LSL3 as a base, IIRC. The SCI11 template game is based on a stripped SQ5. I don't see the issue with basing it on a full game, unless you're just thinking it would be easier to start with less and not have to strip stuff out?
In both of those templates, they have clear signs of their origins.
SCI0 had the option of window colors (which is specific to LSL3) and the "Order Hintbook" joke option in the death dialog (again, this is only in LSL2 and 3).
SCI1.1 has SQ5's specific fonts, subclasses, and status code.
My main focus was to make my templates as generic and minimalist as possible, and mainly use the stock SCI resources that can be found in game demos. Since they're officially freely available and have minimal game-specific scripts, it makes perfect sense to repurpose those.
-
Hmm... it seems I'd made a commit a month ago, but I'd forgotten to push it! Oops! :-[
Most of the changes were in the system scripts, thankfully.
The big change here? Support for sorted features! They were used in QFG2.
Now this is as as complete as it can get. Have fun.
-
Nice!
-
A major update!
Going back to the decompiled SCI0 system scripts and comparing them with their SCI01 counterparts using ExamDiff, I have managed to fill in the blanks for nearly every system script. The temp variables and parameters have been identified.
I'd gotten this idea from my recent decompilations of the LSL1, LSL5, SQ1VGA, and PQ3 demos, where I took the extra step in painstakingly identifying all the params and temps I could in their system scripts.
Also, while I'd done this earlier, I'd also created a subclass of InvItem in the main script. This subclass will allow item descriptions to be placed in a Text resource, saving on heap space and simplifying potential translations.
And there you go, the definitive template for SCI parser games is just about complete!
To answer Doan Sephim's question: The reason you see duplicate resources may be because I set the template to be managed as patch files. This is for source control purposes. The interpreter prioritizes patch files over the contents of RESOURCE.000. I have been using Kawa's SCICompanion build.
-
I have been using Kawa's SCICompanion build.
*feels validated*
-
I fixed a major bug in USER.SC, which was the result of a missing line of code!
Specifically, it's in User's said: method, which is supposed to allow the parser to work with verbMessager. So if you were wondering why doVerb wasn't working, this is the reason, and it's been fixed now.
Also, I've made the handleEvent: method in Main a lot simpler, specifically the "look at inventory items" code.
So, if you're using the template, be sure to update your USER.SC file!
-
Insert gif of a happy cheering audience here. I dunno, Colbert's maybe?
-
The game now has specific event handlers for keyDown, direction, and mouseDown events. This will allow for right-clicking on objects to "look" at them. Of course, I had to tweak some of the game scripts to accommodate this. as seen here (https://github.com/EricOakford/SCI01-Template/commit/e0fd67007409e78155bcad0f8821a9619f8e28d0).
I've been working on porting LockerGnome Quest to SCI01 as an example of this. It should be ready soon.
-
Many (most?) SCI0/SCI01 official games had right-click look.
Which LockerGnome? Redux had SciAudio.
-
I really should get sciAudio into Sierra script format.
-
Many (most?) SCI0/SCI01 official games had right-click look.
Which LockerGnome? Redux had SciAudio.
I'm using Redux's code as the basis, with the SciAudio portions commented out and their relevant scripts unused.
I also made the individual objects in the locker into PicViews by carefully removing them from the picture resource, then placing them into a view resource. This is kind of how QFG1EGA and QFG2 drew various non-moving objects as PicViews, rather than making them part of the picture.
In regards to right-click look... I know that QFG1EGA, QFG2, KQ1SCI, Conquests of Camelot, Codename Iceman, and Colonel's Bequest have this.
The ones that don't are KQ4, LSL2, LSL3, PQ2, and SQ3.
With SCI01, putting the mouseDownHandler in the game is enough to enable right-click mode. With SCI0, I need to research this further.
-
I was not discounting your efforts, just noting that it restores a functionality that was in the official games. It is good to have it in or restored the template game.
-
Here's my work on LockerGnome Quest: SCI01 Edition. It has been tested to completion, with the game responding to much of the possible parser commands, and includes a file containing output from the Feature Writer, which has been quite useful for writing the room's features.
And right-click looking was actually not a feature included in the original SCI0 template. That's one reason my templates are a huge improvement. :)
-
Nice. Does it also feature scrolling background transitions?
-
Nice. Does it also feature scrolling background transitions?
Yes. The show styles are in the interpreter, which in this case is 1.000.172 (from Seasoned Professional EGA). This is a newer version than QFG2 and KQ1SCI's interpreters, which also have scrolling styles. It is also the final interpreter version with both EGA graphics and a parser.
-
I'm 99.99% sure I want to migrate my current project from SCI0 to SCI01!
I only have a couple questions:
1. Is the template generally complete? I guess it hasn't been tested a whole lot, so it's hard to say, but I just wanted to make sure.
2. I have the ability to mass extract resources from my project, but is there a way to mass insert resources while keeping all the same resource numbers, etc? Or am I going to have to do that manually? I have, ahem...a lot :)
-
I'm 99.99% sure I want to migrate my current project from SCI0 to SCI01!
I only have a couple questions:
1. Is the template generally complete? I guess it hasn't been tested a whole lot, so it's hard to say, but I just wanted to make sure.
Yes, it's just about complete.
2. I have the ability to mass extract resources from my project, but is there a way to mass insert resources while keeping all the same resource numbers, etc? Or am I going to have to do that manually? I have, ahem...a lot :)
If you're managing resources as patch files, it's just a matter of drag-and-drop. Pics and views are fully compatible. Sounds will need to be converted to SCI1.
-
Thanks for getting back to me!
I don't know much about SCI1 and music. Would something like MT-32 sound work?
Would scripts generally be comparable, or is the syntax in the template skeleton too different from SCI0?
EDIT: I started migrating, but I think it's just going to be too much for me to handle. I'm still fairly amateur when it comes to programming, and having to wade through all the errors and looking through the template for potential answers is a bit tough for me at this time.
I really like the extra heap and other functionality, but I don't think I'm ready to overcome the barrier to entry (relearning new constants/methods/naming conventions/etc.)
-
Why wouldn't something like MT-32 work?