Messages

901

The Games and other Sierra Adventure stuff / Re: Sierra's SCI EGA View Editor

« on: January 25, 2011, 01:38:39 AM »

I came across this and thought that some here would find it interesting:

What game is that VIEW from do you think? Looks like Conquests of Camelot. Where did you find this image?

The Official Book of King's Quest has a screen shot of the SCI EGA VIEW Editor but that photo shows King's Quest 4. There is also several screen shots of the SCI EGA PICTURE Editor.

902

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 20, 2011, 04:35:01 PM »

That being said, it certainly seems like it would be possible to modify the compiler to allow for something like this (i.e. passing lambda functions to procedures).

This reminds me of what has been happening with the Java VM. Languages such as Clojure and Scala compile to the JVM, as do many others. Having closures and passing functions as objects is where things get really powerful. I wonder how far a compiler could go with the SCI VM?

903

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 20, 2011, 02:08:55 AM »

Keep in mind that is slightly different than an if/else, because in your case both expressions are always evaluated. (However in the example you gave it wouldn't matter, because neither expression modifies any state).

Yes, this is a good point. It will always evaluate both, which might have side effects if the expression alters something in the process of evaluating the value. I guess there is extra work being done needlessly as well.

904

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 20, 2011, 02:05:08 AM »

I agree with troflip. The eval procedure is not required. The same thing would work if you did this:

FormatPrint("%d" (+ 1 2))     // Will print '3'

In the above example, it is actually the + that acts as a procedure. The 1 and 2 are in effect passed to it and it adds them together.

I'm surprised that you had to put the true and false parameters first. There should be no reason I can see why this would be required. What happens if you wrap the condition in () characters as in the following?

iif((> 1 2) "blue" "green")

Maybe the problem is that without the () the compiler is assuming that it is wrapped in () when it appears at the end of the parameter list. Maybe it can't assume that if the condition appears at the start of the parameter list, unless it is wrapped in () as in the above example. Yeah, thinking it through, if you were to write this:

iif(> 1 2 "blue" "green")

then the compiler would probably think that the 1, 2, "blue" and "green" are all parameters for the > operator.

905

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 19, 2011, 03:22:33 PM »

But I think that would be the beauty of it. You wouldn't need to pass in the condition. The condition is essentially self evaluating. e.g.

(proc (> var 5) (+ temp 7) (- bob 2))

The procedure doesn't see the condition expression or the calculation expressions. It sees the result. For example, if var is greater than 5 then the first argument to the procedure is a value of true. The condition expression could be as complex as you want it to be, including nested ands and ors and all that sort of thing. The procedure only ever sees a value of true or false for that first parameter. You would be using the power of the language to perfom the condition evaluation.

906

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 19, 2011, 07:34:41 AM »

The more I think about it, the more I am wondering whether using the "if" keyword as is might not be such a silly idea:

(if (<condition>) (<first-value>) else (<second-value>))

What if it does return a value? Now that I think it through, it seems to make sense that most things have a value. Whether it makes sense or not is the point I guess.

The real question though is whether the compiler will let you put an "if" into this context, e.g. the compiler would have to allow this kind of code:

(= someVar (if (<condition>) (<first-value>) else (<second-value>)))

907

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 19, 2011, 01:55:21 AM »

I don't think it would need an eval() function. The evaluation of the condition would happen before the procedure is called. So in effect what you get is a TRUE or FALSE being passed to the procedure as the first parameter. I am making an assumption that boolean parameters are possible. Likewise the second and third parameters would be evaluated before passing their results to the procedure. The code in the procedure would be very trivial. All the hard word of the evaluation would be done prior to the procedure being called.

Thinking about it, the "if" keyword is almost what you need.

(if (<condition>) (<first-value>) else (<second-value>))

All the procedure would be doing is turning that into a short cut of:

(proc (<condition>) (<first-value>) (<second-value>))

The big difference though would be that the procedure returns the value it picks. I doubt that the if keyword returns a value (but then again I don't know, so perhaps that is worth testing out. It would be weird and cryptic if it does return a value though).

908

SCI Syntax Help / Re: 'Inline If' Statement

« on: January 18, 2011, 02:57:56 PM »

I've never written any SCI code, but from what I've deduced regarding the original language, I doubt that such syntax existed. One reason for this is that it has an expression as the first item after the opening ( character. My understanding is that the first item would have been one of: keyword, operator, kernel function, procedure or an object. An expression that resolves to a boolean does not align with this. I guess what you could do though is define a reusable public procedure that gives you something like this behaviour.

909

SCI Syntax Help / Re: Original SCI syntax

« on: January 09, 2011, 03:48:50 AM »

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:

Code: [Select]

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

910

SCI Syntax Help / Re: Original SCI syntax

« on: January 09, 2011, 02:46:52 AM »

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())

911

SCI Syntax Help / Re: Original SCI syntax

« on: January 06, 2011, 02:12:13 AM »

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.

912

The Games and other Sierra Adventure stuff / Re: SCI Game Debug Modes

« on: January 06, 2011, 01:50:24 AM »

Looks like that LSL7 info originally came from Al Lowe's web site:

http://www.allowe.com/Larry/7teleport.htm

It makes sense that it should be consistent with SQ6 and GK2. Wonder why Al is saying something different? Perhaps a version at some point did work like that.

913

SCI Development Tools / Re: SCI Decompiler?

« on: January 05, 2011, 05:05:55 PM »

Actually the better approach was to use UNLZEXE to obtain the original uncompressed SCIV.EXE file. After having done this, I can now clearly see the version number in the file:

0.000.685

So the interpreter packaged with SCI Companion is 0.000.685.

Just did the same for SCI Studio and it is also 0.000.685.

Maybe earlier versions of SCI Studio used 0.000.572. It seems like the SCI specs and potentially the template game could have been based on that version.

914

SCI Development Tools / Re: SCI Decompiler?

« on: January 05, 2011, 04:50:42 PM »

I believe that the template game was made from LSL3. The Free SCI documentation IDs LSL3 as 0.000.572, which is what mine shows. 0.000.685 covers SQ3, Camelot and ICEMAN.

Ah, just seen this post from back in November that seems to confirm 0.000.572 as being the template game version:

http://sciprogramming.com/community/index.php/topic,309.msg1617.html#msg1617

...although, having said this, I just found this post that seems to suggest it is 0.000.685:

http://sciprogramming.com/community/index.php/topic,50.msg113.html#msg113

...but then this next page seems to suggest a close connection between the SCI0 specifications and version 0.000.572:

http://wiki.scummvm.org/index.php/SCI/Specifications/Graphics/SCI_Ports

I'm fairly sure I saw the string .685 in the SCIV.EXE executable that comes bundled with both SCI Studio and SCI Companion, but that doesn't mean that the template game was based on that version. Perhaps the template game was based on 0.000.572 but the interpreter version packaged with the IDEs is 0.000.685. Unfortunately the SCIV.EXE is a compressed EXE by the looks of it, so the full strings are not fully visible enough for me to be sure of the version. Might need to fire up DOSBOX and see if I can get the interpreter to display the version.

915

The Games and other Sierra Adventure stuff / Re: SCI Game Debug Modes

« on: January 05, 2011, 04:26:46 PM »

I had Space Quest 6 when it came out. In theory I should still have it but when I moved house last year I couldn't find the actual CD. All I found was box with the manual and nothing else. Never actually finished that game. It didn't feel like the old SQ games.

"Creating an empty CLASSES file"...  that sounds quite obscure.

Apparently something similar exists for LSL7 (http://tawmis.com/onlinesierra/eggsandcheats.html):

Leisure Suit Larry VII:

Teleporting around...
Start Notepad.
Type nothing. Just do a