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 Syntax Help / Re: Loading External Scripts on the Fly?
« on: August 12, 2019, 11:57:15 PM »
cramming things like the game's icon bar, control panel, and inventory
All of these will be required often to semi-often in normal use. There's a risk in not being able to pull them up if you're low on memory because their memory footprint was not accounted for earlier. What if you're prevented from saving/restoring/quitting? Putting up a death message? Using a critical object?

They will still be initialized in the game's init using the ScriptID kernel function (so they will still be loaded in heap at startup), so I don't think that will be a problem.
I just thought it was a good idea given that by the time of SCI1, it became standard for the inventory to be placed in its own script, and the control panel soon followed, then the icon bar in the SCI32 era.

Though, admittedly, from SCI01 on, the way heap was stored had been changed.

08/13/2019 UPDATE: I've decided to just move the inventory for SCI0 and SCI01 back into MAIN.SC. It's more memory-efficient that way.
I've further been making sure that the free heap and largest pointer are as close as possible (only a 2 byte difference!)

2
SCI Syntax Help / Re: Loading External Scripts on the Fly?
« on: August 10, 2019, 09:33:40 PM »
Loading external scripts on the fly... that's the approach that I've been using for my templates recently. Instead of cramming things like the game's icon bar, control panel, and inventory into MAIN.SC, why not just put them in their own individual scripts? That's what Sierra did later on, and it makes the main script (which will always be loaded in memory) use significantly less memory. In the case of a game intialization script (so long as it doesn't need to use objects in the main script), it can just erase itself from memory afterwards, since it will not need to be used again.

3
My memory must be faulty then because I thought I remembered interchanging sound files between SCI0 and SCI1 games without an issue but ran into problems with SCI1.1. I'm assuming the SCI0 format is also used by/compatible with SCI01.

If by SCI01 you mean QFG2 or Seasoned Professional, those games actually use the newer SCI1 sound format, if SCI Resource Viewer is right. The DOS version of KQ1SCI does still use the older SCI0 sound format, though that was upgraded to the SCI1 format for the Amiga version.

4
SCI Development Tools / Re: Decompilation Archive
« on: July 29, 2019, 08:26:22 PM »
Here's a new and improved decompile for QFG1EGA!

A major change here is that all of the system scripts and globals are based on the original SCI0 source, which is much more accurate. As a result, there should be no compatibility or decompiler issues on that side

The game generally seems to work okay, but the game crashes in certain areas (entering Meep's Peep, working at the stables, dispelling the bear), which seem to be related to decompilation errors.

Oh, yeah, there's also new decompiles for Seasoned Professional (EGA and VGA use exactly the same scripts) and the QFG2 demo. Both have been fully tested to completion.
7/31/2019 EDIT: Oops! I goofed up with the SCI01 decompiles, as I worked at adapting the original SCI0 header files for them, but uploaded incomplete versions. That has been fixed. Now they really have been tested to completion.

5
And here it is - SCI0 Template Redux! Fully in Sierra Script, built off of the Codename Iceman demo, and no assembly blocks anywhere!

Feel free to fix any bugs that you may notice - that's why I put it up on GitHub in the first place.

6
Eric,
I've created a github repo for the SCI0 system scripts:
https://github.com/OmerMor/SCI0

It has 2 commits for the 2 versions I have.
You can use that to create better SCI0 template.

Cool! I'd better examine these scripts. One set's from November 30, 1988 (close match to LSL2), the other's from October 25, 1989 (close match to LSL3).
I guess I'd better start working on that SCI0 template and touch up the SCI01 and SCI10 templates, since it may be a while before SCICompanion properly supports SCI2.1.

7
Here's my prototype of a new SCI1.1 template game!
It's built on top of the ImagiNation Network demo, whose interpreter is an exact match for the interpreters included in the SCI16 source. Said demo also has a complete set of system scripts, and lots of fonts.

This new template is in Sierra Script right from the start, and uses original Sierra names for defines, globals, scripts, and procedures. Various game-specific subclasses (the inventory and icon bar, for example) are now in their own scripts (this became standard in the SCI32 era). There is no assembly code in any of the scripts. Basically, the code is much simpler, cleaner, and more accurate to Sierra's original code.

The graphics are the same as the existing template, but it's quite a different beast script-wise. Then again, Sierra's programmers all had different ways of implementing things.

I was going to do a new SCI0 template, but why bother? My SCI01 template fills that niche just fine, and has additional features (doVerb method, improved memory management, and scrolling styles, to name a few).

Now to bring this to SCI2.1...

8
Might I suggest making it look a bit less like Space Quest 5, with the font and status bar being as they are in the template? It can be as simple as replacing some font resources and swapping most of statusLineCode::doit for a DrawStatus call.

You know, it's not unlike the SCI0 template having Larry 3's color menu item, but somewhat more in your face.

I have actually been working on a whole new SCI1.1 template. It's built on top of the ImagiNation Network demo, whose interpreter is an exact match for the interpreters included in the SCI16 source. Said demo also has a complete set of system scripts.

The new template is in Sierra Script right from the start, and uses original Sierra names for globals, scripts, and procedures. Various game-specific subclasses (the inventory and icon bar, for example) are now in their own scripts (this became standard in the SCI32 era). There is no assembly code in any of the scripts. Basically, the code is much simpler, cleaner, and more accurate to Sierra's original code.

I plan to upload the template soon. I also plan to create an SCI2.1 template.

9
SCI Development Tools / Re: Decompilation Archive
« on: July 14, 2019, 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.

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

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

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

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

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

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

Pages: [1] 2 3 ... 5

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

Page created in 0.134 seconds with 21 queries.