Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - EricOakford

Pages: [1] 2 3 ... 5
1
SCI Development Tools / Re: Decompilation Archive
« on: Yesterday at 01:20:46 PM »
Here's another one: the Gabriel Knight 1 demo. It seems to have been based off a beta version of the game, judging by the large amount of placeholder messages and the fact that it uses SCI1.1 rather than SCI2 like the full game does. Expect some bugs, but thankfully there are only two asm blocks (in proc211_0 and QScript). There's the needed script and interpreter to debug this thing.

I wonder why the demos for GK1, QFG4, and PQ4 used SCI1.1 instead of SCI2? My guess is that the 32-bit engine was not yet ready to be used, so the designers used the older 16-bit engine during development, then ported it to SCi2 when the full games were completed.

2
SCI Development Tools / Re: Decompilation Archive
« on: July 03, 2019, 11:21:53 PM »
Regarding PQ2demo's graphical error: No, it's actually related to the SWAT team arriving at the motel. One cop erases part of the police car. I think it's related to a decompilation error in the "swatArrives" script.

In any case, here's more decompiles! They are of the demos for LSL2, The Colonel's Bequest, SQ3, and Astro Chicken. All have been tested to completion.

3
SCI Development Tools / Re: Decompilation Archive
« on: July 02, 2019, 10:14:36 PM »
Here are some deconmpiles of the demos for Conquests of Camelot, QFG1VGA, PQ2, and the Fun Seeker's Guide!

They all fully compile and have been tested to completion. The only issue I found was a graphical error in the PQ2 demo; specifically, at the motel scene.

4
SCI Development Tools / Re: Decompilation Archive
« on: June 18, 2019, 08:40:14 PM »
Here is the decompile for the SQ6 demo! It includes a specific interpreter (taken from the SCI tools here) which has an internal debugger and no version stamp check. The latter part is important, as the original interpreter will refuse to run if the RESOURCE file has been modified, saying that it has not been version-stamped.

The game has been tested to completion, and seems like a good basis for a possible SCI32 template.

All of the system scripts are based from the newest SCI32 source from 10-12-1995, with the exceptions of:
   ACTOR.SC (06-28-1995)
   TALKER.SC (decompiled original)
   MESSAGER.SC (decompiled original)
   PLANE.SC (decompiled original)
   DTEXT.SC (06-28-1995)
   STYLER.SC (06-28-1995)

The reasons:
   Plane causes the title bar to lose its custom font.
   Talker is incompatible with the game, causing a "Not an Object" error when someone talks.
   Messager is incompatible, as anyone talking just gives a small "ALT" character and no voice.
   Actor and Styler are incompatible with the game, causing a "Not an Object" error at startup.
   DText causes the ComPost text's lines to leak out of the ComPost screen.

With Actor, Styler, and DText, it was just a matter of using the earlier script revisions from June 1995, more closely matching the game's release.
On the other hand, Plane, Talker, and Messager appear to have been specially modified for SQ6's custom talker and messager, which, in turn, seem to be based on the ones for LSL6 hr-res (to the point that some views for LSL6 are hidden in the resource files!).

There's only one bug that I can find. Specifically, the game's icon bar stops working after closing the control panel. It seems to be a decompilation error in the icon bar's doit, which can't be decompiled and thus is in assembly. For this reason, I've intentionally prevented it from compiling until it can be fixed.

5
SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 12, 2019, 12:11:38 PM »
The flags are enumerated and defined in your GAME.SH file.
Do you define them in the Game.sh file or enumerate them (or does it even matter which?)
I apologize for the hand-holding needed with this, but what does it look like in the subheader?

This is what I see in the Template, but I'm confused on how it relates to the gameFlags:
Code: [Select]
;Event flags
;Example: fBabaFrog (original Sierra naming)

It doesn't really matter; using "enum" is just a simpler way to list defines in numerical order. The compiler recognizes them in the exact same way.

As an example, here are the event flags from R44QSCI:
Code: [Select]
; Event flags
(enum
fFoyerLightOn
fMetJohan
fJohanHasTie
fJohanAtReception
fMetNiels
fNielsSleeping
fTookJar
fTookGarbage
fOpenedStoveHood
fTookFilter
fTookTie
fFellDownStairs
fTookShowerGel
fSavedJinwo
fMetRinze
fGaveRinzeBeer
fTookPen
fTookNote
fWroteNote
fJosineDumped
fJosineGotNote
fCanEnterErikRoom
fJinwoHasKey
fCanEnterJosineRoom
fErikWantsFood
fEnteredJosineRoom
fTookRyeBread
fWearingFilter
fSawErikDead
)

If you want to start an enum at a specific number, just type that number after "enum".

Oh yeah, I forgot to mention a bit of trivia earlier - KQ4 and LSL2, the first two SCI games, didn't use the "Btst/Bset/Bclr" trio at all - they just used global variables for every event. Since that's a waste of heap space, PQ2 implemented the much more efficient bit-based event flag procedures. These became a standard part of SCI games ever since.

6
SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 11, 2019, 11:54:11 AM »
Here's how event flags work, using code from my SCI01 Template:
Code: [Select]
(procedure (Btst flagEnum)
;Test a boolean game flag
(& [gameFlags (/ flagEnum 16)] (>> $8000 (mod flagEnum 16)))
)

(procedure (Bset flagEnum  &tmp oldState)
;Set a boolean game flag
(= oldState (Btst flagEnum))
(|= [gameFlags (/ flagEnum 16)] (>> $8000 (mod flagEnum 16)))
oldState
)

(procedure (Bclr flagEnum  &tmp oldState)
;Clear a boolean game flag
(= oldState (Btst flagEnum))
(&= [gameFlags (/ flagEnum 16)] (~ (>> $8000 (mod flagEnum 16))))
oldState
)

(procedure (SolvePuzzle flag points)
;Adds an amount to the player's current score. A flag (one used with
;Bset, Bclr, and Btst) is used so that a score is only added once.
(if (not (Btst flag))
(theGame changeScore: points)
(Bset flag)
)
)

They refer to a global variable array:
Code: [Select]
[gameFlags 10] ;each global can have 16 flags. 10 globals * 16 flags = 160 flags. If you need more flags, just increase the array!
The SolvePuzzle procedure checks if a flag is set, and if it's not, it awards the specified points to your score.

The flags are enumerated and defined in your GAME.SH file.

This is much more efficient than having one global per TRUE/FALSE situation, so that you only need separate global variables for situations with multiple states.

7
SCI Development Tools / Re: Experiment translating SQ3 to Japanese
« on: June 04, 2019, 12:49:01 PM »

I wanted to translate QFG2, but first I thought to try my hand with a smaller title such as Space Quest III.
(By the way, many thanks to the person who decompiled QFG2 here, I will probably be working off that, if that's all right)

The English to Japanese translation part won't be the problem, barring the time it requires, of course. The problems I have right now are essentially technical, so I thought I'd post about my progress here.

Yeah, I'm the one who decompiled QFG2. I also decompiled its demo and The Seasoned Professional.

They use what seems to be a very early version of SCI1 (also known as SCI01); from that point on, chances are good that Japanese support is integrated into the interpreter (if PQ2 is any indication).

I've put together an archive of SCI Japanese fonts. Maybe we could try to translate the QFG2 demo and Seasoned Professional into Japanese.

8
All right! There's another version of GAME.SC in that archive! I've just now used it along with SCI16's GAME.SC to carefully document the ones in my templates.

9
And here is the new decompile of the INN Demo, with all the scripts fully documented!

Well, now we know that the globals were originally not defined in the main script, but in the header files (SYSTEM.SH for system globals, GAME.SH for game-specific globals). We also know that view and pic defines had dedicated header files, and there were even loop defines.

And there's quite a bit of macro defines here, with "Cls" (clear screen) being one of them (which currently needs to be implemented as a procedure in SCICompanion).

10
Sorry to dig up an old topic, but I've got something new to add here - a decompile of the ImagiNation Network demo!

Attempting to run it after recompiling causes it to crash with the following error:
Code: [Select]
Stampver error: 941-360
Script #: 0, IP: 0

Fortunately, that's easy to work around, using the SCI.EXE taken from the SCI16 repository. On the plus side, you now also get the internal debugger!
One script couldn't be decompiled (CONV.SC), as Companion would crash on the attempt. No worries - I grabbed the CONV.SC from SCI16 and adapted it for Companion.
After that, the demo plays through to completion.

Another thing I discovered in INNDEMO's interpreter:
Code: [Select]
Aug 23 1993 12:03:27
ChrisS
i:/interp/sci/ibm
1.001.097
Release Version

That's an EXACT match for SCI16's interpreter!

11
SCI Development Tools / Re: Decompilation Archive
« on: April 27, 2019, 07:43:48 PM »
And here are decompiles of the Codename Iceman and Hero's Quest demos!
The tricky part here was that important VOCAB files were missing. Iceman had the Vocab.999 file (kernel function list), so that was used in both decompiles. Neither had the VOCAB.997 (selector list), so I had to use the one from the SCI0 version of Mixed-Up Mother Goose, which uses the same interpreter version (0.000.685, which is also the newest SCI0 interpreter).

With the exception of the DiceRm script, everything compiles and plays with no obvious issues.

12
Maybe I just have extraneous files mixed into my root Template Game folder then. Because I definitely have controlitem and SettingsPane in a raw Template Game and they both want to be the same script (and one fails to compile). Kawa, does that ZIP you attached comprise of all the scripts in the Template Game? I have some random numbered scripts to with no sources that I'm not sure if I should delete or not (in the 900s). My Template Game may be tainted.
Didn't SCI Studio renumber the system scripts, just to be annoying? Or am I thinking of someone else?

Yeah, there's also things like the death script being numbered 977, which we now know is supposed to be used for the Grooper script. In fact, game-specific scripts are generally not supposed to be in the 900s. In all fairness, the old SCI0 template was made well before the surfacing of original SCI source.

13
Everything-Else / Re: LSL1 AGI Source Code Released
« on: April 21, 2019, 09:08:56 PM »
RM0.MSG says it's 1.05, 1987-06-26...

I don't think that version was ever released for DOS. Perhaps this code was the basis for a port to another platform?

14
Everything-Else / Re: LSL1 AGI Source Code Released
« on: April 20, 2019, 07:30:26 PM »
Hopefully, the SCI games will follow soon. I've been wanting to get more original procedure and global names, as well as earlier versions of the header files.

No interpreter code? That code doesn't interest me. I'm more interested in the scripts and headers.

15
SCI Development Tools / Re: Decompilation Archive
« on: April 07, 2019, 07:57:35 PM »
Okay, here are some new decompiles for the QFG2 demo and Seasoned Professional. I have managed to put together a list of DoSound defines in the KERNEL.SH file that correspond to those games specifically. I'll have to implement those in the SCI01 template soon.

Also, Seasoned Professional has no VOCAB.900 file, making Companion crash when it attempts to decompile the User script. The required file is included in the archive, taken from the QFG2 demo.

4/9/2019 UPDATE: And here are new decompiles for Ms. Astro Chicken and the PQ3 demo! The DoSound defines closely match that of SCI1.1, so the only thing I really need to do is change them to Sierra's original names in the SCI1.0 template.

Pages: [1] 2 3 ... 5

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

Page created in 0.16 seconds with 21 queries.