Community
SCI Programming => SCI Syntax Help => Topic started by: lance.ewing on January 02, 2011, 01:07:34 PM
-
I thought I should start a new topic for the discussion we were having regarding the original SCI syntax. It is not good news I'm afraid. Both of the leads I had on getting that SCI code from the Sierra book have come to nothing. Kimme has kindly scanned the code that she thought was SCI code and it is as I suspected, which is that it isn't SCI code but is instead AGI code. It appears that Kimme has exactly the same version of TOBOKQ that I have. As I mentioned earlier, Kimme has also checked Kings Quest Companion 1st and 2nd editions and neither of these had SCI code.
I've also heard back from Dark Fiber and he is now saying that the book with the SCI code in it is the one that he doesn't have but he still says that it exists. I also know that something with SCI code in it did exist at some point. We'll just have to keep searching.
-
Did Dark Fiber mention exactly what book?
-
Did Dark Fiber mention exactly what book?
Hmmm. Yes, I'll have to go back to him again though because it appears he is also wrong about what book it was. He also thought it was The Official Book of King's Quest. Here is what he said:
"Yeah its in the official book of kings quest. If she does not know the difference... but its SCI code. Looks like LISP. Its the book I dont have :( but I know its in there."
The scans I was sent were definitely AGI code though. It wasn't LISP-like at all. It was the very same AGI code that I based a lot of my decisions on when I wrote the SHOWLOG utility back in 95-97 and therefore I guess ultimately what led to the compiler that Peter Kelly wrote.
I still have a vague recollection though that it might have been a Police Quest game that the SCI code was for. I might be wrong about that though. Memories are not the best things to go on. We need something solid.
-
I do have the PQ Case Book. I'll have to take a look through it, if you think it might be in it.
-
I can't stand a mystery like this sitting around unsolved. Although I seem to remember it being from a Police Quest game, there is still something not quite right about this Official Book of King's Quest.
I've just realised that not all first editions are created equal. There can be different printings of a particular edition. The one I'm looking at some scans from at the moment (I have scans from two different people now) is printing 4 of the first edition.
Here are some definitions:
"Strictly speaking, an edition compromises all copies of a book printed at any time from one setting-up of type without substantial change."
A printing [also known as] "an impression compromises the whole number of copies of that edition printed at one time, without the type or plates being removed from the press."
The "without substantial change" is something worth considering here. I wouldn't put it past the publishers to have switched the SCI code for AGI code after one of the early printings. The reason I suggest this is because the text around the AGI code is all SCI related. It talks about SCI classes and SCI concepts. Everything else in the book is SCI related (e.g. screen shots of the original SCI picture and view editors) but the code snippets are AGI!!! It doesn't make sense. Here is a snippet from the book to show what I mean:
"He does this using a special computer language called SCI (SCript Interpreter) developed by Sierra. SCI is an object-oriented language similar to LISP; it's written in Assembler, C, and itself. An older version of the interpreter, called Adventure Game Interpreter (AGI), was used to create King's Quests I, II, and / / / and the 256K version of King's Quest IV. With SCI the programmer establishes classes of objects. The Actor Class, for example, includes anything that moves such as sea gulls, ogres, and Ego. The Props Class is composed of items that move but don't go anywhere
-
The web site is (not surprisingly) Amazon. Here is the link:
http://www.amazon.com/gp/offer-listing/0874551552/ref=dp_olp_collectible?ie=UTF8&qid=1294093206&sr=8-1&condition=collectible
I just tried buying this book but it is telling me that it cannot be shipped to my shipping address. I assume that this is because I live outside of the US. I have sent a message to the seller asking why this restriction is in place because I can't see why a book as small as this cannot be sent overseas. If I have no luck with the seller then someone else in the US is welcome to buy it instead. Remember though that I'm not convinced it will be any different from the printing 4 that I've seen. More than likely it will also have AGI code in it since the same edition should usually be mostly the same. The reason I wanted to purchase the first printing is to completely rule out this book.
-
I used to have a copy of this book (though not the first edition, mine covered KQ4 which was pictured on the back cover). It kills me that I just gave it away a few years back.
-
I used to have a copy of this book (though not the first edition, mine covered KQ4 which was pictured on the back cover). It kills me that I just gave it away a few years back.
Are you sure it wasn't the first edition? The first edition did cover KQ4, in fact all the code snippets and screen shots were from KQ4. What I meant by the book providing evidence that SCI stood for something other than Sierra Creative Interpreter before the release of KQ4 is because the book must have been written at the time that the SCI version of KQ4 was being worked on and most likely before its release. Even though the book was apparently published in Nov 1988, the intro by Roberta was dated in May of that year.
Still haven't heard back from the seller yet.
-
I was working under the impression that KQ4 was not in the first edition. I do recall some code being in there, but I don't remember any details. Either way, the book is gone now...
-
If you recall around mid-December I mentioned the "feature writer" feature in the QFG2 debug mode. I was thinking about this last night and cross referencing it with SCI Companion code syntax. One thing that immediately jumps out is the naming of the classes. In my debug session, I was able to generate a file that contained a basic definition of a Prop, Actor, PicView, View and Feature. These were the actual class names that it generated. If I look inside the Feature.sc script (998) in SCI Companion, the names of the equivalent classes are: Prop, Act, PV, View and Feature. Note the difference in the case of PicView and Actor. What this suggests to me is that classes had both a longer more readable name and perhaps an optional shorter name. It appears that the longer name might be lost during the compilation if a shorter name is provided.
Looking through the system classes in the template game, there are a lot of cases of class names that have been abbreviated/truncated and that I suspect are not what appeared in the original source. Class names such as Blk, Collect, even Obj. The list goes on: Rm, Rgn, SL. CT.
The QFG2 generated source provides evidence in the case of PicView and Actor that there was some amount of abbreviation but it wasn't always used it appears (e.g. View, Prop, Feature). It seems likely then that there was an optional way of specifying that shorter name that would then be used in the compiled code.
-
After playing around with the SCI debugger a bit, I've realised that the Send Stack is another clue as to the original SCI syntax. For example, in the attached screen shot the Send Stack is as follows:
(doorSound check:)
(sounds eachElemenDo:)
(Game doit:)
(SQ3 doit:)
(SQ3 play:)
This appears to confirm the Smalltalk message sending syntax that we discussed earlier, which was:
(object method:)
rather than: (send object:method())
-
As an aside, I've been searching for strings in the SCIV.EXE file and realised that the copyright message contained within this executable seems to reconfirm the original name of the SCI interpreter:
$ strings SCIV.EXE | grep Script
Script Interpreter, Copyright (C) 1987 Sierra On-Line, Inc.
i.e. it was simply "Script Interpreter", which agrees with what Donald B. Trivette says in The Official Book of King's Quest ("SCript Interpreter").
Another string I found in there was "RootObj". Any ideas what this might be? This string seems to be clustered with the rest of the strings that are related to the inspection part of the SCI debugger. So I'm assuming that if I inspect the right thing, it will display the string "RootObj" in some context. Note that this is different from the Obj class. I can inspect Obj no worries. RootObj is not recognised by the inspector, and yet this string exists in the SCIV.EXE file for some reason.
-
I just tried buying this book but it is telling me that it cannot be shipped to my shipping address. I assume that this is because I live outside of the US. I have sent a message to the seller asking why this restriction is in place because I can't see why a book as small as this cannot be sent overseas. If I have no luck with the seller then someone else in the US is welcome to buy it instead. Remember though that I'm not convinced it will be any different from the printing 4 that I've seen. More than likely it will also have AGI code in it since the same edition should usually be mostly the same. The reason I wanted to purchase the first printing is to completely rule out this book.
I still haven't heard from the seller regarding this first edition, first printing and yet it is still up on Amazon for sale and I still can't buy it. If someone out there lives in the states, they are welcome to try buying it.
-
http://sierrahelp.com/forums/viewtopic.php?f=32&t=134&p=26699#p26699
-
Bah, Collector beat me!
-
That's obviously AGI code. There goes that theory then I guess. I assume that he verified it really is a first printing. I might have to ask him.
-
Found this on the Internet:
SCI was Sierra's own advanced object oriented programming language, quite similar to Java. Sierra's programmers wrote scripts for every objects and let objects communicate with each other, to create an interesting interactive gaming-world.
Source: http://colonelsbequest.net/extras/Credits
But Java is nothing like Smalltalk/Obj-C so that's probably a false statement.
Why not write a letter to Al Lowe and ask him, if he remembers what the syntax was like? I know he's still active with his website and will surely reply. Other former Sierra people are probably harder to contact.
-
That's obviously AGI code. There goes that theory then I guess. I assume that he verified it really is a first printing. I might have to ask him.
Uh, the first scan supplied references KQ4 - was KQ4 part of the first printing? I had some thought that KQ4 was introduced later...
-
That's obviously AGI code. There goes that theory then I guess. I assume that he verified it really is a first printing. I might have to ask him.
Uh, the first scan supplied references KQ4 - was KQ4 part of the first printing? I had some thought that KQ4 was introduced later...
KQ4 was the game that the first version of The Official Book of King's Quest coincided with the release of. All of the photos of the editors and the source code is from KQ4.
-
Found this on the Internet:
SCI was Sierra's own advanced object oriented programming language, quite similar to Java. Sierra's programmers wrote scripts for every objects and let objects communicate with each other, to create an interesting interactive gaming-world.
Source: http://colonelsbequest.net/extras/Credits
But Java is nothing like Smalltalk/Obj-C so that's probably a false statement.
Why not write a letter to Al Lowe and ask him, if he remembers what the syntax was like? I know he's still active with his website and will surely reply. Other former Sierra people are probably harder to contact.
Interesting. I think the similarity to Java is in the area of the P-Machine. The Java VM is obviously also an OO P-Machine but SCI predates Java. What is probably more likely is that both Java and SCI are based in part on Smalltalk, which was one of the first (if not the first) languages to compile to an OO pseudo code machine.
-
Uh, the first scan supplied references KQ4 - was KQ4 part of the first printing? I had some thought that KQ4 was introduced later...
KQ4 was the first SCI game, however for the customers with older machines that didn't meet the high hardware requirements for the new interpreter Sierra simultaneously developed the game in AGI. That is the reason that Brian has the screenshots from KQ4 to show the graphical differences between the two interpreters in the SCI Studio help file
http://sierrahelp.com/SCI/SCIStudio3Help/SCI-Overview.html
-
Regarding the suggestion to talk to an ex-Sierra employee, we briefly discussed this on the previous thread:
http://sciprogramming.com/community/index.php/topic,363.msg2026.html#msg2026
I talked to a couple of ex employees that were very helpful but both admitted that their memory is a little rusty. It has been quite some time after all. When these guys were writing SCI code, I was still into GWBASIC and I admit now that I would not be able to write a BASIC app these days without reading the manual again. But they have confirmed the similarity to Smalltalk for message passing and the LISP-like syntax.
-
I guess my main driver for wanting to track down that snippet of SCI code that I believe was previously in the public domain is because of that fact, i.e. it was in the public domain. When I was talking to Brian a month or two ago about SCI Studio, he confirmed that the code syntax in SCI Studio is in part based on the snippet of real code that was around back in the late 90s. He thought it might have been on Dark Fiber's site but in talking to Stuart it seems like that is a dead end. He doesn't have it anymore. The code snippet must have been quite small though because the SCI Studio syntax has made a lot of guesses about things, so much so that one ex employee when shown the SCI Studio syntax said it was definitely not correct. The message passing is the main area that looked wrong.
-
lance,
I found some stuff that might interested. I posted it as a reply in a thread in the Sierra Help Pages:
http://www.sierrahelp.com/forums/viewtopic.php?f=6&t=2102&start=30#p33222 (http://www.sierrahelp.com/forums/viewtopic.php?f=6&t=2102&start=30#p33222)
It has the sci script sample from PQ: SWAT.
-
OMG! That is indeed the snippet of SCI code that I recall seeing over ten years ago. That you very much for that. I can't believe that code segment was on Wikipedia the whole time and I couldn't find it. I spent quite some time trying to come up with magic words to enter in Google in a vain attempt to locate that segment of SCI code. Thanks again. When I get time, I will of course continue this discussion. Now that it has been found, we can talk a lot about the syntax it shows.
I knew it was a Police Quest game. I even suspected it was SWAT. But I couldn't find anything when I was searching for that.
-
Glad I could help!
FYI, the google search I used was:
"police quest" sci code sample lisp
-
I noticed from the history of the Wikipedia page that you were the one that added the PQ SWAT code to the page back in August 2008. Is that correct? If so, do you remember where you got it from? Was it on someone's SCI related web site at that time?
-
That's funny. Only now that you mention it I noticed that it was indeed me who added this snippet. Unfortunately I can't remember where I found it. I guess it was in on eof the SCI sites back in the days.
Maybe I'll give archive.org a visit with some links to old sci sites.
-
This is part of script 325 in PQ SWAT (I have been searching in vain for this as well...) - 40 lines out of roughly 4kloc according to the embedded line number info in the script.
So a short piece of code indeed. It seems quite plausible that it is from some kind of paper publication, and scanned in by whoever posted it in the first place - there are typos in the code that look like the errors OCR software would make (setloop instead of setLoop, setcel instead of setCel, etc.)
There are also arguments against that, however: I can see that the code is unfinished in places (compared to the version of the game that I have), indicating that the
game may have been a work in progress at the time this was leaked. This would make it less likely to be an official publication, right?
Thanks Omer, for finding this!
(btw, I came up with a small piece of code to test that sq5 issue of yours - but you haven't been back to the ScummVM forum for a long time)
-
Thanks for the analysis lskovlun!
re: sq5 - I hang around in the scummvm forums, and I also check regularly github commits to the sci engine of scumvmm. I haven't seen anything relevant - can you point me toward it?
-
I haven't posted it on-line because it is really only for investigative purposes, and it does not belong in the main tree (or as a formal patch).
I imagined we would take care of things on IRC, though I must admit I'm not entirely clear on what the next step is after trying this code.
What it does is it clears the underBits of all cast members during DrawPic... SSCI does not do that, so if this patch helps, that would indicate
a tricky bug somewhere in our graphics system.
-
This is part of script 325 in PQ SWAT (I have been searching in vain for this as well...) - 40 lines out of roughly 4kloc according to the embedded line number info in the script.
So a short piece of code indeed. It seems quite plausible that it is from some kind of paper publication, and scanned in by whoever posted it in the first place - there are typos in the code that look like the errors OCR software would make (setloop instead of setLoop, setcel instead of setCel, etc.)
There are also arguments against that, however: I can see that the code is unfinished in places (compared to the version of the game that I have), indicating that the
game may have been a work in progress at the time this was leaked. This would make it less likely to be an official publication, right?
Thanks Omer, for finding this!
(btw, I came up with a small piece of code to test that sq5 issue of yours - but you haven't been back to the ScummVM forum for a long time)
Hi Lars. I was trying to track you down a few days ago. I tried emailing but not sure if I got the right email address. Is it still the one on your profile page on this site?
-
Hi Lars. I was trying to track you down a few days ago. I tried emailing but not sure if I got the right email address. Is it still the one on your profile page on this site?
Hmm... *checks* no, it's not... *fixes* done.
Should be good now.
-
Resurrecting this old thread...
I took a look at the PQ Swat syntax snippet a bit today:
(instance hitNineShot of Script
(method (changestate newstate)
(switchto (= state newState)
(
(theGame handsOff
(qualProd dispose:,delete:)
(messager say: ALL ALL QUAL-HIT-9-C ALL self 320)
)
(
(++ nineShotCntr)
(qualList dispose:)
(target1 dispose:)
(messager say: ALL ALL QUAL-RELOAD-9-C ALL self 320)
)
(
(if (== nineShotCntr 9)
(Bset fQualifiedSniper)
(curroom newroom: ANGELES-TABLES)
else
(targetl
view: 3329,
setloop: 2, ;One inch target
setcel: 0,
posn: 495 370,
setPri: 470,
init: ((snipeplane casts?) at: 0)ftrlnitializer,
)
(= qualList (List new:))
(qualProd setReal: qualprod 6)
(theGame hands0n:)
(self dispose:)
)
)
)
)
) ;hitNineShot
I know there are some typos in there, and there were a couple of things that left me with questions. I found a copy of Swat and compared the disassembly (using SCI Viewer) with the script snippet and found a few answers.
One question I had was the syntax in this line:
(Bset fQualifiedSniper)
There's no selector colon after like the other statements. It turns out this is a procedure call, so that makes sense (that might be obvious to those familiar with smalltalk too?). Basically it's the equivalent of Bset(fQualifiedSniper) in current SCI Studio syntax.
The other mystery to me was this line:
init: ((snipeplane casts?) at: 0)ftrlnitializer,
What on earth is the question mark? From looking at the disassembly, I think this must just be a typo, and should actually be a colon. It's calling the "casts" selector on snipeplane with no arguments. That returns an object (presumably a list), on which we call the "at" selector with a single parameter 0. The result of that is the first argument to init: Then ftrInitializer is the second. So the SCI Studio equivalent is:
init( (send (snipeplane:casts()):at(0)) ftrInitializer)
-
Another tidbit:
It seems the original language supported a do-until construct (instead of, or in addition to, the do-while construct that Brian's language implements), since I see this pattern:
A: a bunch of instructions
bt B // branch to B if true
jmp A // jump back to A otherwise...
B: more code...
-
Fascinating...it's too bad that there was no one else with the knowhow and interest to delve into SCI other than Brian. I can't help but imagine how much more we could have had much earlier. Can't blame him for losing the will, though.
-
Some more things I found out using the "write cast to file" and "path writer " functionality built into QFG2.
Write cast to file produced output like this:
(instance gate of Actor
(properties
view 290
loop 0
cel 0
palette 1
x 134
y 132
priority 7
signal (| fixPriOn ignrAct notUpd)
)
)
You'll note that the value for signal uses a bitwise-OR operator, and provides three values. So the original syntax supported operators that works on an arbitrary number of values. This is a LISP-like thing. Neither SCI Studio or SCI Companion handle this properly.
The above also provides us with some of the names of the constants that were used (fixPriOn, etc...). Not particularly important.
Using the polygon writer, I generated this file:
;** Path points for picture #100
(local
pts1 = [21 157 89 158 93 165 91 174 80 177 61 179 41 179 18 171]
pts2 = [92 137 95 123 161 116 169 129 149 142 100 142]
pts3 = [131 132 181 154 208 129 167 99 94 103 46 128 104 152 134 159]
pts4 = [159 161 198 150 203 137 177 130]
pts5 = [145 152 114 155 85 150 92 137 128 142]
pts6 = [218 134 131 132 129 104 199 131)
;** The following belongs in the room's init:
(poly1 points: @pts1, size: 8)
(poly2 points: @pts2, size: 6)
(poly3 points: @pts3, size: 8)
(poly4 points: @pts4, size: 4)
(poly5 points: @pts5, size: 5)
(self
addObstacle:
poly1 poly2 poly3 poly4 poly5
)
;** Necessary objects:
(instance poly1 of Polygon
(properties
type: PBarredAccess
)
)
(instance poly2 of Polygon
(properties
type: PBarredAccess
)
)
(instance poly3 of Polygon
(properties
type: PTotalAccess
)
)
(instance poly4 of Polygon
(properties
type: PBarredAccess
)
)
(instance poly5 of Polygon
(properties
type: PNearestAccess
)
)
The main thing here is the array syntax, which is different from the one Brian invented for SCI Studio. Otherwise, I don't think there is anything new. It confirms the pointer syntax Brian used ('@'), and that comments were done with ';'.
Here's another for editing a "freeway" path, whatever that is.
;** Path points for picture #100
(local
ePData = [2 0 0 0
(| PATHSTART SLICK ACTIVE 162) 146 ;** path#0
208 137
194 159
146 163
111 153
145 (| PATHEND 147)
(| PATHSTART SLICK ACTIVE 172) 154 ;** path#1
184 133
189 149
201 157
199 (| PATHEND 129)
0
]
)
Like the first snippet, it shows that you can use expressions in constants. Neither SCIStudio or SCI Companion let you use a '|' operator to initialize arrays or properties.
I managed in activating the feature writer in LSL6 too, and output this:
(instance gregory of Actor
(properties
x 118
y 120
z 8
heading 0
view 200
loop 0
cel 0
sightAngle 40
approachX 118
approachY 112
approachDist 55
_approachVerbs $0
noun eat
)
(method (doVerb theVerb)
(switch theVerb
(else
(super doVerb: theVerb)
)
)
)
)
There's a couple things of note here. The PQ SWAT code had a "switchto" statement, and but here we have a "switch" statement. It's possible they changed the name of the statement by the time SCI32 came along, or it's possible they do different things. In the PQ SWAT code, there were no "case" values for the switchto statement... they were implied (0, 1, 2 ,3 ,etc...). So perhaps switchto just automatically numbered cases, while switch requires explicit cases (we can't tell from the above code, because filling in the doVerb method is left to the programmer).
One other thing to note is the else clause in the switch statement. This suggests that the "default" clause is called "else".
-
init: ((snipeplane casts?) at: 0)ftrlnitializer,
What on earth is the question mark? From looking at the disassembly, I think this must just be a typo, and should actually be a colon. It's calling the "casts" selector on snipeplane with no arguments. That returns an object (presumably a list), on which we call the "at" selector with a single parameter 0. The result of that is the first argument to init: Then ftrInitializer is the second. So the SCI Studio equivalent is:
I think the ? might have been used specifically in the context of requesting the value of a property. I agreed that it seems redundant though and that : could have been used in its place. In fact it doesn't really need either, does it? In Smalltalk syntax, the colon wouldn't have been required (apparently). Read here:
http://www.smalltalk.org/articles/article_20040917_a1.html
"When "getting" a parameter value from an object one simply uses a keyword without the parameter (and colon)."
-
Hmm, interesting, that could be. It looks like, in all the code segments we have (PQ swat, and the feature/poly writer), there is only one place that retrieves a property, and it's that place with the question mark.
So a method call would always have a colon, as would a property set. But a property retrieve would be a ?.
So does this seem right?
(gEgo posn: 35 105) ; set ego position
(gEgo dispose:) ; dispose of ego
(= myVar (gEgo x?)) ; assign ego's x to my var
(gEgo x: 5) ; set ego's x to 5 directly
(gEgo x:) ; this would be a syntax error because x is a property on ego, not a method on ego
Have you given any thought to how handle when selectors themselves are used as arguments/variables? This is the # syntax in SCIStudio:
(self:eachElementDo(#init))
Smalltalk, from what I can tell, uses the # syntax to do that also. So in "original SCI", it would look like:
(self eachElementDo: #init someInitParams)
The problem is what does this look like on the receiving end in the eachElementDo method? The method definition isn't a problem:
(method (eachElementDo aSelector sendParams)
But I'm wondering what the syntax to use the "aSelector" parameter would look like. SCIStudio just uses it directly, but it seems kind of ambiguous. Essentially what it does is this (in "original SCI"-equivalent):
(nodeVal aSelector: sendParams)
The problem comes when you have an actual selector that has the same name as the parameter (e.g. x). Smalltalk would use something like "nodeVal perform: aSelector" (from what I can tell), but "perform" is actually already a selector in SCI which has a different use. I guess I could make up a new keyword? Objective-c has a special "performSelector:" for this.
-
So does this seem right?
(gEgo posn: 35 105) ; set ego position
(gEgo dispose:) ; dispose of ego
(= myVar (gEgo x?)) ; assign ego's x to my var
(gEgo x: 5) ; set ego's x to 5 directly
(gEgo x:) ; this would be a syntax error because x is a property on ego, not a method on ego
Hard to say on the final example, but for the first four, that looks right to me.
Have you given any thought to how handle when selectors themselves are used as arguments/variables? This is the # syntax in SCIStudio:
(self:eachElementDo(#init))
Smalltalk, from what I can tell, uses the # syntax to do that also. So in "original SCI", it would look like:
(self eachElementDo: #init someInitParams)
I hadn't really looked at scenarios like that previously. But after reading your question, I did a bit of Google searching on Smalltalk, and also skimming through the Smalltalk blue book, and I have a feeling that you're probably right. From what I can tell, the #init type of syntax is known as a Literal Symbol, or Symbol Literal, or more specifically a "Selector Literal". This particular wikipedia page is what sold me on the correctness of the syntax:
http://en.wikipedia.org/wiki/Symbol_(programming)#Examples_4
where it has this example:
" same as 'foo' at: 2 "
'foo' perform: #at: with: 2 " => $o "
I'm guessing you might have found the same wiki page given what you go on to discuss in the bit below.
The problem is what does this look like on the receiving end in the eachElementDo method? The method definition isn't a problem:
(method (eachElementDo aSelector sendParams)
But I'm wondering what the syntax to use the "aSelector" parameter would look like. SCIStudio just uses it directly, but it seems kind of ambiguous. Essentially what it does is this (in "original SCI"-equivalent):
(nodeVal aSelector: sendParams)
The problem comes when you have an actual selector that has the same name as the parameter (e.g. x). Smalltalk would use something like "nodeVal perform: aSelector" (from what I can tell), but "perform" is actually already a selector in SCI which has a different use. I guess I could make up a new keyword? Objective-c has a special "performSelector:" for this.
Yeah, I can see the problem. I don't actually know much about Smalltalk, other than what I've been specifically searching for examples of. Have you found any examples of it passing such a "selector literal" to a method? And then using it? I haven't yet set aside the time to work out how a method would be defined in Smalltalk. I learnt Objective-C about 20 years ago, but having not used it since, all of that knowledge has gone. - I really should read that Smalltalk blue book from the start and get a proper understanding of it. Obviously Sierra were designing a new language, so would have been picking up ideas that they liked potentially from several different languages that existed at the time, and like what you're contemplating, they may also have come up with their own thing for such a scenario, particularly given the clash with the "perform" method they'd already defined for different purpose. - So as you say, it's a choice of either going with the SCI Studio syntax, or with your own thing. I doubt though that they would have used performSelector: as a syntax if that particular selector name is not in the selector vocab resource (VOCAB.997)., which I don' t think it is.
-
So as you say, it's a choice of either going with the SCI Studio syntax, or with your own thing. I doubt though that they would have used performSelector: as a syntax if that particular selector name is not in the selector vocab resource (VOCAB.997)., which I don' t think it is.
Yeah, it feels a bit out of place to have a special keyword selector.
What's your opinion on the syntax of switch and switchto statements? From the PQ SWAT code, it's clear they had implied case values (useful for changeStates, where you are often inserting and removing cases, so you don't need to update the case values).
Assuming they use LISP-style syntax for regular switch statements, a switch statement would have cases whose first expression is the case value (i.e. no case keyword is used):
(method (handleEvent pEvent)
(switch (pEvent type?)
(evKEYBOARD
Print("keyboard")
)
(evJOYSTICK
Print("joystick")
)
(else
Print("something else")
)
)
)
This would make it impossible to distinguish implied cases vs explicit cases, hence necessitating a different kind of switch statement for that... this "switchto".
The alternative is to assume switch/switchto are actually the same thing, and a case statement can optionally start with a "case [expression]", or something else, in which case the case value is implied from the previous one (e.g. previous one plus one).
And then there's another question: did they allow "fall throughs" from one case to the next? Brian's SCIStudio syntax doesn't. I suppose it will become obvious once I decompile some more scripts and encounter that pattern.
-
What's your opinion on the syntax of switch and switchto statements?
I think I would have preferred an extra keyword (say, next) and then say
(switch
(next (...))
(next (...))
(next (...))
)
but next was already taken as an identifier by the time switchto came into being.
-
You mean next was already a selector that was being used in existing code, right?
I suppose switchto might have been a later addition to the SCI language then.
-
This would make it impossible to distinguish implied cases vs explicit cases, hence necessitating a different kind of switch statement for that... this "switchto".
The alternative is to assume switch/switchto are actually the same thing, and a case statement can optionally start with a "case [expression]", or something else, in which case the case value is implied from the previous one (e.g. previous one plus one).
And then there's another question: did they allow "fall throughs" from one case to the next? Brian's SCIStudio syntax doesn't. I suppose it will become obvious once I decompile some more scripts and encounter that pattern.
Yeah, I think the name switchto feels more like it was a later addition, as you were also suggesting in your most recent post. For switchto, it does indeed appear that the "case" value is implied, and I'm assuming therefore that the implied values are 0, 1, 2, etc.
Regarding your alternative that the one keyword might have supported both implied and explicit, it seems unlikely to me. The name "Switch To" suggests to me that it is saying "switch to this position" rather that switching to the block whose expression value matches. If that is what switchto implies, then it doesn't cater for a more flexible type of switch, which suggests the existence of the more common form.
But why did they choose to support switchto? Just to save typing in a few digits? I'm guessing that this pattern became so common that they decided to simplify it, ever so slightly.
Your example of the standard switch, where it has an expression as the first value of each block, looks good for that type of switch.
I don't think they would have supported fall throughs using such a syntax. If it does align with a LISP-like switch, then I don't think they'd be let in to a block of code unless the expression matched.
The only bit from your example that looks out of place to me are the Print calls. Something like Print("keyword") should be (Print "keyboard"), to be consistent with the Bset example from the SWAT code that you identified as a procedure call. If you think about it a bit, even examples such as (++ counter) or (+ 2 3) are procedure calls. Anything that is a procedure call, rather than a method call, is likely to follow the same syntax.
-
But why did they choose to support switchto? Just to save typing in a few digits? I'm guessing that this pattern became so common that they decided to simplify it, ever so slightly.
I wouldn't call it a "slight" simplification. If you had designed a large state machine, you would almost certainly have to name the states (if nothing else, to keep the numbers in one place for easy reference). In the cases where you don't need to reference the states explicitly, switchto permits you to skip this step. This makes maintenance (adding and removing things) easier.
-
Hmmm, yeah, I can see how that would be cleaner where all we're doing to the state value is, for example, incrementing it.
-
A few other things I've found out from decompiling scripts (often where my decompiler fails):
It seems that, like LISP, more than one parameter was allowed for comparison operators (in addition to other operators). So to check is an event's message was between 32 and 255 you could have:
(if (<= 32 (pEvent message?) 255)
// do something
)
I also see a lot of code like this:
(if (globalvar0025)
(globalvar0025 dispose:)
)
... but the request to retrieve the globalvar isn't made twice. So it's basically re-using the thing that was tested in the condition, which makes a difference if executing the code in the condition caused side effects (like calling a function might).
In smalltalk, I believe, this might be written something like this:
globalvar0025 ifNotNilDo: [:theVar | theVar dispose:]
But presumably the original SCI had some kind of syntax to evaluate an expression, and then use the result of that expression in another expression, if the expression was true. Any guesses as to what that would look like?
I've also seen a case where an entire switch statement was used as a value to pass to a function (SQ3, script 993). Basically the equivalent of:
(= handle
(switch (paramTotal)
(case 0
FOpen(name 0)
)
(case 1
FOpen(name param1)
)
(default
0
)
)
)
-
The example with the switch statement doesn't look particularly unusual to me. It seems to fit with the LISP-like nature of the language. I agree that it wouldn't make much sense in a language such as Java (which is what I program in for my day job), but perhaps for SCI, where everything in parentheses, i.e. every s-expression, would seem to have a value, it might make sense. That particular example you've shown would seem to make a lot of sense. I'd say that the same type of usage would be possible for the "if" statement as well, and technically and syntactically it is probably possible for things like "for" and "while" as well, but I doubt that there'd be a good reason to write SCI code that calls for that. The code would be cryptic and ugly. But for "switch" and "if", it seems quite useful. Obviously a "switch" and an "if" can do more than execute a single thing that returns a single value, so presumably the switch or if evaluates to the value of the final statement that was executed within the structure. This is exactly how LISP behaves for its equivalent statements. I found a number of references to this behaviour in LISP. Apparently special forms such as "if" and the like are designed to be convenient for use at the top level (so wouldn't normally be used in the way you've discovered them being used), but it is not illegal to use them embedded in other forms. Whether it is meaningful to do so in the context it is used is the real question. The example you've shown is clearly meaningful.
Out of interest, how are you intending to represent an "if-elseif-elseif-else" type of structure? I noticed that LISP doesn't support this with the "if" statement itself. It uses something called "cond" for that. I guess "else if" could be achieved with nested ifs but that might get a bit too nested and ugly.
That observation about the <= operator makes sense. I agree that LISP also supported this. I just tested it on an online LISP IDE. :-)
For the globalvar0025 example, globalvar0025 must be an object given the call to the dispose method. I'm assuming therefore that an object reference can be used as a conditional expression, i.e. if it not yet pointing to something, it would evaluate to false, but if it is pointing to something, then it would evaluate to true. Are you able to copy and paste the byte code for this and a bit either side for context? I probably need to see that to have an opinion on the side effects of it re-using the object.
Btw, I'm fairly sure the FOpen calls would be (FOpen name 0) rather than FOpen(name 0)
-
Out of interest, how are you intending to represent an "if-elseif-elseif-else" type of structure? I noticed that LISP doesn't support this with the "if" statement itself. It uses something called "cond" for that. I guess "else if" could be achieved with nested ifs but that might get a bit too nested and ugly.
I hadn't really though about that yet, but I think that's pretty much covered with switch statements already. Both SCI Companion and SCI Studio support expressions for case values, not just constants (though I haven't seen any evidence of original game scripts using anything but constants).
For the globalvar0025 example, globalvar0025 must be an object given the call to the dispose method. I'm assuming therefore that an object reference can be used as a conditional expression, i.e. if it not yet pointing to something, it would evaluate to false, but if it is pointing to something, then it would evaluate to true. Are you able to copy and paste the byte code for this and a bit either side for context? I probably need to see that to have an opinion on the side effects of it re-using the object.
In Motion::init, in the template game we have:
= theCycler (send client:cycler)
(if(theCycler)
(send theCycler:cycleCnt(0))
)
When decompiling the SQ3 version of Motion::init, my decompiler produced this:
(if (= temp3 (send client:cycler))
(send ERROR_UNKNOWN_OBJECT:cycleCnt(0))
)
... because it didn't find an object being sent to.
If you look at the disassembly, with my annotated comments, you'll see why:
0374:38 00a7 pushi a7 // $a7 cycler
0377:76 push0
0378:63 08 pToa client
037a:4a 04 send 4 // This, and the above 3 instructions are "(send client:cycler)"
037c:a5 03 sat temp3 // This assigns the result of that to temp3
037e:30 0006 bnt code_0387 // This branches on the result of the assignment (which is equal to the thing that got assigned)
0381:39 7e pushi 7e // $7e cycleCnt // sending to the cycleCnt selector
0383:78 push1 // one paramter
0384:76 push0 // which is "0"
0385:4a 06 send 6 // Normally just before here there would be an instruction that puts something into the accumulator.
// Instead it is using what was left from the last instruction that changed the acc (037c:)
My decompiler doesn't (yet) know how to look backwards through branch instructions. And even if it could, I need to figure out what to output for the decompiled source code. In this case, Brian created a temp variable (theCycler) to handle the fact that SCIStudio doesn't support this kind of construct. The original script doesn't have this temp variable.
It's possible the original code used the same constructs as Brian's decompiled code, and Sierra's compiler happened to be smart enough to optimize the temp variable out of the compiled script. I kind of doubt that though, because other parts of the original scripts don't seem particularly "optimized". Like for instance, they have unreachable code, like two JMP instructions in a row (the second is never reachable).
Btw, I'm fairly sure the FOpen calls would be (FOpen name 0) rather than FOpen(name 0)
Yeah, sorry, that was using SCIStudio syntax. I guess I need to be more clear whether each snippet is SCIStudio syntax, LISP, smalltalk, or an attempt at "original SCI syntax". :P
-
Embedding the assignment in the "if" test expression looks okay to me. I think that that would be valid in the original syntax, based on what we were discussing a few posts back. At the same time, Brian's approach was probably valid as well, i.e. having it outside the "if", in fact it would have to be valid if the embedded one works. I wonder whether the compiler would produce the same byte code for both cases? I guess it probably would.
You know, I have a feeling that it actually is a compiler optimization that is causing your problem, but perhaps not the one you've suggested. I don't understand the comment about the temporary variable though. Doesn't the byte code "sat temp3" imply that there was a temporary variable in the original source code? It doesn't seem like Brian created it given the "sat". It's only use appears to be to hold the object ID of the cycler property, which we can assume might in some instances not yet contain a reference to a cycler. The same thing could be achieved like this (using assumed original syntax):
(if (client cycler?)
((client cycler?) cycleCnt: 0)
)
I'm not suggesting that that is better because it probably isn't, and it's obvious from the byte code that the original source didn't look like that since the same send doesn't appear twice. What I'm saying is that it conveys the same thing, i.e. send the cycleCnt message to the client's cycler if the client's cycler property is set. So the temporary variable's only purpose seems to be to avoid the double call to client to get the cycler property. And given this, I quite like the syntax you've already got for it, but obviously with the unknown object being resolved to the temp3 variable:
(if (= temp3 (client cycler?))
(temp3 cycleCnt: 0)
)
Not sure if you've thought about it yet, but in a situation like the above, the temporary variable could be named using the property name as part of the variable's name, e.g. generated like this: tmpCycler, or even clientCycler.
Back to the missing instruction to load the accumulator with a value (presumably from temp3). I don't think it is the temporary variable that has been optimized out given the presence of the "sat". I'm guessing that the compiler stripped out a "lat temp3" because it worked out that the accumulator already had that value. Can the decompiler recognise this scenario? Or would it need to identify and reverse such optimizations before decompiling?
I was wondering over recent days whether a decompiler like this actually needs to almost interpret the byte code as it goes along, for example, pushing things on to stack, keeping track of what value the accumulator currently has, effectively doing what the byte code is saying in order to work out what state things are in at important points in the code, such as this send. Are you doing something like that?
As to the evidence of non-optimized code (such as the double jmp), perhaps it was a compiler option that the individual coder could choose. Maybe if things were getting tight, they'd turn the optimizer option on. Maybe some people did it by default and others didn't. Who knows. I guess we might be able to find evidence for this though. If I get a chance, I might see if I can find something that looks optimised vs something that doesn't. Given their tight constraints back then, they must have supported a few optimizations.
-
I'm not concerned with the assignment in the if. That works, and it's the most obvious result of the decompilation.
And this:
(if (= temp0 foo)
// Stuff
)
would definitely produce different byte code than this:
(= temp0 foo)
(if (temp0)
// Stuff
)
The latter will have an extra lat instruction to load the temp variable into the accumulator for the branch. Both my compiler and, I assume, Brian's compiler do this. With a little work, this could be safely optimized out though. Maybe it's true that Sierra's compiler did that.
I don't understand the comment about the temporary variable though. Doesn't the byte code "sat temp3" imply that there was a temporary variable in the original source code? It doesn't seem like Brian created it given the "sat".
Yeah, that was a bad example. But you can imagine, say, the result of a FGets kernel call or something. The only way to get identical behavior would be to pull the result into a temp variable.
Not sure if you've thought about it yet, but in a situation like the above, the temporary variable could be named using the property name as part of the variable's name, e.g. generated like this: tmpCycler, or even clientCycler.
Yeah, that's a good idea. It shouldn't be too hard to write code to scan for how the variable is used and suggest a name.
I was wondering over recent days whether a decompiler like this actually needs to almost interpret the byte code as it goes along, for example, pushing things on to stack, keeping track of what value the accumulator currently has, effectively doing what the byte code is saying in order to work out what state things are in at important points in the code, such as this send. Are you doing something like that?
I'm doing something like that. It works backwards though. For instance, I'll see a send call, and know that it uses one value in the accumulator, and 2 values on the stack, say. Then I go backwards from there to collect the instructions that produce those values. One current flaw, though, is that the instruction groups are broken on branch boundaries. It's clear I need to change that.
-
Yeah, that was a bad example. But you can imagine, say, the result of a FGets kernel call or something. The only way to get identical behavior would be to pull the result into a temp variable.
Using FGets as an example, can you show me source code to illustrate what you mean?
would definitely produce different byte code than this:
Yeah, I guess if Sierra's compiler was stripping out redundant instructions, then it would be difficult to distinguish between the embedded assignment vs the prior assignment. But in such a scenario, it seems appropriate for the decompiler to use the embedded syntax.
-
Suppose we wanted to read a string from a file, and, if any bytes were read, print out how many were read. In SCI Studio syntax:
= temp0 FGets(strBuffer, 100, hFile)
(if (temp0)
FormatPrint("Read %d bytes" temp0)
)
But in the actual disassembly, a temp variable might not be used. It might be (in pseudo assembly syntax):
callk FGets .... // result goes into accumulator
bnt -> B // if zero, then branch to B, otherwise...
push2 // two parameters to FormatPrint
lofss // push a reference to string "Read %d bytes" to the stack
push // push the accumulator to the stack... this was the result of FGets
calle FormatPrint // print
B: more code...
Which is conceptually (in SCI Studio syntax) the following impossible code:
(if (FGets(strBuffer, 100, hFile))
FormatPrint("Read %d bytes" <the result of FGets>)
)
If I make my decompiler look backwards to see what was last put in the accumulator, and repeat that, I would get:
(if (FGets(strBuffer, 100, hFile))
FormatPrint("Read %d bytes" FGets(strBuffer, 100, hFile))
)
... which has a totally different meaning, since calling FGets a second time will retrieve the next string in the file.
The only way to have equivalent functionality (in SCIStudio syntax) is to create an additional temp variable and store the result.
Clearly Sierra's original code would not have had two calls to FGets (Since that is different functionality). So the only possibilities are:
1) Sierra's original code had a temp variable, and their compiler was able to figure out it wasn't needed outside that particular scenario, and thus optimize it out., or
2) Sierra's original syntax had the ability to say "if this expression is not nil, then do the following code with the expression"
For the purposes of my decompiler, I can probably just duplicate the expression (so the functionality would be wrong if the expression had side effects like FGets), and then tag it with a comment saying to look at this in more detail because it might be wrong.
As for "unoptimized" Sierra code, I just ran across this example in Laura Bow's code for DSelector::advance. Note the 3 jmp instructions in a row. There is no way to reach the second or third instruction, they are pointless.
(method (advance) // method_0637
0637:3f 01 link 1 // (var $1)
0639:35 00 ldi 0
063b:a5 00 sat temp0
code_063d
063d:87 01 lap param1
063f:30 0039 bnt code_067b
0642:7a push2
0643:67 22 pTos cursor
0645:67 1c pTos x
0647:43 66 04 callk StrAt 4
064a:30 002e bnt code_067b
064d:35 01 ldi 1
064f:a5 00 sat temp0
0651:67 22 pTos cursor
0653:63 1c pToa x
0655:02 add
0656:65 22 aTop cursor
0658:67 26 pTos mark
065a:35 01 ldi 1
065c:02 add
065d:36 push
065e:63 1e pToa y
0660:22 lt?
0661:30 0005 bnt code_0669
0664:6b 26 ipToa mark
0666:32 0007 jmp code_0670
code_0669
0669:67 24 pTos lsTop
066b:63 1c pToa x
066d:02 add
066e:65 24 aTop lsTop
code_0670
0670:e7 01 -ap param1
0672:32 ffc8 jmp code_063d
0675:32 0003 jmp code_067b
0678:32 ffc2 jmp code_063d
code_067b
067b:85 00 lat temp0
067d:30 0005 bnt code_0685
0680:39 53 pushi 53 // $53 draw
0682:76 push0
0683:54 04 self 4
code_0685
0685:48 ret
)
-
As for "unoptimized" Sierra code, I just ran across this example in Laura Bow's code for DSelector::advance. Note the 3 jmp instructions in a row. There is no way to reach the second or third instruction, they are pointless.
Yeah, that's certainly pointless. Maybe the compiler did run some optimizations on this byte code and left it in a mess (a working mess, but a mess none the less). I can't see how unreferenced jmp instructions like that could have ended up like that through a normal unoptimized compilation (unless there was a weird bug in the compiler). There's nothing branching or jumping to them. It's really weird. Let's say that something was originally branching or jumping to those locations in the unoptimized code. The optimizer might have seen "oh, it's a branch to a jmp" or a "jmp to a jmp" and altered the first branch and/or jmp to go to the end destination rather than the in between destination. But maybe it then didn't go far enough and strip out the redundant jmps. A bug in the optimizer, or a bug in the compiler. Seems like a bug in something.
Maybe the first step for the decompiler should be to optimize the byte code. :)
-
I can't see how unreferenced jmp instructions like that could have ended up like that through a normal unoptimized compilation (unless there was a weird bug in the compiler).
Yeah, it would have to be dumb code to start with. Like, this would do it (assuming a "continue" statement was supported):
(while (something)
// perform some operations in the loop
continue // jmp back to loop start
break // jmp to loop exit
) // jmp back to loop start
Otherwise, there could have been more complex logic where the continue/break made sense, and the compiler optimized it out.
-
Yeah, the original code must have looked something like that. The language probably did support both continue and break. The second jmp was most likely a break in the original code but I doubt that their original source would have had a continue followed by a break. This is one of the common library classes present in all of the games, right? All of their devs would have seen it at some point and someone would have fixed it if it looked like that.
Regarding the FGets example, thanks for that. I guess that one is a hypothetical scenario, but you mentioned originally that you saw a lot of code that was structured along these lines. Can you find a real example that doesn't make use of a temporary variable in the byte code?
-
Regarding the FGets example, thanks for that. I guess that one is a hypothetical scenario, but you mentioned originally that you saw a lot of code that was structured along these lines. Can you find a real example that doesn't make use of a temporary variable in the byte code?
I don't think I've found that yet. Once my decompiler is working better, I'll be able to decompile large numbers of scripts at once and easily search for all these cases.
-
(instance gregory of Actor
(properties
x 118
y 120
z 8
heading 0
view 200
loop 0
cel 0
sightAngle 40
approachX 118
approachY 112
approachDist 55
_approachVerbs $0
noun eat
)
(method (doVerb theVerb)
(switch theVerb
(else
(super doVerb: theVerb)
)
)
)
)
I was looking back over some of the discussion on the SCI code that can be generated by the games themselves and noticed your example above with the switch statement. I then also saw that your decompile of SQ5 has code in the feature writer n948.txt file that generates code of the same structure, but it appears to include other values for the switch, i.e. for LOOK, DO, and TALK. Did you manage to get it to generate those "case" values?
lofsa " \t\t\t(LOOK^M\n\t\t\t)^M\n"
push
lea @local65460
push
callk Format, 6
pushi 1
lea @temp0
push
call localproc_0714, 2
code_0b3b: ldi 0
lali local80
bnt code_0b5b
pushi 3
lea @temp0
push
lofsa " \t\t\t(DO^M\n\t\t\t)^M\n"
push
lea @local80
push
callk Format, 6
pushi 1
lea @temp0
push
call localproc_0714, 2
code_0b5b: ldi 0
lali local280
bnt code_0b7e
pushi 3
lea @temp0
push
lofsa " \t\t\t(TALK^M\n\t\t\t)^M\n"
-
Ok, I'm able to invoke the feature writer, but it looks like some of the local vars need to be set to certain values in order for it to generate those cases. It also looks like it either generates or reads from a "smh" file to do something. I'll play around with it later...
-
I don't think there's a way to get it to generate the case values without recompiling (and there are things currently preventing me from doing that for this file).
However, we can tell from the code that switch statements look like this:
(switch theVerb
(LOOK
// stuff...
)
(DO
// stuff
)
(else
(super doVerb: theVerb)
)
)
e.g. there is no 'case' keyword. I think that's a new discovery.
As for the shm files, the code seems to read from that file to find the verb that the user entered in the feature writer. But it doesn't seem to do anything with the result (unless my decompiler is generating bad code, which is possible). At any rate, the file is supposed to exist in a msg directory one up from the exe location.
So if the exe was here:
c:\foo\sciv.exe
The shm file would be here:
c:\msg\300.shm
That gives us some insight into their development environment, I suppose.
Based on the code that reads the file, the shm file would appear to be a series of defines, I assume like this:
(define WALK 0)
(define DO 1)
(define TALK 2)
; CASES
-
Here's a question, how easy would it be to add extra interactions? Different games had different interactions and some had more than others. Is it a simple matter to add new ones? Or is each interpreter locked to a certain number?
-
I'm pretty sure it's just a function of the scripts, not the interpreter. I haven't looked into it enough to know for sure though.
-
So it turns out that the entries in the export table don't always match the order that the procedures or instances/classes appear in the script. They will if you just compile with sci studio or sci companion, but they don't in Sierra games.
I spent a while trying to debug a decompiled script (made more difficult because scumm crashes a lot when trying to use its debugger), only to finally realize two objects had been swapped in the export table, and another script was sending a message to "export 5 of script 109", which went to the wrong object.
So Sierra must have had some markup in script to explicitly set the export table entries. I'm trying to figure out what syntax I should use.
Should it be a list of entries at the top of the script? ?.g.
[export(0) = starCon]
[export(1) = sExitSouth]
[export(2) = myProcedure]
Or should it be right before the class or procedure? E.g.
[export = 0]
(Class starCon of Rgn)
Etc.....
I'm kind of leaning towards the first option, because it makes it clear if you're calling these from other scripts.
In either case, these would be optional, and by default it would just use the order they appear in the script.
-
I spent a while trying to debug a decompiled script (made more difficult because scumm crashes a lot when trying to use its debugger), only to finally realize two objects had been swapped in the export table, and another script was sending a message to "export 5 of script 109", which went to the wrong object.
I noticed a bug in the send command earlier when researching Brandon's SQ4 easter egg request. wjp fixed it just yesterday. Or are you referring to something else?
-
If I've been poking around in the debugger for a bit (doesn't seem to matter what I do... Sometimes just breaking into the debugger is enough), when I type 'go' to continue the game, scumm just exits.
-
Should it be a list of entries at the top of the script? ?.g.
[export(0) = starCon]
[export(1) = sExitSouth]
[export(2) = myProcedure]
The "export(0) = " bit seems redundant. Could it simply be a list of the names in the order they appear in the export list? Or does it sometimes have gaps in the numbering, and therefore maybe needs to specify the position?
Also, given that most sections seem to be wrapped in parenthesis, maybe you could just do something like the properties section of a class, e.g. as generated by the Feature Writer:
(export
starCon
sExitSouth
myProcedure
)
Or if we go down the route of specifying the position, it could exactly match the properties section generated by the Feature Writer and look like this:
(export
myProcedure 2
sExitSouth 1
starCon 0
somethingElse 7
)
Out of interest, where does the name export originally come from? Is this something mentioned only in the SCI specs? Or does the interpreter mention this name somewhere? Recently we were talking about public classes, public procedures, etc. so "public" could be another name to use.
-
Ok, I'm able to invoke the feature writer, but it looks like some of the local vars need to be set to certain values in order for it to generate those cases. It also looks like it either generates or reads from a "smh" file to do something. I'll play around with it later...
The SHM files are related to the message resources. There is one included on the GK2 CD (by accident, clearly).
-
The "export(0) = " bit seems redundant. Could it simply be a list of the names in the order they appear in the export list? Or does it sometimes have gaps in the numbering, and therefore maybe needs to specify the position?
There are gaps. And some exports can appear multiple times. So maybe something like this:
(exports
0 starCon
1 sExitSouth
2 somethingElse
6 myProcedure
7 myProcedure // duplicate export that appears in some games
)
Out of interest, where does the name export originally come from? Is this something mentioned only in the SCI specs? Or does the interpreter mention this name somewhere? Recently we were talking about public classes, public procedures, etc. so "public" could be another name to use.
I don't think the interpreter mentions it anywhere. Exports is what they are called in SV.exe, ScummVM, and the specs on the wiki. "public" is also a keyword, so I don't want to re-use that or something similar. Although admittedly it's redundant.
If I had to guess, I'd say the original Sierra syntax didn't have the "public" keyword, and that there was a separate section of script that mapped export slot to proc/class name.
-
The SHM files are related to the message resources. There is one included on the GK2 CD (by accident, clearly).
Do you or anyone else have a copy of that shm file? I'd be curious to see what it represents, what's inside it.
On an unrelated note, just for kicks, I've attached the decompiled code for QFG3. It only takes about 10 seconds to decompile a game now (down from 10 minutes), so if anyone has any request, let me know.
-
Do you or anyone else have a copy of that shm file? I'd be curious to see what it represents, what's inside it.
Just a bunch of defines, really (mapping nouns, verbs and cases to the numbers that SV displays). Interestingly, Sierra used the Message technology for KQ8 - to the point that KQ8 (which wasn't SCI) includes a header file (TALKERS.SH) with SCI-syntax defines in it (again, by accident):
http://kingsquest.wikia.com/wiki/KQ8_development (http://kingsquest.wikia.com/wiki/KQ8_development)
The guys behind that page didn't think to use SV on the message files in KQ8. I have, and it works :)
EDIT: Not quite by accident... the KQ8 binary actually loads and parses this file (there's a VERBS.SH file too)
-
I was wondering if someone has done an exhaustive search across as many later SCI games as possible for scripts that generate SCI source, such as the Feature Writer? Troflips find with the "switch" keyword was great. I'm wondering if Sierra continued to expand on the in-game code generation tools as time went on, and therefore whether we might find some gems like that in later games that might reveal more. Even if we couldn't decompile the later games yet, maybe a search across all uncompressed text for patterns that look suspiciously like source code might reveal something. I wonder how far they took these in-game code generation tools.
-
Just a bunch of defines, really (mapping nouns, verbs and cases to the numbers that SV displays). Interestingly, Sierra used the Message technology for KQ8 - to the point that KQ8 (which wasn't SCI) includes a header file (TALKERS.SH) with SCI-syntax defines in it (again, by accident):
Hmm, if there's a talkers.sh and a verbs.sh, I wonder what the %d.shm files were for then?
I guess the nouns are unique to each room, but talkers are not? What about if a noun and a talker refer to the same thing, do they end up using the same name in the defines?
What are "cases"? Is that the "condition" property of a message?
The numbers used for "verb" appear to be flags (i.e. powers of two, 1, 2 ,4), but not always. Is there any significance to that?
-
Hmm, if there's a talkers.sh and a verbs.sh, I wonder what the %d.shm files were for then?
I'm guessing there was a provision in the message editor for marking stuff local or global.
Which reminds me, it is possible to store comments for each message in a MSG file, but I never found a reliable way to get at them; we didn't need to for the purpose of running a game.
I guess the nouns are unique to each room, but talkers are not? What about if a noun and a talker refer to the same thing, do they end up using the same name in the defines?
Here's how the process goes for playing a long dialogue in SCI: You start out with a noun/verb/case triple which identifies the dialogue uniquely. Sequence is set to 0. Then we loop over the sequence numbers, and for each message, we get the talker value (returned by the Message/GetMessage subfunction 0). We feed that talker value into the findTalker method of a "messager" object (in the main script), which translates the talker value into a reference to a talker object. We then let that talker object handle the portrait display and animation. Increment the sequence number, and repeat.
So noun and talker values live in different namespaces, there is no risk of a clash. Similarly for verbs and cases.
What are "cases"? Is that the "condition" property of a message?
Conditions and cases are the same thing. Both words were used at various times.
The numbers used for "verb" appear to be flags (i.e. powers of two, 1, 2 ,4), but not always. Is there any significance to that?
I haven't noticed this. Looking at 0.MSG in SQ5, it has 5, 1, 24, 7... where are you looking? (yes, there is some translation going on in the code, for the approachVerbs property and perhaps in other places)
-
I see, so items in the msg resource need to have a unique [noun, verb, case] tuple.
So looking in the cliffygoeswith.sc of SQ5, I see
(send gTestMessager:say(22 0 43 0 self))
22 is the noun, 0 is the verb, 43 is the condition. Following the code, that looks like it turns into:
Message(msgGET roomNumber 22 0 43 0))
which will return the talker, in this case 19 for both sequences of this thing.
main.sc has a big case statement for resolving the talker based on this number. For 19, looks like it uses export 15 of script 240, which is tkrRoger.
As for the flags thing, yeah, I just noticed that 0, 1, 2 and 4 were often all that were used in a msg resource. But there are other numbers too, so I guess it's just a coincidence.
_approachVerbs does look like flags though. Looks like they have a hard-coded subset of verbs that get turned into flags, in order to be able to "store" multiple verbs in that property.
(method (doit param1)
(switch (param1)
(case 1
1
)
(case 2
2
)
(case 3
4
)
(case 4
8
)
(case 31
16
)
(case 24
32
)
(case 29
64
)
(case 25
128
)
(default
-32768
)
)
)
-
Do you or anyone else have a copy of that shm file? I'd be curious to see what it represents, what's inside it.
Here.
On an unrelated note, just for kicks, I've attached the decompiled code for QFG3. It only takes about 10 seconds to decompile a game now (down from 10 minutes), so if anyone has any request, let me know.
How about Freddy?
-
Thanks!
And in return, here's Freddy...
-
Actually, I'm quite interested in KQ1SCI, if possible. Might help me with some things I'd try to replicate in KQ2SCI, if I even pick it up again...
-
Here you go...
-
Thanks. Was the Freddy the floppy or MPC version?
-
Thank you!
-
Thanks. Was the Freddy the floppy or MPC version?
The interpreter is version 1.cfs.081, if that helps.
-
That is the DOS interpreter for the floppy version. The reason that I ask is that there is a fatal bug in the MPC version. I didn't know if I could track it down or not. I am not sure if it exists in the floppy version or not.
By the way, if there are any files you need from any of the games I could supply almost anything for you. Just let me know.
-
Well, any of the *.sh or *.shm files that accidentally shipped with games would be useful (like the one you already provided). I hadn't thought much about how to let the user edit messages, but I may as well use the same system Sierra apparently did. e.g. both the editor and the script will pull the message-related defines from the *shm header files, and the editor will also push new values into there. And then I guess I'll have a global talkers.sh that is included by the game.sh, and edited manually by the user.
What does "MPC" refer to?
-
What does "MPC" refer to?
Multimedia PC (http://en.wikipedia.org/wiki/Multimedia_PC), i.e. the CD-ROM version.
-
Omer is right. Sierra had the MPC logo emblazoned on all of their CD-ROM talkie games at the time.
I ave never paid any attention to the sh shm files before, but will take a look to see if I have any more.
-
Here's the content of 220.SHM from the DOS demo of Freddy Pharkas:
; 220.SHM -- Produced by SCI Message Editor 4.211
; This file should only be edited with ME
; NOUNS
(define ANVIL_N 26)
(define BALANCE_N 22)
(define BANKDOOR_N 28)
(define BANK_N 16)
(define CANT_GO 1)
(define CORRAL_N 17)
(define FENCE_N 21)
(define FIREPIT_N 24)
(define HORSE_ON_BLOX_N 2)
(define RAIL_N 20)
(define SADDLE_N 18)
(define SIDEWALK_N 27)
(define SMITHIE_N 14)
(define SMITHY_N 15)
(define STREET_N 23)
(define TROUGH_N 19)
(define WAGON_N 25)
; CASES
; After you've removed the mole from Smithie's face, but if you haven't left the room yet
(define AFTERMOLE 6)
; (After the Smithie has left)
(define AFTER_GONE 7)
; While the fire is going and Smithie's working
(define FIREGOING 3)
; Once the fire is out and Smithie's gone.
(define FIREOUT 4)
; If you click on any part of Smithie's body EXCEPT his face (or whenever his back is turned)
(define NOTONFACE 1)
(define NO_MORE_CHAR 8)
; On Smithie's face, while he's facing you
(define ONFACE 2)
; When Smithie still has the mole on his face.
(define WITHMOLE 5)
-
I just searched my SCI games and all I found were those two. If I understand it we would not expect it to be found in the resource archive, right?
-
I'm not sure what the resource archive is, but those two files were useful, thanks guys! I see they used a different naming convention for nouns and cases for those two games.
-
By resource archive I was just referring to the RESOURCE.00* files where all of the resources are stored. Is there any other internal name or reference that indicates what Sierra called it?
-
Oh, sorry for the misunderstanding... I just call them package files or volume files.
No, these shm files are not resources, and the game doesn't need them to run. They're essentially bits of the original source code, which is why they're important. It would be cool if something other than just header files got accidentally shipped with any of the games - though I'm sure we'd know about it if that had happened.
-
So these would be the equivalent of C/C++'s *.h files?
-
So these would be the equivalent of C/C++'s *.h files?
Yes. They are header files giving symbolic names to the numbers found in the corresponding MSG file. And the .SH files are actually parsed by KQ8, as previously noted.
-
Does KQ8 actually depend on them for the game to run? Some of SCI1.1 games load and parse these files too, but only for the debug features that were left in.
-
Ohh, could I also request the SQ3 source? There's some code in that game I've been curious about.
-
Here are the MoE SH files
-
I was wondering if someone has done an exhaustive search across as many later SCI games as possible for scripts that generate SCI source, such as the Feature Writer? Troflips find with the "switch" keyword was great. I'm wondering if Sierra continued to expand on the in-game code generation tools as time went on, and therefore whether we might find some gems like that in later games that might reveal more. Even if we couldn't decompile the later games yet, maybe a search across all uncompressed text for patterns that look suspiciously like source code might reveal something. I wonder how far they took these in-game code generation tools.
Script.21 in Space Quest 6 looks interesting. It appears to reveal an additional bit of original syntax:
lofsa string_047a ; " (super init: &rest)\r\n"
There is other code in the script as well, but I think an example of the use of &rest is something new. This obviously relates to the &rest op code, but what is interesting is that it appears to show that they also had the & in front of "rest" in the original source.
-
SQ3 source code attached. There were some problems in script 18, looks like there is some bad code in there (or else my version of SQ3 is corrupted or something). RadarScript::changeState branches to offset $c000, which is way out of code range. Interestingly, script 0 also has an invalid export $c000. Curious...
collector, thanks for the .sh files!
So maybe I'll standardize on having _V, _N and _C suffixes for the verb, noun and cases.
-
I'm also wondering about this from Script 18 in QFG4:
lofsa string_0536 ; "[egoStats i] is %d"
I realise this isn't source, but rather is a debug message. It's a strange way of referring to an item in an array though (if that is what it is doing). Why not say :
"egoStats[i] is %d"
It hints at some connection with the original source.
-
Good find on the &rest thing. I think more interesting than the ampersand is the fact that rest doesn't take any parameters. In SCIStudio it takes a parameter that means "from this parameter and on". Does that script have the method signature text in it too? What does it look like?
-
Thank you. :)
-
Good find on the &rest thing. I think more interesting than the ampersand is the fact that rest doesn't take any parameters. In SCIStudio it takes a parameter that means "from this parameter and on". Does that script have the method signature text in it too? What does it look like?
These are all the strings related to the source generation code in that Script:
string_03b9 = "%d.fea"
string_03c0 = "Output File Name:"
string_03d2 = ";***************************\r\n"
string_03f1 = "\r\n"
string_03f4 = "(instance "
string_03ff = " of Feature\r\n"
string_040d = " (properties\r\n"
string_041c = " x"
string_0420 = " "
string_0425 = "%d"
string_0428 = " y"
string_042c = " sightAngle 40\r\n"
string_043e = " noun\r\n"
string_0447 = " )\r\n"
string_044c = " (method (init)\r\n"
string_045e = " (self setPolygon:\r\n"
string_0474 = " )\r\n"
string_047a = " (super init: &rest)\r\n"
string_0492 = ");"
string_04e0 = " ;********************\r\n"
string_04fa = " (curRoom addObstacle:\r\n"
Maybe in this case, &rest without anything after it would mean from the first parameter, i.e. all of them? They'd still need the additional starting parameter when starting from a parameter different from the first, otherwise I'm not sure how this syntax would cope with that case.
From these strings, it would seem that the "(super init: &rest)" call is within a method defined as "(method (init)", so apparently doesn't have any defined parameters. So I guess this means it could take some unknown number of parameters and it would pass them all through to the super init, which in this case would be the Feature init. I guess therefore that the parameters passed to this init would need to match what Feature init is expecting.
-
Well, yes, they need to match. In general, without a parameter supplied to it, I'd guess it would just pass all the parameters after the last named parameter in the signature (in this case there are no named parameters).
Given that sci studio allowed you to specify from what parameter onward was passed (which mirrors the &rest opcode), I'm just wondering if there is ever a scenario where a function passes anything other than the parameters after the last one it uses. I.e. Maybe there is no need in source code for the argument used with the rest statement.
-
That's a good point. Technically the original source shouldn't need to specify what parameter to start at, since they'd be able to refer to the named parameters for those ones, then follow that by &rest for the rest. I suppose it is possible that they might want to skip the first couple of the unnamed parameters, but that would be a bit strange. It would imply that they do know what's in that parameter list, so why not name them all?
I guess that if we can find an example where the compiled byte code for a method or procedure refers directly to parameter numbers up to a certain number (e.g. let's say 4) but then it has a &rest instruction that starts at a lower number, e.g. 2, then that might answer the question.
-
I think it will be difficult to spot something like this manually. It occurred to me that you could probably add a throwaway piece of code in to your decompiler to solve this problem. For every method or procedure it decompiles, if it encounters &rest, then it subtracts from the number after &rest the max param number that it encounters in the same method/procedure. If the original source always had &rest with nothing after it, then we'd expect the result to always be 1. All you'd need to do then is run a few games through your decompiler and see if this ends up being the case. I have a feeling that your theory is correct and that it will always be 1.
-
Thinking about that a bit more, I wonder if you might get something other than 1 if the last named parameter is an array. I haven't looked to see how array parameters affect references to parameter by number.
-
Yeah, it was quick to detect this in the decompiler. Out of over 1000 uses of rest, the function that uses it only refers to parameters below the rest index.
So this is pretty good evidence to support that &rest never took a parameter name in Sierra's source code. It just referred to all the remaining unnamed parameters that were passed to the function.
-
Yeah I agree from that result that it seems like it was the case.
-
This is a full example generated by the Space Quest 6 debug mode, showing the context of that (super init: &rest)
(instance sitDownGame of Feature
(properties
x 88
y 117
sightAngle 40
noun
)
(method (init)
(self setPolygon:
((Polygon new:)
type: PTotalAccess,
init: 27 123 42 135 132 135 139 129 150 126 151 123 151 109 137 100
90 100 59 108 41 108 26 116,
yourself:
)
)
(super init: &rest)
)
);sitDownGame
I've had a look over a number of other newer SCI games but can't see anything new on top of what we've already discussed in this thread.
-
Yeah, doesn't look like anything new. The noun property has no value associated with it, but I assume that's because the .shm file is missing.
Regarding some of the decompiled scripts where we see evidence of bugs in Sierra's source code - specifically, assigning multiple values to a property like so:
(self:
view(233 x 199) // Clearly this was supposed to send 233 to view, and 199 to x
y(86)
)
... I think this can give us some clues regarding Sierra's original syntax. From what we know, the proper code would have been:
(self view: 233,
x: 190,
y: 86
)
... and we know the following code would give the result we actually see in the script resource:
(self view: 233 // missing comma
x 190, // missing colon
y: 86
)
.. but that requires two typos to be made, which I think is unlikely?
I wonder if the original code looked like this:
(self view: 233 // just a missing comma
x: 190,
y: 86
)
I dunno.. it seems that would be a pretty easy syntax error to detect. Maybe it was considered valid syntax to refer to a property on self like that?
-
WOW does all this discussion really infuriate me all over again that CUC/Cendant Publishing or whoever bought out Sierra at the time simply and unceremoniously threw out all the source code for these games into a dumpster.
-
This is part of script 325 in PQ SWAT (I have been searching in vain for this as well...) - 40 lines out of roughly 4kloc according to the embedded line number info in the script.
So a short piece of code indeed. It seems quite plausible that it is from some kind of paper publication, and scanned in by whoever posted it in the first place - there are typos in the code that look like the errors OCR software would make (setloop instead of setLoop, setcel instead of setCel, etc.)
There are also arguments against that, however: I can see that the code is unfinished in places (compared to the version of the game that I have), indicating that the
game may have been a work in progress at the time this was leaked. This would make it less likely to be an official publication, right?
Lars, I was taking a look at script 325 in PQ SWAT this morning and I can see what you mean about the source being quite different (perhaps unfinished) when compared to the compiled version. It may still have been an official publication, but as you say, maybe it was just a work in progress at the time, or perhaps deliberately altered for publication. Are we sure there is no other hitNineShot in PQ SWAT? I haven't yet checked every Script, so not sure myself yet. - If it was published in a book/magazine (which for some reason my memory seems to recall that whoever found it stated was the case), then this is still one of those unsolved mysteries. It would be great to track down an actual image of the page that this appeared on. When I asked Brian about it a few years back, his memory was vague, but he thought it might have come from Dark Fiber. When I asked Stuart he thought I was talking about the code in the Official Book of King's Quest, which is obviously KQ4 AGI code (and we confirmed a few years back that no edition of that book contained SCI code), so it didn't ring any bells with him.
So it's still a mystery where the PQ SWAT code came from and one that would be great to track down.
-
... and we know the following code would give the result we actually see in the script resource:
(self view: 233 // missing comma
x 190, // missing colon
y: 86
)
.. but that requires two typos to be made, which I think is unlikely?
I wonder if the original code looked like this:
(self view: 233 // just a missing comma
x: 190,
y: 86
)
Yeah, I see what you mean. It could have been either one of those scenarios that resulted in the compiled code you're seeing, but in the second example, the colon seems like an invalid character for inclusion in a value.
For me, I've always wondered why they needed to use the commas. What I've read about the smalltalk keyword message syntax, it doesn't make use of commas. So the above example could instead have been simply this:
(self view: 233
x: 190
y: 86
)
Even if they had multiple values for a parameter, the colon still seems to be enough to distinguish the selector name from the value. But from what we've seen in the Feature Writer generated source, and the PQ SWAT snippet, I guess we have to assume that for whatever reason, they needed the comma.
Could it be that the comma was mandatory but the colon was optional in their version of keyword messaging? e.g. maybe this would have been valid (because the comma is the main delimiter in their case):
(self view: 233,
x 190, // Missing colon
y: 86
)
-
That is the DOS interpreter for the floppy version. The reason that I ask is that there is a fatal bug in the MPC version. I didn't know if I could track it down or not. I am not sure if it exists in the floppy version or not.
By the way, if there are any files you need from any of the games I could supply almost anything for you. Just let me know.
Does anyone happen to have handy the files required to activate the debug mode in Freddy? The English version doesn't have them but supposedly versions for other languages do. I think its the 10 scr, hep & txt thats required and they'll work with the English version.
-
I don't, but would love to get them as well. I can try asking in some of the Sierra Facebook groups.
-
I guess all we need to do is track down a non-English version. Not sure where we'd find that these days. Does GOG and the like have versions available other than English? I'd pay for it just to get the debug mode going. The decompiled source for the EditablePolygon looks quite interesting. It seems to generate pretty much the same as other Polygon Editors, but it looks like it could be a bit more polished. I can see Mark Wilden's name in there as one of the devs:
(case 97
localproc_18f1(" by^M\n^M\nMark Wilden^M\n^M\nOriginal program by Chad Bye " 1)
)
The polygon editor in SQ6 seemed quite basic compared with what this Freddy Pharkas one seems to have. It looks to be quite polished, with menus:
local46[25] = ("EDITING" 0 0 "About" 0 0 "Map" 0 0 "Create" 0 0 "Type" 0 0 "Undo" 0 0 "Help" 0 0 "eXit" 120 )
local71[22] = ("CREATING" 0 0 "About" 0 0 "Map" 0 0 "Done" 0 0 "Undo" 0 0 "Help" 0 0 "eXit" 120 )
...and help information:
(case 104
(switch (state)
(case 0
localproc_18f1(" CREATING POLYGON^M\n^M\nClick to create each corner of the polygon, then choose Done from the menu to finish. You can also press Esc or Ctrl-click to finish.^M\n^M\nTo UNDO a corner, choose Undo.^M\n^M\nTo change MAP displayed (visual or control), choose Map.^M\n^M\nTo EXIT the Polygon Editor, choose eXit or press Ctrl-S." 0)
)
(case 1
localproc_18f1(" EDITING POLYGON^M\n^M\nTo MOVE a corner, click on it and drag it to the new position.^M\nTo INSERT a new corner, Ctrl-click to create it, then drag it to the correct position.^M\nTo DELETE a corner, Shift-click on it.^M\nTo UNDO an action, choose Undo from the menu.^M\nTo CREATE a new polygon, choose Create.^M\nTo change a polygon's TYPE (Total, Near or Barred), choose Type.^M\nTo change MAP displayed (visual or control), choose Map.^M\nTo EXIT the Polygon Editor, choose eXit or press Ctrl-S.^M\n^M\nIn addition to using the mouse, you can use Space and BackSpace to select corners and Tab and BackTab to select polygons. " 0)
)
)
)
-
Here.
-
Just experimented with it. Bringing this up looks useful. Curious thing is that if you click the so what it places you close to the bug I was talking about.
-
Hey, thanks a lot for this. I'm going to start playing with it now. :)
-
Oh, I wonder if we can get troflip to add these to his copy of Freddy Pharkas and generate a new decompilation? ;D
I'd love to see what the source for this script looks like.
-
Easy peasy, here you go...
-
Lars, I was taking a look at script 325 in PQ SWAT this morning and I can see what you mean about the source being quite different (perhaps unfinished) when compared to the compiled version.
I spent the last hour decompiling this method by hand from my copy of PQ SWAT. This is what I have:
(instance hitNineShot of Script
(method (changeState newState)
(switchto (= state newState)
(
(theGame handsOff:)
(qualProd dispose:, delete:)
(if (== (++ nineShotCntr) 9) ; Assume local21 is nineShotCntr
(qualList dispose:) ; Assume local20 is qualList
(Bset fQualifiedSniper) ; Assume 24 is fQualifiedSniper
(ego awardMedal: 256)
(= local43 1) ; ?????
(curRoom newRoom: 320) ; Assume global2 is curroom (or curRoom if its a typo or an OCR error)
else
(messenger say: 0 0 88 0 self 320) ; Assume 88 is QUAL-HIT-9-C and 0 is ALL
)
)
(
(messenger say: 0 0 89 0 self 320) ; Assume 89 is QUAL-RELOAD-9-C and 0 is ALL
)
(
(= qualList (List new:)) ; Assume local20 is qualList
(qualProd setReal: qualProd 6)
(theGame hands0n:) ; Assume global1 is called "theGame"
(self dispose:)
)
)
)
)
It is indeed quite different from the same code that appears on the Wayback Machine copies of Brian's web site:
http://web.archive.org/web/20050205191150/http://www.classicgaming.com/agisci/swatcode.shtml
But at the same time, it is recognisably the same method. So what are the likely explanations for these differences? We talked about some already but I'm keen for as many suggestions as we can get. I doubt that it was leaked code, because why would a single method be leaked? If it were leaked, we'd be more likely to see a whole Script file. So I'm still leaning towards the OCR theory, which might account for the syntax errors, inconsistencies and lower-cased vars.
-
The person that I was talking to that has the source to Freddy said that the HWM debug list was missing several things for Freddy.
-
Easy peasy, here you go...
Hey, thanks, I'm taking a look now...
-
The person that I was talking to that has the source to Freddy said that the HWM debug list was missing several things for Freddy.
HWM? Do you mean this list?
http://wiki.scummvm.org/index.php/SCI/Debug_Modes#Game_specific:_Freddy_Pharkas:_Frontier_Pharmacist
I've got it activated, and have been playing around with the Polygon Editor. I've managed to crash it once so far.
-
I produced this with the Dialog Editor:
; DialogEditor v1.0
; by Brian K. Hughes
(Print
posn: 217 113,
addTitle: {Testing 123},
font: 0,
addButton: 0 {button test} 3 3,
addText: {text} 3 3,
addText: {text} 3 3,
addIcon: 0 0 0 3 3,
addEdit: @str 5 3 3 {},
font: 2108,
width: 20,
addText: {text} 0 0,
init:
)
and this with the Polygon Editor:
; Polygon Editor 1.11
; Dynamic Obstacles : Picture 230
(curRoom addObstacle:
((Polygon new:)
type: PBarredAccess,
init: 0 0 319 0 319 124 281 124 281 110 205 110 168 113 151 74
147 74 147 114 134 114 129 105 51 105 51 78 37 78 37 105
0 105,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 0 174 319 174 319 189 0 189,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 131 114 145 133 111 125 103 134 64 123 64 108 75 108 76 114,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 8 107 23 107 23 118 8 118,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 302 109 302 122 283 122 283 109,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 200 112 215 112 215 120 200 120,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 243 111 258 111 258 120 243 120,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 192 129 259 126 254 147 201 149 190 129,
yourself:
)
)
(altPolyList add:
((Polygon new:)
type: PBarredAccess,
init: 135 99 135 87 163 87 163 99,
yourself:
)
((Polygon new:)
type: PBarredAccess,
init: 28 103 28 100 57 100 57 103,
yourself:
)
)
As a side note, that "curRoom" global var confirms that the curroom in the PQ SWAT code is another example of the wrong case, which is a consistent error in the PQ SWAT code snippet. It is full of examples of the case being wrong and/or inconsistent.
-
The person that I was talking to that has the source to Freddy said that the HWM debug list was missing several things for Freddy.
HWM? Do you mean this list?
http://wiki.scummvm.org/index.php/SCI/Debug_Modes#Game_specific:_Freddy_Pharkas:_Frontier_Pharmacist
I've got it activated, and have been playing around with the Polygon Editor. I've managed to crash it once so far.
Yes, I believe that Lars and Omer have collaborated to it. http://agisci.altervista.org/SDMFAQ094.TXT
-
But at the same time, it is recognisably the same method. So what are the likely explanations for these differences? We talked about some already but I'm keen for as many suggestions as we can get. I doubt that it was leaked code, because why would a single method be leaked? If it were leaked, we'd be more likely to see a whole Script file. So I'm still leaning towards the OCR theory, which might account for the syntax errors, inconsistencies and lower-cased vars.
I guess it could have been typed in by hand rather than OCR. The newState parameter is written in different cases, as is qualProd. Can OCR create inconsistent cases like that?
But if instead someone had typed this in by hand, then it might explain a few of the inconsistencies. I was thinking this when I was decompiling the same method by hand last night. I had initially typed in some inconsistent var names at the start.
If someone did originally type in the PQ SWAT code by hand, then that suggests that they didn't have the actual source to copy and paste from, otherwise the source would have been syntactically correct. So that feels to me like they were reading from something, such as a book or magazine, and typing it in.
-
The person that I was talking to that has the source to Freddy said that the HWM debug list was missing several things for Freddy.
Any ideas what they could be? It's possible since Freddy was one of the first covered in the list, and back then I purely based it on what was listed in the "debug help" screen, which I later discovered was not always correct and did not necessarily cover all options.
In later discoveries I did try to cover all by disassembling the scripts and checking for key codes, but I don't think the ones covered earlier were revised. I didn't bother with documenting the specific options such as the Polygon Editor, etc. as I thought they were rather straigthforward and a bit beyond the original scope of the document.
To weigh in on the SCI syntax discussion: I have some parts of Sierra fan/development sites (pre 2000) still backupped somewhere, that might contain some additional information on the SWAT code (as it was already out there around that time). Also I think I've encountered an example of code somewhere, other than the SWAT code, in a SCI release. The memory is vague; it might have been AGI instead. I do know for sure that there are portions of the official AGI specs by Sierra and even assembly code of the AGI interpreter included with some AGI release(s).
-
Yeah, if you do find something in those old files that mentions where the PQ SWAT code originally came from, that would be great. I was probably told at some point but I just can't remember.
There is sample AGI code in The Official Book of King's Quest that you might be remembering. Everyone thinks of that one when they think of code examples.
Wow, I'd be very keen to know what AGI releases contained portions of the official AGI specs and assembly code. I'd never heard of that before. Can you track that down?
-
HWM wow, everybody has been resurfacing.
Any ideas what they could be? It's possible since Freddy was one of the first covered in the list, and back then I purely based it on what was listed in the "debug help" screen, which I later discovered was not always correct and did not necessarily cover all options.
Unfortunately no. He has the entire source for Freddy on CD that he recently checked to see if it was still readable. He mentioned the debug modes and the magic files. I said what the files were and linked to the AGI Wiki debug page which is based on your list. That is when he said it was missing things. I asked him if it would be possible to see a sample of the code and he disappeared from the scene.
-
If we compare troflips decompiled scripts with what is in on the debug page, we should be able to spot if something is missing. I haven't had a chance to look at it in detail yet. A quick skim over it and it looks like there are cases in there that are empty, which is a bit strange. Maybe the debug script itself is missing things. Maybe they commented bits of code in an out depending on what they were doing at the time.
-
I would expect that the code he had was from development, so it may have debugging that was removed for the release.
-
Yeah, if you do find something in those old files that mentions where the PQ SWAT code originally came from, that would be great. I was probably told at some point but I just can't remember.
There is sample AGI code in The Official Book of King's Quest that you might be remembering. Everyone thinks of that one when they think of code examples.
Wow, I'd be very keen to know what AGI releases contained portions of the official AGI specs and assembly code. I'd never heard of that before. Can you track that down?
No leads (yet) on the SWAT code, but I did manage to track the AGI specs portions down. I remembered I had copied them off the disk(s), back when their existence was mentioned in a thread on the old MT/AGIgames board. I'm not sure which release it was; it might have been the original LSL release.
Since it's somewhat off-topic I've created a new thread for it: http://sciprogramming.com/community/index.php?topic=1418.0
-
Another possible syntax clue? The SQ5 code has the following in Obj.sc:
(procedure public (proc999_7 param1 param2 param3)
(send param1:param2(rest param3))
)
This seems like a completely pointless function. It's used in (for example) Slider.sc:
proc999_7(theObj selector rest param1)
which could of course have easily been written:
(send theObj:selector(rest param1))
since the SCI Studio syntax allows using variable names as selector values. But maybe the fact that they have this proc999_7 at all suggests that the original Sierra syntax to do this was more verbose/ugly. Or rather, that there was no syntax for it, and it had to be written in asm?
-
This seems like a completely pointless function. It's used in (for example) Slider.sc:
proc999_7(theObj selector rest param1)
which could of course have easily been written:
(send theObj:selector(rest param1))
No, the two statements don't do the same thing. The second statement sets the value of the selector property of theObj to whatever is between the parentheses (maybe, if &rest works with property messages; I'm not sure of that). The first statement executes the method (or gets/sets the property) of theObj given by the selector property of the executing object. To elaborate on the syntactical ideas developed in this thread, I guess the compiler might have allowed a syntax like
(theObj (self selector?): &rest)
but if it did, this function would indeed be pointless. There is also the matter of getting in the right position to use &rest.
-
No, the two statements don't do the same thing. The second statement sets the value of the selector property of theObj to whatever is between the parentheses (maybe, if &rest works with property messages; I'm not sure of that). The first statement executes the method (or gets/sets the property) of theObj given by the selector property of the executing object.
Not quite. In the proc999_7 I posted I had actually changed the var names for readability, but that just caused confusion. In either case, the intention is to call a selector that is only known at runtime.
(procedure public (proc999_7 param1 param2 param3) // param2 is a selector value (presumably only known at runtime)
(send param1:param2(rest param3))
)
Why would the calling code use proc999_7? Only if there would otherwise be ambiguity in the syntax - or rather, if the variable name of the variable containing the selector value was actually a selector name.
With code like this:
(send myObj:myVarWithSelectorValue(stuff))
there's no point to using proc999_7, since myVarWithSelectorValue isn't a valid selector (so we know to use the value of the variable instead).
But if your code was:
(send myObj:selector(stuff))
"selector" is a valid selector (#535), so the compiler thinks the code is trying to set the value of the selector property on myObj. But the actual intent is to call a method on myObj, where the method selector is stored in the selector property of the current object. This code appears in the Slider class, which has a "selector" property.
The other usage is in Game:doit. In this case, the variable is "thePanelSelector", but this is a fabricated variable name from my decompiler. That suggests that whatever variable name was used in the original source code at this point conflicted with an actual selector name. So they needed to use proc999_7.
The conclusion to be drawn is that Sierra's syntax suffered from the same ambiguity as SCI Studio's syntax when it comes to invoking selectors that are only known at runtime (which answers a question I had posed earlier in this thread). Thus they required this little helper procedure.
-
Did anyone decompile KQ6?
-
Several times, why?
-
I thought so, but was not finding an attachment with it. Robert Lindsley was wanting to see it.
-
Whoever does it, make sure you decompile at least 3 times. I'm in the middle of reinstalling everything at the moment.
-
As I said, I thought someone already had decompiled it and didn't want to bother if t already had been done.
You giving up on Win10?
-
No, still working it into submission. Actually, it's kind of worked me into submission. I screwed everything up by messing with file/folder ownerships. Never worked right since. I just have to get over the fact that I just can't put whatever I want in root C drive anymore. Not really any going back either seeing as when I reset Windows it removed the option to rollback (as it reinstalls from scratch rather than an upgrade).
-
I've got several recurring issues in my latest decompilation of KQ6 that I just made. Four times over. For example, edgeToRoom is not a property or method on type KQ6Room, or PROPERTY-ACCESS-IN-NON-METHOD in an assembly block. Got a few instances of invalid &rest uses, some duplicated case labels... I'd believe those first two may be related to the latest commit at this time? Considering how Rm totally has an edgeToRoom method and KQ6Room is a kind of Rm...
Oh, here's the decomp in question, just for the hell of it.
-
I decompiled it last night, too. Curious thing is that when I decompiled without setting the names of the scripts it compiles without issues. If I decompile with script names set it results in many compiling errors. It would take a while to track down all of the errors.
-
Is this KQ6 CD?
The invalid &rest's might need to be fixed up manually. It's the result of changes I made to the decompiler to be more accurate (it was sometimes generating incorrect code, which is worse than non-compiling code). If I can detect these situations and try to correct them, I will. Just not sure how much work that would be yet.
The duplicate cases is unavoidable, those are just bugs in Sierra's code. I can probably turn these into warnings so at least the script will compile.
The PROPERTY-ACCESS-IN-NON-METHOD should be easily fixable.
-
I was decompiling the CD version.
-
fyi, the PROPERTY-ACCESS-IN-NON-METHOD in at least some of these cases is happening inside public procedures that fallback to disassembly. They fallback because they are invalid pointers (and appear to be unused). That is, the export points into the middle of another function. So it's trying to decompile invalid code.
-
Why does it compile without error if the file names of the scripts are not set, i.e. "n000.sc" instead of "Main.sc"?
-
I think you must be mistaken?
-
Mine was the diskette version, incidentally.
-
I know that it seems screwy, but the output simply says 341 scripts compiled.
-
Can you attached the game.ini too?
Those scripts won't compile, so scicompanion must be doing something wonky.
-
I wondered if it was actually compiling. I think I found what is going on. I was playing around with the decompiler after I had already decompiled it and clicked the 'Set Filenames' button. It created script entries in the ini with the names, even though the scripts were named 'n*.sc' and 'n*.sco'. Somehow this fools the compiler into thinking that it can find the script. Even if you delete the name of the script and have entries in the ini with just 'n000=' The same happens. Looks like it just needs to check for the existence of each script before it tries to compile it. Possibly have the 'Decompile' button write to the ini instead of the 'Set Filenames' button? That might avoid invalid ini entries.