SCI Wiki - User contributions [en]

SciAudio

2020-07-12T20:09:46Z

Jeremiah Nellis:

{{SCISoftwareInfobox
| Software = sciAudio
| image = [[Image:SciAudio.png|200px]]<br />
''sciAudio Example''
| Version = 1.1
| ReleaseDate = Oct. 20, 2012
| Developers = {{JeremiahNellisToolDev}}
| ProgLanguage = C#
| Platform = {{WinTool}}
| Type = {{ModTool}}
| Localization = English
| Website =
}}

<div align="center"><span style="font-size: 22pt">sciAudio</span><br />
Version 1.1<br />
''Developer: [[Gumby]]''</div>
<br />
==<br /><br /> Description ==

<blockquote>
sciAudio is here! Check out the "LockerGnome Quest Redux" demo game to see it in action!

Announcement here: http://sciprogramming.com/community/index.php?topic=634.0
</blockquote>

==<br /> Features ==

* Playback of WAV and MP3 files
* Unlimited number of sounds playing simultaneously
* Fade in/out, looping and volume control
* Classification of sounds for playback management
* Multiple commands may be issued simultaneously to the 'controller' file
* Multiple controller files to avoid resource contention
* Runs hidden in background & will terminate itself shortly upon game close
* Calls to sciAudio are performed very similarly to the built-in SCI sound calls
* Poor man's encryption (MP3's only) - simply rename your .MP3 to be .sciAudio
* Log file for troubleshooting sound playback ('sciAudio.log' located in same directory as sciAudio.exe)

 

== Limitations ==

<blockquote>
Works only in Windows (requires .NET framework)
</blockquote>

==<br /> Usage ==

<blockquote>
===<br />Setup ===

# Place the 2 nAudio DLLs & executable into a subfolder within your game named 'sciAudio'
# Create subfolders within sciAudio for your playback files. Something like this<blockquote><gamedir>\sciAudio\effects<br /><gamedir>\sciAudio\music</blockquote>
# Include the sciAudio.sc script & 'use' it in any script you wish to have sciAudio playback in

===<br /> Available commands ===

<blockquote>
command <playback command>
<blockquote>
play<blockquote>
Begins playback of a sound</blockquote>

stop<blockquote>
Stops playback of a sound</blockquote>

change<blockquote>
Changes playback of a sound. Used primarily for volume & loop control, very limited usefulness.</blockquote>

playx (play exclusively based on sound class)<blockquote>
This behaves just like the 'play' command, but will stop any currently playing sounds with the same sound class as the specified class.</blockquote>
</blockquote>
fileName
<blockquote>Filename to playback, including the path.</blockquote>

soundClass
<blockquote>Sound class to assign this sound. This is simply a string to assign to the playback for the purpose of potentially changing or terminating all sounds with the same sound class at a later time.

For example, you might have several sound effects playing simultaneously in a room. Upon leaving the room, you want to stop all the sound effects. To to this you would issue a stop <soundclass> command, which would stop all currently playing sounds with the specified sound class.

If no sound class is specified, a default sound class of "noClass" will be used</blockquote>

volume
<blockquote>Playback volume of sample. Default is 100 (100% volume of sample). Range: 0 to ~300?</blockquote>

fadeInMillisecs
<blockquote>Number of milliseconds to fade in the sample

fadeOutMillisecs
<blockquote>Number of milliseconds to fade out a sample. Can be issued with a play or stop command</blockquote>

loopFadeInMillisecs
<blockquote>Number of milliseconds to fade in a sample between loops.</blockquote>

loopFadeOutMillisecs
<blockquote>Number of milliseconds to fade out a sample between loops.</blockquote>

loopCount
<blockquote>Number of times to loop the sample. Default is 0, -1 is infinite</blockquote>

conductorFile
<blockquote>'Conductor' file name used to place commands into. This is how commands are passed between the SCI virtual machine & the sciAudio application. The sciAudio application constantly polls all conductor files, looking for changes & executes them. These files must have extension of .con.

The default value for this parameter is command.con.

Utilization of this parameter is useful in the event you have many near-simultaneous playback commands issued from within your game. Multiple different conductor files can mitigate the issue of potential file contention of just using a single file. Most game developers will probably not need to use this option.</blockquote>

playXFadeOutMillisecs
<blockquote>Only used for the 'playx' command. Upon terminating any currently playing sounds for a sound class, this value will be used for the fade out.
</blockquote>
</blockquote>
</blockquote>
</blockquote>

==<br /> Examples ==

<blockquote>
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
(use "sciAudio")

(local
snd
)

(instance aud of sciAudio
(properties)
(method (init)
(super:init())
)
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// basic playback
(send snd:
command("play")
fileName("effects\\score.sciAudio") // important: note the two backslashes in path name!
volume("35")
loopCount("0")
fadeInMillisecs("3000") // fade in beginning by 3 secs
fadeOutMillisecs("2000") // fade out ending by 2 secs
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// looping playback example
(send snd:
command("play")
fileName("effects\\loopedSound.sciAudio")
volume("100")
loopFadeInMillisecs("2000")
loopFadeOutMillisecs("2000")
loopCount("-1") // loop forever
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// stop with 5 second fade out
(send snd:
command("stop")
fileName("music\\introMusic.sciAudio")
fadeOutMillisecs("5000")
loopCount("0")
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// change currently playing volume for a sound class
(send snd:
command("change")
soundClass("myMusicSoundClass")
volume("50") // set playback to 50% volume
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// stop looping a particular sound file
(send snd:
command("change")
soundClass("music\\introMusic.sciAudio")
loopCount("0") // stop looping
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// exclusive playback (starts new playback of sound
// & stops any already playing sounds (with fadeout) for same soundClass
(send snd:
command("playx")
soundClass("narration")
conductorFile("speech\\narrate.con")
fileName("speech\\newNarration.sciAudio")
playXFadeOutMillisecs("1500") // will fade currently playing "narration" sound class sounds
volume("200")
init()
)
</syntaxhighlight>
</blockquote>

==<br /><br /> Version 1.2/1.2.1 ==

New version attached here and also put all this code into a git repo, apparently it wasn't before: https://bitbucket.org/nellisjp/sciaudio/

Now there is an sciAudio.ini file (needs to be in the sciAudio subdirectory of your game) that is read in and used for monitoring a list of (5) possible applications to monitor to determine when to kill sciAudio. It's a bit hacky, and 5 applications might be overkill but it gives a little flexibility and is backward-compatible with the previous versions which monitored either 'RUN', 'DosBox' or 'ntvdm'. I also improved the logging around all of this so it's a bit easier to troubleshoot.

Here's what the included INI file looks like, modify it to suit your needs:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
[sciAudio]
GameExecutableName1=RUN
GameExecutableName2=DOSBox
GameExecutableName3=ntvdm
GameExecutableName4=
GameExecutableName5=
</syntaxhighlight>

Version 1.2.1 includes a fix that was causing the application to not work reliably because it was checking for the game application 'too soon' and would abruptly exit. Fix consists of a 5 second delay before watching currently running processes.

==<br /> Notes ==

If you decide to re-use the same sound instance for multiple sounds, it's up to you to reset any previously specified properties, otherwise they will be carried over into the next command

Use the sciAudio.log file (located in the same directory as executable) for troubleshooting sound playback.

==<br /> Download ==

<blockquote>
Download from here (source included):
* [[Image:ZIP.PNG|ZIP File]] [[scidl:AudioUtilities/SciAudio_v1.2.1.zip|sciAudio 1.2.1]]<span class="DLInfo"> (ZIP file) [193 KB]</span>
* [[Image:ZIP.PNG|ZIP File]] [[scidl:AudioUtilities/sciAudio10_wSRC.zip|sciAudio 1.0]]<span class="DLInfo"> (ZIP file) [200 KB]</span>
</blockquote>

==<br /> Also See ==

*

SciAudio

2020-07-12T20:07:25Z

Jeremiah Nellis:

{{SCISoftwareInfobox
| Software = sciAudio
| image = [[Image:SciAudio.png|200px]]<br />
''sciAudio Example''
| Version = 1.1
| ReleaseDate = Oct. 20, 2012
| Developers = {{JeremiahNellisToolDev}}
| ProgLanguage = C#
| Platform = {{WinTool}}
| Type = {{ModTool}}
| Localization = English
| Website =
}}

<div align="center"><span style="font-size: 22pt">sciAudio</span><br />
Version 1.1<br />
''Developer: [[Gumby]]''</div>
<br />
==<br /><br /> Description ==

<blockquote>
sciAudio is here! Check out the "LockerGnome Quest Redux" demo game to see it in action!

Announcement here: http://sciprogramming.com/community/index.php?topic=634.0
</blockquote>

==<br /> Features ==

* Playback of WAV and MP3 files
* Unlimited number of sounds playing simultaneously
* Fade in/out, looping and volume control
* Classification of sounds for playback management
* Multiple commands may be issued simultaneously to the 'controller' file
* Multiple controller files to avoid resource contention
* Runs hidden in background & will terminate itself shortly upon game close
* Calls to sciAudio are performed very similarly to the built-in SCI sound calls
* Poor man's encryption (MP3's only) - simply rename your .MP3 to be .sciAudio
* Log file for troubleshooting sound playback ('sciAudio.log' located in same directory as sciAudio.exe)

 

== Limitations ==

<blockquote>
Works only in Windows (requires .NET framework)
</blockquote>

==<br /> Usage ==

<blockquote>
===<br />Setup ===

# Place the 2 nAudio DLLs & executable into a subfolder within your game named 'sciAudio'
# Create subfolders within sciAudio for your playback files. Something like this<blockquote><gamedir>\sciAudio\effects<br /><gamedir>\sciAudio\music</blockquote>
# Include the sciAudio.sc script & 'use' it in any script you wish to have sciAudio playback in

===<br /> Available commands ===

<blockquote>
command <playback command>
<blockquote>
play<blockquote>
Begins playback of a sound</blockquote>

stop<blockquote>
Stops playback of a sound</blockquote>

change<blockquote>
Changes playback of a sound. Used primarily for volume & loop control, very limited usefulness.</blockquote>

playx (play exclusively based on sound class)<blockquote>
This behaves just like the 'play' command, but will stop any currently playing sounds with the same sound class as the specified class.</blockquote>
</blockquote>
fileName
<blockquote>Filename to playback, including the path.</blockquote>

soundClass
<blockquote>Sound class to assign this sound. This is simply a string to assign to the playback for the purpose of potentially changing or terminating all sounds with the same sound class at a later time.

For example, you might have several sound effects playing simultaneously in a room. Upon leaving the room, you want to stop all the sound effects. To to this you would issue a stop <soundclass> command, which would stop all currently playing sounds with the specified sound class.

If no sound class is specified, a default sound class of "noClass" will be used</blockquote>

volume
<blockquote>Playback volume of sample. Default is 100 (100% volume of sample). Range: 0 to ~300?</blockquote>

fadeInMillisecs
<blockquote>Number of milliseconds to fade in the sample

fadeOutMillisecs
<blockquote>Number of milliseconds to fade out a sample. Can be issued with a play or stop command</blockquote>

loopFadeInMillisecs
<blockquote>Number of milliseconds to fade in a sample between loops.</blockquote>

loopFadeOutMillisecs
<blockquote>Number of milliseconds to fade out a sample between loops.</blockquote>

loopCount
<blockquote>Number of times to loop the sample. Default is 0, -1 is infinite</blockquote>

conductorFile
<blockquote>'Conductor' file name used to place commands into. This is how commands are passed between the SCI virtual machine & the sciAudio application. The sciAudio application constantly polls all conductor files, looking for changes & executes them. These files must have extension of .con.

The default value for this parameter is command.con.

Utilization of this parameter is useful in the event you have many near-simultaneous playback commands issued from within your game. Multiple different conductor files can mitigate the issue of potential file contention of just using a single file. Most game developers will probably not need to use this option.</blockquote>

playXFadeOutMillisecs
<blockquote>Only used for the 'playx' command. Upon terminating any currently playing sounds for a sound class, this value will be used for the fade out.
</blockquote>
</blockquote>
</blockquote>
</blockquote>

==<br /> Examples ==

<blockquote>
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
(use "sciAudio")

(local
snd
)

(instance aud of sciAudio
(properties)
(method (init)
(super:init())
)
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// basic playback
(send snd:
command("play")
fileName("effects\\score.sciAudio") // important: note the two backslashes in path name!
volume("35")
loopCount("0")
fadeInMillisecs("3000") // fade in beginning by 3 secs
fadeOutMillisecs("2000") // fade out ending by 2 secs
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// looping playback example
(send snd:
command("play")
fileName("effects\\loopedSound.sciAudio")
volume("100")
loopFadeInMillisecs("2000")
loopFadeOutMillisecs("2000")
loopCount("-1") // loop forever
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// stop with 5 second fade out
(send snd:
command("stop")
fileName("music\\introMusic.sciAudio")
fadeOutMillisecs("5000")
loopCount("0")
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// change currently playing volume for a sound class
(send snd:
command("change")
soundClass("myMusicSoundClass")
volume("50") // set playback to 50% volume
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// stop looping a particular sound file
(send snd:
command("change")
soundClass("music\\introMusic.sciAudio")
loopCount("0") // stop looping
init()
)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// exclusive playback (starts new playback of sound
// & stops any already playing sounds (with fadeout) for same soundClass
(send snd:
command("playx")
soundClass("narration")
conductorFile("speech\\narrate.con")
fileName("speech\\newNarration.sciAudio")
playXFadeOutMillisecs("1500") // will fade currently playing "narration" sound class sounds
volume("200")
init()
)
</syntaxhighlight>
</blockquote>

==<br /><br /> Version 1.2.1 ==

New version attached here and also put all this code into a git repo, apparently it wasn't before: https://bitbucket.org/nellisjp/sciaudio/

Now there is an sciAudio.ini file (needs to be in the sciAudio subdirectory of your game) that is read in and used for monitoring a list of (5) possible applications to monitor to determine when to kill sciAudio. It's a bit hacky, and 5 applications might be overkill but it gives a little flexibility and is backward-compatible with the previous versions which monitored either 'RUN', 'DosBox' or 'ntvdm'. I also improved the logging around all of this so it's a bit easier to troubleshoot.

Here's what the included INI file looks like, modify it to suit your needs:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
[sciAudio]
GameExecutableName1=RUN
GameExecutableName2=DOSBox
GameExecutableName3=ntvdm
GameExecutableName4=
GameExecutableName5=
</syntaxhighlight>

==<br /> Notes ==

If you decide to re-use the same sound instance for multiple sounds, it's up to you to reset any previously specified properties, otherwise they will be carried over into the next command

Use the sciAudio.log file (located in the same directory as executable) for troubleshooting sound playback.

==<br /> Download ==

<blockquote>
Download from here (source included):
* [[Image:ZIP.PNG|ZIP File]] [[scidl:AudioUtilities/SciAudio_v1.2.1.zip|sciAudio 1.2.1]]<span class="DLInfo"> (ZIP file) [193 KB]</span>
* [[Image:ZIP.PNG|ZIP File]] [[scidl:AudioUtilities/sciAudio10_wSRC.zip|sciAudio 1.0]]<span class="DLInfo"> (ZIP file) [200 KB]</span>
</blockquote>

==<br /> Also See ==

*

File:SciAudio v.1.2.1.zip

2020-07-12T19:47:09Z

Jeremiah Nellis: sciAudio version 1.2.1 - Added 5 second delay before checking running processes for the game executable

sciAudio version 1.2.1 - Added 5 second delay before checking running processes for the game executable

SCI Specifications: Chapter 3 - The Graphics subsystem

2016-02-02T11:44:01Z

Jeremiah Nellis:

==General stuff==
The graphics in SCI are generated using four resource types:

* Pic resources for background pictures
* View resources for images
* Font resources for drawing text
* Cursor resources for displaying the mouse pointer

Those resources are drawn on three distinct maps:

* The visual map, used for displaying the actual pictures the player sees
* The priority map, which keeps information about how the depth of the screen
* The control map, which contains special information

==SCI Ports==

'''Lars Skovlund'''

Version 1.0, 6. July 1999

Note that the observations made in this document are generally based on SCI version 0.000.572 (the one that comes with LSL3), but should be valid even for SCI01 and SCI1, as well. I know already about some differences in the port system from SCI0 to SCI1, but I feel we should have an interpreter running for SCI0 before dealing with SCI1.

This article discusses a key data structure in SCI graphics handling; this data structure is called a port, and it is involved in most graphics-related operations. The port is basically a graphics state record, storing things like pen color, current font, cursor position etc. Each port also has an origin and a size. The actual port data structure has remained absolutely unchanged from SCI0 up to the latest versions of SCI1.

The port can be viewed as a rectangle in which things are drawn. Every drawing operation (even KDrawPic) is executed relative to the origin coordinates of the current port (depending on the kernel function, other parameters in the port structure are used as well), such that coordinate (0, 0) in the "picture window" (such a thing really exists in SCI!) is not the top of the screen, but rather the leftmost point underneath the menu bar. The coordinate set (0,0) is called the local coordinates, and its physical position on the screen, (0, 10), is called the global coordinates. Kernel calls exist to ease conversion between the two coordinate systems, but they are, it appears, meant for event handlers to use, and not generally usable (I think they take a pointer to an Event object as a parameter).

At least three ports are created and managed automatically by the SCI interpreter. These are the "window manager" port, the menu port, and the picture port (which is actually a window, see later). The latter two should be fairly easy to understand. The menu bar is drawn in the menu port, and the current room is drawn in the picture port. What may be less obvious is that the window manager port is an "invisible" port, on which the window backgrounds are drawn, although the windows have a port themselves. If you are familiar with Windows™ programming, the term "client rectangle" may ring a bell here - SCI draws the window backgrounds, using values in the window manager port, while the window's own port controls what is drawn inside it. The window manager port covers the same bounding rectangle as the picture window, but it is transparent so it doesn't mess up the graphics.

I feel compelled to mention windows for a bit here, not in depth - they are the subject of a later article - but just to mention that the structure used to manage windows is just an extension of the port structure. Whenever an SCI system call needs a pointer to a port structure, a pointer to a window structure will do. This implicates that the SysWindow class (which implements windows) has no "port" property. Instead, its "window" property points to the extended port/window structure which can safely be passed to KSetPort. Not surprisingly, many of KNewWindow's arguments end up in the port part of the window structure.

An SCI program can't directly instantiate a port. If a program wants to access a specific part of the screen using ports, it has to instantiate a transparent window. In fact, SCI creates the picture window using RNewWindow, the same function that the kernel call KNewWindow ends up calling, asking for an untitled window with a transparent background - but more on that in a later article.

It must be stressed that ports are purely internal structures. Although a program can select different ports to draw in, the data structures themselves are absolutely off-limits to SCI code. KNewWindow fills a port structure with user-supplied data, but there is no way of changing that data, short of dis- posing the window and instantiating it again. The structure is frequently changed by SCI itself, though.

Only two kernel calls deal directly with ports:

KGetPort (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x14:_GetPort.28.29|the Section called Kernel function 0x14: GetPort() in Chapter 5]])<br>
KSetPort (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x15:_SetPort.28.29|the Section called Kernel function 0x15: SetPort() in Chapter 5]])

These two functions are often used in pairs (also internally), like:

<pre>var temp;

temp=KGetPort(); /* Save the old port */
KSetPort(...); /* Activate some other port */
.. /* Draw some stuff */
KSetPort(temp); /* Reactivate the old port */</pre>

==The Cursor resource==

This resource stores a simple bitmap describing the shape and texture of the mouse pointer. All information stored herein is little endian in byte order.

0x00 - 0x01

:: X coordinate of the mouse cursor hot spot as a 16 bit integer. This variable is not used in SCI0.

0x02 - 0x03

:: Y coordinate of the mouse cursor hot spot as a 16 bit integer. Only 0x03 is used in SCI0; here, if set, the hot spot is at (8,8), if not set, it is located at (0,0).

0x04 - 0x23

:: This is a list of 16 unsigned 16 bit integers constituting bitmasks for the mouse cursor's transparency map, with the MSB representing the leftmost pixel.

0x24 - 0x43

:: This is another list of 16 unsigned 16 bit integers. Each of them represents another bitmask, determining whether the mouse cursor pixel should be drawn in black (not set) or white (set).

To determine whether or not to draw a pixel, and, if it is to be drawn, in which color it should be drawn in, the corresponding bits of both bitmask lists mentioned above have to be examined. In the table below, A represents a bit from the first list, and B the corresponding bit from the lower list.

 

===Color mapping for the SCI0 mouse pointer===

<blockquote>
{| class="wikitable" width="150"
|-
! align="center" width="25" | AB
! width="120" | Result
|-
| align="center" width="25" | 00
| width="120" | Transparent
|-
| align="center" width="25" | 01
| width="120" | Transparent
|-
| align="center" width="25" | 10
| width="120" | 0x00 (Black)
|-
| align="center" width="25" | 11
| width="120" | 0x0f (White)
|}
</blockquote>

 

===Color mapping for the SCI1 mouse pointer===

Since this method of doing things wastes one combination, the table was changed for SCI01 and SCI1:

<blockquote>
{| class="wikitable" width="150"
|-
! align="center" width="25" | AB
! width="120" | Result
|-
| align="center" width="25" | 00
| width="120" | Transparent
|-
| align="center" width="25" | 01
| width="120" | 0x0f (White)
|-
| align="center" width="25" | 10
| width="120" | 0x00 (Black)
|-
| align="center" width="25" | 11
| width="120" | 0x07 (Light Gray)
|}
</blockquote>

 

==The SCI0 View Resource==

In SCI0, Views are collections of images or sprites. Each View resource contains a number of groups, which, in turn, contain one or more images. Usually, those groups contain a number of consecutive animation frames. It appears to be customary to store related animations or images in a single frame. For example, the basic movements of all protagonists (four or eight animation cycles (depending on the game)) are stored inside of a single View resource. Please note that the byte order of the following data is always little endian.

===The View Resource===

0x00 - 0x01

:: The number of image groups available.

0x02 - 0x03

:: A bitmask containing the 'mirrored' flag for each of the groups, with the LSB containing the 'mirrored' flag for group 0.

0x04 - 0x07

:: - unknown -

0x08...

:: A list of indices pointing to the start of the cell list for each image group. The number of entries is equal to the number of cells as described in 0x00 -

0x01.

===Cell List===

0x00 - 0x01

:: The number of image cells available for this group.

0x02 - 0x03

:: - unknown -

0x04...

:: A list of 16 bit pointers indexing the start of the image cell structure for each image cell. The pointers are relative to the beginning of the resource data.

===Image Cell===

0x00 - 0x01

:: The horizontal (X) size of the image.

0x02 - 0x03

:: The vertical (Y) size of the image.

0x04

:: The x placement modifier. This signed value determines the number of pixels a view cell is moved to the right before it is drawn.

0x05

:: The y placement modifier. This signed value determines the number of pixels a view cell is moved downwards before it is drawn.

0x06

:: The color key, i.e. the color number used for transparency in this cell.

0x07...

:: A list of combined color/repeat count entries. Each byte contains a color entry (low nibble) and a repeat count (high nibble). If the color is equal to the color key from index 0x06, then no drawing should be performed, although [repeat] pixels still need to be skipped. It is not known whether this list is terminated; the FreeSCI drawing algorithm stops drawing as soon as the rectangle defined in the first two cell entries has been filled.

==The SCI font resource==

SCI font resources remained unchanged during the SCI revisions and were still used in SCI32. Their format is relatively straightforward and completely sufficient for any 8 or even 16 bit character table:
<div id="AEN2349"></div>
'''Table 3-1. The SCI font resource data structure'''

{| class="wikitable" width="760"
|-
! width="85" align="center" | Offset
! width="235" | Type
! width="440" | Meaning
|-
| width="85" align="center" | 0
| width="235" | 16 bit integer, little endian encoding
| width="440" | Always zero (?)
|-
| width="85" align="center" | 2
| width="235" | 16 bit integer, little endian encoding
| width="440" | NUMCHAR: Number of characters
|-
| width="85" align="center" | 4
| width="235" | 16 bit integer, little endian encoding
| width="440" | HEIGHT: Number of pixel lines per text line
|-
| width="85" align="center" | 6 + NR * 2
| width="235" | 16 bit integer, little endian encoding
| width="440" | Absolute offset of the character #NR, where 0 <= NR < NUMCHAR
|}

HEIGHT does not affect the height of a character, though- it only tells the interpreter how far to move downwards when displaying a line of text. The characters referenced to starting at offset 6 are encoded as follows:
<div id="AEN2375"></div>
'''Table 3-2. The SCI font resource character data structure'''

{| class="wikitable" width="760"
|-
! width="85" align="center" | Offset
! width="235" | Type
! width="440" | Meaning
|-
| width="85" align="center" | 0
| width="235" | unsigned 8 bit integer
| width="440" | character <span style="color: red; text-decoration: line-through;">HEIGHT</span> WIDTH
|-
| width="85" align="center" | 1
| width="235" | unsigned 8 bit integer
| width="440" | character <span style="color: red; text-decoration: line-through;">WIDTH</span> HEIGHT
|-
| width="85" align="center" | 2...
| width="235" | bitmask, size HEIGHT * round_up(WIDTH / 8)
| width="440" | Bitmask for the character
|}

The bitmap consists of HEIGHT lines of n bytes, where n equals the number of bytes required for storing WIDTH bits. Data is stored with the MSB first, in little-endian encoding (first byte describes the 8 leftmost pixels), where a pixel is drawn iff the bit it corresponds to is set.

==The SCI0 and SCI01 pic resource==

The pic (background picture) resource format used in SCI0 is rather complex in comparison to the other graphical resource formats. It is best described as a sequence of drawing operations on a set of four 320x200 canvases, three of which are later used in the game (visual, priority, and control), and one of which is used during the drawing process for auxiliary purposes<ref group=Note>Due to the vector graphics nature of these drawing operations, they are inherently more scaleable than pixmaps.</ref>.

Note hereIn order to describe the process, we will first need to define a set of operations we base them on:

<pre>FUNCTION peek_input(): Byte; /* returns the byte pointed to by the input pointer */
FUNCTION get_input(): Byte; /* works like peek_input(), but also increminates the
** input pointer */
FUNCTION skip_input(x): Byte; /* skips x input bytes */</pre>

Using these pre-defined functions, we will now define additional helper functions used for reading specifically encoded data tuples:

<pre>FUNCTION GetAbsCoordinates(): (Integer, Integer)
VAR
x, y, coordinate_prefix : Integer;
BEGIN
coordinate_prefix := get_input();
x := get_input();
y := get_input();
x |= (coordinate_prefix & 0xf0) << 4;
y |= (coordinate_prefix & 0x0f) << 8;

RETURN (x,y)
END

FUNCTION GetRelCoordinates(x : Integer, y: Integer): (Integer, Integer)
VAR
input : Integer;
BEGIN
input := get_input();

''The below code for x is inaccurate. The left-most bit is used to indicate sign, so before doing the bitshift it is necessary to remove the left-most bit''
IF (input & 0x80) THEN
x -= (input >> 4);
ELSE
x += (input >> 4);
FI

IF (input & 0x08) THEN
y -= (input & 0x7);
ELSE
y += (input & 0x7);
FI

RETURN (x,y)
END</pre>

We also need some data types based on EGACOLOR and PRIORITY, which can be thought of as integers:

<pre>TYPE Palette = ARRAY[0..39] of EGACOLOR[0..1]
TYPE Priority_Table = ARRAY[0..39] of PRIORITY

Palette default_palette =
<(0,0), (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7),
(8,8), (9,9), (a,a), (b,b), (c,c), (d,d), (e,e), (8,8),
(8,8), (0,1), (0,2), (0,3), (0,4), (0,5), (0,6), (8,8),
(8,8), (f,9), (f,a), (f,b), (f,c), (f,d), (f,e), (f,f),
(0,8), (9,1), (2,a), (3,b), (4,c), (5,d), (6,e), (8,8)>;

#define DRAW_ENABLE_VISUAL 1
#define DRAW_ENABLE_PRIORITY 2
#define DRAW_ENABLE_CONTROL 4

#define PATTERN_FLAG_RECTANGLE 0x10
#define PATTERN_FLAG_USE_PATTERN 0x20</pre>

And now for the actual algorithm:

<pre>FUNCTION DrawPic (cumulative, fill_in_black : Boolean; default_palette: Integer; visual_map, priority_map, control_map, aux_map : Map): Map^4
VAR
palette : Array [0..3] of Palette;
drawenable, priority, col1, col2, pattern_nr, pattern_code : Integer;
BEGIN
palette := (default_palette × 4);
drawenable := DRAW_ENABLE_VISUAL | DRAW_ENABLE_PRIORITY
priority := 0;
col1 := col2 := 0;
pattern_nr := 0;
pattern_code := 0;

IF (!cumulative) THEN BEGIN
visual_map := (0xf × 320 × 200);
map control := map priority := map aux := (0 × 320 × 200);
END

FOREVER DO BEGIN

opcode := get_input();

COND opcode:
0xf0 → /* PIC_OP_SET_COLOR */
code := get_input();
(col1, col2) := palette[default_palette + (code / 40)][code % 40];
drawenable |= DRAW_ENABLE_VISUAL;

0xf1 → /* PIC_OP_DISABLE_VISUAL */
drawenable &= ~DRAW_ENABLE_VISUAL;

0xf2 → /* PIC_OP_SET_PRIORITY */
code := get_input();
priority := code & 0xf;
drawenable |= DRAW_ENABLE_PRIORITY;

0xf3 → /* PIC_OP_DISABLE_PRIORITY */
drawenable &= ~DRAW_ENABLE_PRIORITY;

0xf4 → /* PIC_OP_RELATIVE_PATTERNS */
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f
FI

(x,y) := GetAbsCoordinates();

DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);

WHILE (peek_input() < 0xf0) DO BEGIN
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f
FI
(x,y) = GetRelCoordinates(x,y);
DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);
END

0xf5 → /* PIC_OP_RELATIVE_MEDIUM_LINES */
(oldx, oldy) := GetAbsCoordinates();
WHILE (peek_input() < 0xf0) DO BEGIN
temp := get_input();
IF (temp & 0x80) THEN
y := oldy - (temp & 0x7f)
ELSE
y := oldy + temp
FI
x = oldx + get_input();
DitherLine(oldx, oldy, x, y, col1, col2, priority, special, drawenable);
(oldx, oldy) := (x, y);
END

0xf6 → /* PIC_OP_RELATIVE_LONG_LINES */
(oldx, oldy) := GetAbsCoordinates()
WHILE (peek_input() < 0xf0) DO BEGIN
(x, y) := GetAbsCoordinates();
DitherLine(oldx, oldy, x, y, col1, col2, priority, special, drawenable);
(oldx, oldy) := (x, y);
END

0xf7 → /* PIC_OP_RELATIVE_SHORT_LINES */
(oldx, oldy) = GetAbsCoordinates()
WHILE (peek_input() < 0xf0) DO BEGIN
(x, y) := GetRelCoordinates(oldx, oldy);
DitherLine(oldx, oldy, x, y, col1, col2, priority, special, drawenable);
(oldx, oldy) := (x, y);
END

0xf8 → /* PIC_OP_FILL */
IF (fill_in_black) THEN
(oldc1, oldc2) := (c1, c2);
FI

WHILE (peek_unput() < 0xf0) DO BEGIN
(x, y) := GetAbsCoordinates();
DitherFill(x, y, col1, col2, priority, special, drawenable);
END

IF (fill_in_black) THEN
(c1, c2) := (oldc1, oldc2);
FI

0xf9 → /* PIC_OP_SET_PATTERN */
pattern_code := get_input() & 0x37;
pattern_size := pattern_code & 0x7;

0xfa → /* PIC_OP_ABSOLUTE_PATTERNS */
WHILE (peek_input() < 0xf0) DO
IF (pattern_code & PATTERN_FLAG_USE_PATTERN)
pattern_nr := (get_input() >> 1) & 0x7f
FI
(x, y) := GetAbsCoordinates();
DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);
END

0xfb → /* PIC_OP_SET_CONTROL */
control := get_input() & 0x0f;
drawenable |= DRAW_ENABLE_CONTROL;

0xfc → /* PIC_OP_DISABLE_CONTROL */
drawenable &= ~DRAW_ENABLE_CONTROL;

0xfd → /* PIC_OP_RELATIVE_MEDIUM_PATTERNS */
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f;
FI

(oldx, oldy) := GetAbsCoordinates();

DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);

WHILE (peek_input() < 0xf0) DO BEGIN
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f;
FI

temp := get_input();
IF (temp & 0x80)
y := oldy - (temp & 0x7f)
ELSE
y := oldy + temp
FI
x := oldx + get_input();
DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);
END

0xfd → /* PIC_OP_OPX */
COND get_input():
0x00 → /* PIC_OPX_SET_PALETTE_ENTRY */
WHILE peek_input() < 0xf0 DO BEGIN
index := get_input();
color := get_input();
palette[index / 40][color % 40] := color;
END

0x01 → /* PIC_OPX_SET_PALETTE */
palette_number := get_input();
FOR i := 0 TO 39 DO
palette[palette_number][i] := get_input();
OD

0x02 → /* PIC_OPX_MONO0 */
skip_input(41);

0x03 → /* PIC_OPX_MONO1 */
skip_input(1);

0x04 → /* PIC_OPX_MONO2 */
0x05 → /* PIC_OPX_MONO3 */
skip_input(1);

0x06 → /* PIC_OPX_MONO4 */
0x07 → /* PIC_OPX_EMBEDDED_VIEW */ /* SCI01 operation */
0x08 → /* PIC_OPX_SET_PRIORITY_TABLE */ /* SCI01 operation */

0xff → return (visual, control, priority, aux);
END OF COND
END
END</pre>

'''This algorithm uses three auxiliary algorithms, DrawPattern, DitherLine, and DitherFill, which are sketched below. All of these functions are supposed to take the four maps as implicit parameters.'''

<pre>PROCEDURE DrawPattern(x, y, col1, col2, priority, control, drawenable : Integer; solid : Boolean ; pattern_size, pattern_nr : Integer; rectangle : Boolean)</pre>

Alters (x,y) so that 0 <= (x - pattern_size), 319 >= (x + pattern_size), 189 >= (y + pattern_size) and 0 <= (y - pattern_size), then draws a rectangle or a circle filled with col1, col2, priority, control, as determined by drawenable.

If rectangle is not set, it will draw a rectangle, otherwise a circle of size pattern_size. pattern_nr is used to specify the start index in the random bit table (256 random bits)

<pre>PROCEDURE DitherLine(x, y, xend, yend, color1, color2, priority, control, drawenable : Integer)</pre>

Draws a dithered line between (x, y+10) and (xend, yend+10). If the appropriate drawenable flags
are set, it draws 'priority' to the priority map, 'control' to the control map, and 'color1' and 'color2'
(alternating) to the visual map. The auxiliary map is bitwise-or'd with the drawenable flag while this is
done.

<pre>PROCEDURE DitherFill(x, y, col0, col1, priority, control, drawenable : Integer)</pre>

Fills all layers for which drawenable is set with the appropriate content. Diagonal filling is not allowed. Boundaries are determined as follows:

<x<0, x>319, y<10, y>199 are hard boundaries. We now determine the 'boundary map' bound_map and the allowed color legal_color. If bound_map[coordinates] = legal_color, then the pixel may be filled.

<pre>IF (drawenable & DRAW_ENABLE_VISUAL)
bound_map = visual;
legal_color = 0xf;
ELSIF (drawenable & DRAW_ENABLE_PRIORITY)
bound_map = priority;
legal_color = 0;
ELSIF (drawenable & DRAW_ENABLE_CONTROL)
bound_map = control;
legal_color = 0;
ELSE
return;
FI</pre>

==Windows, Dialogs and Controls==

'''by Lars Skovlund'''

Version 1.0, 7. July 1999

I am going to start by mentioning the menus. It has nothing to do with the material I deal with in this essay. They use different kernel calls, and such things as port management are handled internally by the kernel routines. The SCI program just sets up a menu structure using the kernel calls. Since they are irrelevant to the subject of this essay, I will not spend more time on them.

The Rect structure is important (also to ports) since it is the basis for passing a screen position to the interpreter. It looks like this:

<pre>typedef struct
{
short top, left, bottom, right;
}</pre>

It will be seen from this that rectangle coordinates in SCI are not normally represented in the usual (x,y,width,height) fashion. So pay close attention to this structure! Also, it is not passed as a pointer, but rather as the four values in order. This is particularly true of SCI objects, where the property names nsTop etc. actually form a Rect structure which can be used directly by the interpreter.

Windows are created using the KNewWindow kernel function. Each window has six attributes which are passed from the script to the kernel function:

Bounding rectangle<br>
Title<br>
Type<br>
Priority<br>
Foreground color<br>
Background color

Of these, the type and priority are the most interesting, because they decide the appearance of the window. The type is a bit field:

bit 0 - transparency<br>
bit 1 - window does _not_ have a frame<br>
bit 2 - the window has a title<br>
bit 3-6 - unused<br>
bit 7 - see below

Bit 0 specifies a transparent window. KNewWindow does not save the image behind the created window - it stays on the screen until the pic is redrawn, so windows with this style definitely can't be used as message boxes. It does have some special uses, though. If this bit is not set, KNewWindow draws a rectangle in the specified background color using the bounding rectangle coordinates (using the WM port). When this bit is set,

Bit 1 specifies a window without a frame. The frame is the black shading you can see in the corner of a message box.

Bit 2 tells KNewWindow to draw a grey title bar with a title printed in white. In the version I have used for this essay, it is not possible to change the title bar colors. Note that the bounding rectangle is always specified as if the window had no title bar. If this bit is set, ten pixels are reserved above the coordinates specified. Although this bit is set, the Title parameter may still be NULL. If this is the case, an empty title bar is drawn.

Bit 7 has a special meaning; it is used only in window type 0x81, and is not tested in any other way. When this style is chosen, KNewWindow does not draw anything at all. It is the caller's responsibility to draw a window frame on the WM port. CB1 uses this style for its ornate windows, and draws the frame manually.

The picture window which I mentioned in the last article is created using style 3 (that is, TRANSPARENT | NOFRAME). The normal message box styles used in LSL3 are 0 and 4.

I have not been able to investigate the priority property yet, so the fol- lowing is based on suppositions. It is only used when drawing transparent windows. In this case, if priority is not -1 (which means not used), the window is drawn onto the priority map (with the specified priority value) as well as the screen.

There is a class called SysWindow which is just a simple wrapper around the following two kernel calls. Try breaking on SysWindow::open, then type c to inspect the current object. You can change all the parameters to KNewWindow (the Rect is split in its fields, to nsTop, nsLeft etc.)

To create a window structure, use KNewWindow (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x13:_NewWindow.28Rect.2C_HeapPtr.2C_word.2C_word.2C_word.2C_word.29|the Section called Kernel function 0x13: NewWindow(Rect, HeapPtr, word, word, word, word) in Chapter 5]]); to remove it again, apply KDisposeWindow (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x16:_DisposeWindow.28HeapPtr_Window.29|the Section called Kernel function 0x16: DisposeWindow(HeapPtr Window) in Chapter 5]]) on it.

So how do we put stuff inside these windows? That question is a little complicated to answer, because it is really a shared effort between the interpreter and the object hierarchy, and this is one case where the interpreter actually interacts with the objects itself. I will start by explaining the classes involved.

All control types are descendants of a common class (I do not know its name, since it appears to have an invalid name property). Among other things, this common class contains a type number and a state. The type number is the only thing that distinguishes the control types from each other inside the interpreter - if a wrong type is set, the interpreter might try to change a non-existent property.

The type numbers are laid out as follows:

# - Button control
# - Text control
# - Edit control
# - Icon control
# - not used
# - Selector control (as in the Save and Restore boxes)

The gauge "controls" are not really controls. I don't know how they work (yet).

Each control also has a state value. These are laid out as follows:

: bit 0 - selectable. If this bit is set, the control can be selected using the Tab key. Except for the text and icon controls, all controls are selectable.<br>
: bit 1 - unknown. Always set, except for the text and icon controls<br>
: bit 2 - disabled. When this bit is set, a button is grayed out. No other control types are affected.<br>
: bit 3 - selected. When this bit is set, a frame is drawn around the control.

Note that state 3 is by far the most common. With that explained, I'll move on to the kernel functions. There are three functions associated with controls - KDrawControl (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x17:_DrawControl.28HeapPtr.29|the Section called Kernel function 0x17: DrawControl(HeapPtr) in Chapter 5]]), KHiliteControl (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x18:_HiliteControl.28HeapPtr.29|the Section called Kernel function 0x18: HiliteControl(HeapPtr) in Chapter 5]]) and KEditControl (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x19:_EditControl.28HeapPtr.29|the Section called Kernel function 0x19: EditControl(HeapPtr) in Chapter 5]]). Note that there is a KOnControl kernel call which is entirely unrelated to window management.

The dialogs are implemented using not one, but two classes - Dialog and Window. While the Window class maintains the window (It is derived from SysWindow), the Dialog class is just a list of controls. It is derived from the List class, but has extended functionality to tell its members to redraw etc. There is a special function, located in script 255, which allows scripts to push information about the dialog on the stack instead of creating the Dialog object manually.

:: '''''Note''' that the internal debugger uses the same window calls as the SCI script. That is why the screen messes up if you step through drawing code - the debugger has activated the Debug window port, and "forgets" to switch back while stepping across instructions. Thus, all graphics commands are redirected to the debug window port. Not a pretty sight.''

==Pictures and movement control==

'''By Lars Skovlund'''

Version 1.0, 24. July 1999

A pic in SCI consists of three layers (called maps - they are unrelated to the map resources found in SCI1 games). The visual map, used for the picture which appears on the user's screen. The priority map which tells the interpreter which things go in front of which in the three-dimensional room. Without the priority map, a room would just be a flat, painted surface. The control map decides where game characters (called actors) can walk and where special events occur. These special events are triggered by a game character walking on a particular spot. Where the visual map is almost always very complex and using dithered fills etc., the latter two consist of large areas of solid color.

Many functions which need to access these maps do so by using a bit-field. The bits are laid out as follows (but don't set more than one at a time!)

bit 0 - Visual<br>
bit 1 - Priority<br>
bit 2 - Control

It is important to understand that, although being represented as colors on the screen, a priority/control "color" should be considered a number. The colors map to values according to the standard EGA color values.

Every animated object in SCI has a priority. As the object moves, its pri- ority changes according to the so-called priority bands, explained next (it is, however, possible for a script to lock the priority of a view). The picture window is divided vertically into 16 priority bands. The priority of an animated object is determined by the position of its "base rectangle" in one of these bands. Things are drawn in order of ascending priority, so objects with priority 15 are guaranteed to be in front of everything else. The default priority mapping gives priority 0 a fairly large space, the 42 topmost rows (including the menu bar which AFAIK is 10) in the picture. All other priority bands have the same size. A script can choose to alter this mapping, specifying the amount of space to assign to priority 0, and the number of the last row to include in the mapping calculation.

In most rooms, it is desirable to limit actor movement, confining the actor to a specific part of the screen. In other cases, special events are triggered by movement into a specific screen area. On some occasions, even room switches are implemented using control polygons. While the meaning of priorities is determined by the kernel, the meaning of control values is entirely up to the script. It is more or less a standard, however, that actors can't walk on white control areas.

As the control map is not consulted by the interpreter itself (except in a few cases), scripts need a way to do so. That way is called OnControl, and it is a kernel call. Supplied with a point or a rectangle, it returns a bit mask containing the control values of all the pixels in the desired region. If a specific control value is encountered, it is used as a bit number, and that bit is set in the output mask.

This bit mask system is also used in another place, namely the illegalBits selector of the Act (actor) class. The illegalBits selector determines in which areas the actor may not walk.

The OnControl() system call is explained in [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x52:_OnControl.28word.2C_Point_.7C_Rect.29|the Section called Kernel function 0x52: OnControl(word, Point | Rect) in Chapter 5]].

;Notes
<references group=Note/>

 

<span style="float: left">[[SCI Specifications: Chapter_2_-_Resource_files|< Previous: Chapter 2 - Resource files]]</span><span style="float: right">[[SCI Specifications: Chapter_4_-_The_Sound_subsystem|Next: Chapter 4 - The Sound subsystem >]]</span>

 

[[Category:SCI Documentation]]
[[Category:Sierra Creative Interpreter Specifications]]
[[Category:SCI Resources]]
[[Category:Control Areas]]

Leveraging The Text Resources Further

2013-12-10T23:28:47Z

Jeremiah Nellis: Created page with "You can move all your #title & #button text descriptions used in Print() statements: In controls.sc, in the Print() procedure change the '(case #button' section: <div class="..."

You can move all your #title & #button text descriptions used in Print() statements:

In controls.sc, in the Print() procedure change the '(case #button' section:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(case #button
= hButtons[buttonCnt] (DButton:new())

(if(>= Abs(params[+ paramCnt 1]) 0 and <= Abs(params[+ paramCnt 1]) 999)
(send hButtons[buttonCnt]:
text(Format("%s" params[+ paramCnt 1] params[+ paramCnt 2]))
value(params[+ paramCnt 3])
setSize()
)
= paramCnt + paramCnt 3
)(else
(send hButtons[buttonCnt]:
text(params[++paramCnt])
value(params[++paramCnt])
setSize()
)
)
= btnsWidth (+ btnsWidth (+ (send hButtons[buttonCnt]:nsRight) 4))
++buttonCnt
)
</syntaxhighlight>
And the '(case #title' section:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(case #title
++paramCnt

(if(>= Abs(params[paramCnt]) 0 and <= Abs(params[paramCnt]) 999)
Format("%s" params[paramCnt] params[+ paramCnt 1])
++paramCnt
)(else
(send hDialog:text(params[paramCnt]))
)
)
</syntaxhighlight>
Now, you can use either technique - specify a static string or a text resource like this:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
Print("Hello there" #title 999 1) // 999 is the text resource holding our title text
Print("Hello there" #title "Greetings") // the original way of specifying a title still works too
</syntaxhighlight>
Same with buttons:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
Print("Make a selection" #button 888 2) // 888 is the text resource holding our button text
Print("Make a selection" #button "OK") // the original way of specifying text for buttons still works
</syntaxhighlight>
Of course, if you are this heap-bound, you'd have the actual text of your Print statement to be in a text resource too, so a more realistic example would be something like this:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
Print(0 15 #title 999 1)
Print(0 22 #button 888 1)
</syntaxhighlight>
[[Category:TemplateGameFixes]]
[[Category:Syntax]]

Graphical health meter

2013-11-02T03:11:05Z

Jeremiah Nellis: Created page with "''Originally posted on the SCI Programming Forums by Gumby.'' Here's a really simple solution to accomplish this. First, the laborious part; y..."

''Originally posted on the [[scipf:topic,667.html|SCI Programming Forums]] by [[Gumby]].''

Here's a really simple solution to accomplish this. First, the laborious part; you need to make a view starting with a health bar at 'full strength', and then in each frame remove one 'line' of heath. My implementation used a health meter with a length of roughly 100 pixels (so 100 cells in the view). We will instantiate this as our 'lifeMeter' view.

Once you have your view created, add this code to your room script:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
(local
flag
)

(instance public rm001 of Rm
(method (init)
...
(lifeMeter:init()) // display the life meter on the screen
= flag FALSE // init the flag variable
)

(method (doit)
(super:doit)
// when we hit particular cells in the view, display messages to the user
(switch (lifeMeter:cel())
(case 35
(if (not flag)
Print("You don't feel so well.")
= flag TRUE
)
)
(case 70
(if (not flag)
Print("You are doubling over in pain.")
= flag TRUE
)
)
(case 95
(if (not flag)
Print("Death is imminent.")
= flag TRUE
)
)
(case 100
(if (not flag)
Print("You are dead.")
= flag TRUE
)
)
(default // need this so that for the 10 seconds that this cell is active
= flag FALSE // for the states specified in the switch above that the message is
// only displayed once
)
)
)
)

(instance RoomScript of Script
(method (changeState mainState)
(var currentCel)
= seconds 10 // wait 10 seconds
= currentCel (lifeMeter:cel()) // get the current cell of the health meter view
(lifeMeter:setCel(+ currentCel 1)) // advance to the next view in the cell, life meter is now shorter
)
)

(instance lifeMeter of Prop (properties y 8 x 165 view 11)) // meter located top-center of screen
</syntaxhighlight>
 

Basically, the changeState() method runs continuously, every 10 seconds it shortens the health bar by advancing the view to the next cell. The doit() method waits for the view to hit certain cells, and when it does it alerts the user of their failing heath.

Obviously, this is a really simple implementation, suitable perhaps if the ego is poisoned and steadily losing health, or maybe dying from starvation. If you wanted something that was more 'event-driven', you could go without the changeState() entirely, and handle the changing of the lifeMeter view through specific events in your game (monster attack, ego touches a particular control color, etc).

'''With regard to heap/hunk space consumption:'''<br>
Looks like it loads the whole view into 'hunk space' upon init. Which in my case consumed 31K (which is the size of the view reported by Companion), but I still have plenty of hunk left (128K) and that's with lots of other views already init()ed. Doesn't seem to matter whether the view cycles or doesn't, no change there.

To see a full implementation (with source code) of the health meter described here, see [[120_Degrees_Below_Zero|120 Degrees Below Zero]]

[[Category:Examples]]

SCI Logging

2013-11-02T02:58:00Z

Jeremiah Nellis: Created page with "''Originally posted on the SCI Programming Forums by Gumby.'' I'm pleased to announce that the first version of [[SCI Logging Demo|SCI Logging]..."

''Originally posted on the [[scipf:topic,718.html|SCI Programming Forums]] by [[Gumby]].''

I'm pleased to announce that the first version of [[SCI Logging Demo|SCI Logging]] has been hacked together & uploaded to the fan games page.

It essentially logs all the necessary events (all user interaction) that is required for a 'automated replay' of a game. Useful for testing & troubleshooting and should hopefully work for an automated walkthrough of a game. Ultimately, I'd like to create automated testing functionality where a recorded log file could be coupled with a file containing expected responses from the game.

Unfortunately I had to make extensive changes to the template game to make this work, too many to list here but here's an overview. I created a new script (LogEvent.sc) which is responsible for the heavy lifting, reading and writing events to/from a log file. For logging events, the calls are pretty much all wired into the User.sc and Controls.sc script. For replaying logs, the replay command is called in the doit() method in the Main.sc. Logging is enable/disabled in the init() method of the Main.sc script. Please see the commented/uncommented sections, you'll be able to spot them pretty easily.

Here's the included log file in the game (poorly formatted - it's a fixed width of 115 characters or so):

Ticks: 00000051 Event: gameLClick X: 201 Y: 083 Key: Msg:<br>
Ticks: 00000054 Event: openPrint X: Y: Key: Msg: Initial Print<br>
Ticks: 00000202 Event: closePrint X: Y: Key: Msg:<br>
Ticks: 00000202 Event: openPrint X: Y: Key: Msg: Print #2<br>
Ticks: 00000349 Event: closePrint X: Y: Key: Msg:<br>
Ticks: 00000409 Event: keyMove X: Y: Key: $4d00 Msg:<br>
Ticks: 00000529 Event: parseOpen X: Y: Key: Msg: Enter Input:<br>
Ticks: 00000607 Event: parseClose X: Y: Key: Msg: look<br>
Ticks: 00000608 Event: openPrint X: Y: Key: Msg: I see nothing<br>
Ticks: 00000882 Event: closePrint X: Y: Key: Msg:<br>
Ticks: 00000990 Event: keyMove X: Y: Key: $4800 Msg:<br>
Ticks: 00001242 Event: keyMove X: Y: Key: $4800 Msg:<br>
Ticks: 00001260 Event: leftClick X: 160 Y: 100 Key: Msg:<br>

Initial tests are very promising. The only thing of concern is to make sure that your game runs quickly enough to log & replay the events at the correct tick count. If your game is laggy (like 120 Below Zero), you'll need to change your DosBox speed settings to address this. Tick counts are the Achilles Heel of this entire project. Right now it does not perform a 'perfect replay', but it is quite close - within one or two ticks.

I'm pretty happy with the result, though I'm sure it needs additional testing & feedback. I learned a lot about event handling, especially with regard to the print and parser events.

Okay, here's a stab at how you need to modify your own game to support log/replay functionality. First, download the [[SCI Logging Demo|SCI Logging]] demo game and put the LogEvent.sc script into your game /src directory. Then modify the following files accordingly.

------------------------------------------------------------------------
game.sh
------------------------------------------------------------------------
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// Add the following defines
(define LOGEVENT_SCRIPT 970)

// all the different possible log events
(define EVENT_LEFTCLICK 0)
(define EVENT_RIGHTCLICK 1)
(define EVENT_KEYMOVE 2)
(define EVENT_PARSEOPEN 3)
(define EVENT_CLOSEPRINT 4)
(define EVENT_OPENPRINT 5)
(define EVENT_GAMEKEY 6)
(define EVENT_GAMELEFTCLICK 7)
(define EVENT_GAMERIGHTCLICK 8)
(define EVENT_PARSECLOSE 9)

// the 3 log actions
(define NO_LOG 0)
(define SAVE_LOG 1)
(define REPLAY_LOG 2)
</syntaxhighlight>
 
------------------------------------------------------------------------
Controls.sc
------------------------------------------------------------------------
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// Include the LogEvent script near the top:
(use "logevent")

// Change your Dialog class doit() method to be this (changes highlighted):

(method (doit pItem)
(var hEvent, isClaimed, editControl)
= busy TRUE
= editControl FALSE

(self:eachElementDo(#init))
(if(theItem)
(send theItem:select(FALSE))
)
(if(paramTotal and pItem)
= theItem pItem
)(else
= theItem (self:firstTrue(#checkState TRUE))
)
(if(theItem)
(send theItem:select(TRUE))
)
= isClaimed FALSE

(while((not isClaimed))

(if (== gLogAction REPLAY_LOG)
// Queue up events until we get a parser close or close print event (should just be the next event in the log)
(if (<> gEventEvent EVENT_PARSECLOSE and <> gEventEvent EVENT_CLOSEPRINT)
= gEventClaimed TRUE
QueueEvent()
)
// wait until we should close this window
(if (>= GetTime() gEventTicks)
// it's been closed, get out of the loop
= isClaimed TRUE
break
)
)

(self:eachElementDo(#cycle))
= hEvent (Event:new())
GlobalToLocal(hEvent)
= isClaimed (self:handleEvent(hEvent))
(send hEvent:dispose())
(self:check)
(if( (== isClaimed -1) or (not busy) )
= isClaimed FALSE
= editControl TRUE
EditControl(theItem 0)
break
)
Wait(1)
)
= busy FALSE

// Log the close print event, as long as this is not an EditPrint window
(if (== gLogAction SAVE_LOG and == editControl TRUE)
LogEvent(hEvent "closePrint" )
)

return(isClaimed)
)

// Make the Dialog class dispose method look like this:

(method (dispose)
(if(== self gPrintDlg)
SetPort(gOldPort)
= gPrintDlg NULL
= gOldPort NULL
)
(if(window)
(send window:dispose())
)
= window NULL
= theItem NULL
(super:dispose())

// When the print window is destroyed, load up the next event
(if (== gLogAction REPLAY_LOG)
= gEventClaimed TRUE
QueueEvent()
)

)

// Add this code before the send to hDText in the Print() procedure

// Logs when either the parser window is opened or a print dialog is opened
(if (== gLogAction SAVE_LOG)
(= dummyEvent Event:new())
(if(== STRINGS_EQUAL StrCmp(@msgBuf "Enter Input:"))
LogEvent(dummyEvent "parseOpen" @msgBuf)
)(else
LogEvent(dummyEvent "openPrint" @msgBuf)
)
)

(send hDText:
text(@msgBuf)
moveTo(4 4)
font(gDefaultFont)
setSize()
)

// Further down in the Print() procedure, before the open call:

// Queue up the next event (which should be a CLOSEPRINT event)
(if (== gLogAction REPLAY_LOG and == gEventEvent EVENT_OPENPRINT)
= gEventClaimed TRUE
QueueEvent()
)

(send hDialog:open(moveToX moveToY))
</syntaxhighlight>
 
------------------------------------------------------------------------
User.sc
------------------------------------------------------------------------
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// Again, include the LogEvent script
(use "logevent")

// Change the getinput method to look like this:

(method (getInput pEvent)
(var prevSound, strLen)
(if(<> (send pEvent:type) evKEYBOARD)
= inputStr 0
)

// this allows for replaying the typed text into the input window
(if (== gEventEvent EVENT_PARSEOPEN and == gLogAction REPLAY_LOG)
= gEventClaimed TRUE
QueueEvent() // parser close
StrCpy(@inputStr @gEventMsg)
(send pEvent:message(@gEventMsg)) // set the input in input box (from parser close event)
)(else
(if(<> (send pEvent:message) echo)
Format(@inputStr "%c" (send pEvent:message))
)
)
= prevSound (Sound:pause(blocks))
= strLen EditPrint(@inputStr maxInputLen prompt #at x y)

(Sound:pause(prevSound))
return(strLen)
)

// And the handleEvent method:

(method (handleEvent pEvent)
(var evType, origKey)
(if(send pEvent:type)
= gUserEvent pEvent
= evType (send pEvent:type)

= origKey (send pEvent:message) // get the original key input, prior to it being manipulated in mapKeyToDir

(if(mapKeyToDir)
MapKeyToDir(pEvent)
)
(if(TheMenuBar)
(TheMenuBar:handleEvent(pEvent evType))
)

GlobalToLocal(pEvent)

(if(not (send pEvent:claimed))
(send gGame:handleEvent(pEvent evType))
)

(if(controls and (not (send pEvent:claimed))
and (send gCast:contains(alterEgo)))
(send alterEgo:handleEvent(pEvent))
)

// logs ego events (mouse clicks and keyboard movements
(if((send pEvent:claimed) and == gLogAction SAVE_LOG)
(send pEvent:message(origKey))
LogEvent(pEvent "ego")
)

(if(canInput and not(send pEvent:claimed))
(if( (== (send pEvent:message) echo) or (<= $20 (send pEvent:message)) and (<= (send pEvent:message) 255))
(if( (self:getInput(pEvent)))

// logs the closing of the parser
(if (== gLogAction SAVE_LOG)
LogEvent(pEvent "parseClose" @inputStr)
)

(if(Parse(@inputStr pEvent))
(send pEvent:type(evSAID))
(self:said(pEvent))
)
)
)

)
// for handling the titlescreen events
(if (== canInput FALSE and not(send pEvent:claimed) and == gLogAction SAVE_LOG)
LogEvent(pEvent "game")
)

)
= gUserEvent NULL
)
</syntaxhighlight>
 
------------------------------------------------------------------------
Main.sc
------------------------------------------------------------------------
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
// Include logevent again:
(use "logevent")

// Add these local variables:
// Logging variables
gLogLineSize = 116
gLogAction = NO_LOG
gLogFileName[50]
gEventTicks
gEventEvent
gEventX
gEventY
gEventKey
gEventMsg[51]
gLogFileHandle
gEventClaimed = TRUE

// At the bottom of the init() method in the Game instance, add ONE of the following code blocks,
// depending whether you want to log events or replay a log file:

// for logging events
= gLogAction SAVE_LOG
Format(@gLogFileName "logs\\log%d" Abs(GetTime(gtTIME_OF_DAY)))
= gLogFileHandle FOpen(@gLogFileName fOPENFAIL)

// for replaying events
= gLogAction REPLAY_LOG
StrCpy(@gLogFileName "logs\\LOG19736") // change this to the log file of your choice
= gLogFileHandle FOpen(@gLogFileName fOPENCREATE)
= gEventEvent -1
= gEventTicks -1

// At the bottom of the doit() in your Game instance, add this:

// enables replaying of the log
(if (== gLogAction REPLAY_LOG)
ReplayLog()
)
</syntaxhighlight>
 

[[Category:Examples]]

Timing change for death handler script (Dying.sc)

2013-11-02T02:44:02Z

Jeremiah Nellis:

''Originally posted on the [[scipf:topic,665.html|SCI Programming Forums]] by [[Gumby]].''

I just utilized the dying.sc script for the first time and I immediately noticed that there is a significant delay between calling the the script and the death 'screen' popping up.

This is by design, but I didn't like the fact that the delay length was hard-coded into script. Making a few modifications, I exposed the delay property for the script:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
(instance public DyingScript of Script
(properties
seconds 3 // Exposed this property (just by adding it here),
) // which is inherited from the Script class & set the default to 3

(method (changeState newState)
(var mbResult, message)
= state newState
(if(== state 0)
ProgramControl()
(send gTheMusic:fade())
(send gRoom:setScript(0))
Load(rsSOUND 2)
//= seconds 3 // Commented out this line, which set the delay to 3 seconds
)(else
(if(== state 1)
...
</syntaxhighlight>
 

So now, when I call the dying script, I can specify seconds like so:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci">
(send dyingScript:
caller(802)
seconds(1) // You can set this to however long you wish, based on your animation length
register("You are dead.")
)
</syntaxhighlight>
 
If you need more granularity than seconds, it would be simple to expose the 'cycles' property instead of the 'seconds' property in the Script class, then change the dying script to use cycles instead of seconds.

[[Category:Examples]]

Timing change for death handler script (Dying.sc)

2013-11-02T02:41:22Z

Jeremiah Nellis: Created page with "''Originally posted on the SCI Programming Forums by Gumby.'' I just utilized the dying.sc script for the first time and I immediately noticed ..."

SCI Specifications: Chapter 3 - The Graphics subsystem

2013-06-22T23:57:24Z

Jeremiah Nellis: /* The SCI font resource */

==General stuff==
The graphics in SCI are generated using four resource types:

* Pic resources for background pictures
* View resources for images
* Font resources for drawing text
* Cursor resources for displaying the mouse pointer

Those resources are drawn on three distinct maps:

* The visual map, used for displaying the actual pictures the player sees
* The priority map, which keeps information about how the depth of the screen
* The control map, which contains special information

==SCI Ports==

'''Lars Skovlund'''

Version 1.0, 6. July 1999

Note that the observations made in this document are generally based on SCI version 0.000.572 (the one that comes with LSL3), but should be valid even for SCI01 and SCI1, as well. I know already about some differences in the port system from SCI0 to SCI1, but I feel we should have an interpreter running for SCI0 before dealing with SCI1.

This article discusses a key data structure in SCI graphics handling; this data structure is called a port, and it is involved in most graphics-related operations. The port is basically a graphics state record, storing things like pen color, current font, cursor position etc. Each port also has an origin and a size. The actual port data structure has remained absolutely unchanged from SCI0 up to the latest versions of SCI1.

The port can be viewed as a rectangle in which things are drawn. Every drawing operation (even KDrawPic) is executed relative to the origin coordinates of the current port (depending on the kernel function, other parameters in the port structure are used as well), such that coordinate (0, 0) in the "picture window" (such a thing really exists in SCI!) is not the top of the screen, but rather the leftmost point underneath the menu bar. The coordinate set (0,0) is called the local coordinates, and its physical position on the screen, (0, 10), is called the global coordinates. Kernel calls exist to ease conversion between the two coordinate systems, but they are, it appears, meant for event handlers to use, and not generally usable (I think they take a pointer to an Event object as a parameter).

At least three ports are created and managed automatically by the SCI interpreter. These are the "window manager" port, the menu port, and the picture port (which is actually a window, see later). The latter two should be fairly easy to understand. The menu bar is drawn in the menu port, and the current room is drawn in the picture port. What may be less obvious is that the window manager port is an "invisible" port, on which the window backgrounds are drawn, although the windows have a port themselves. If you are familiar with Windows™ programming, the term "client rectangle" may ring a bell here - SCI draws the window backgrounds, using values in the window manager port, while the window's own port controls what is drawn inside it. The window manager port covers the same bounding rectangle as the picture window, but it is transparent so it doesn't mess up the graphics.

I feel compelled to mention windows for a bit here, not in depth - they are the subject of a later article - but just to mention that the structure used to manage windows is just an extension of the port structure. Whenever an SCI system call needs a pointer to a port structure, a pointer to a window structure will do. This implicates that the SysWindow class (which implements windows) has no "port" property. Instead, its "window" property points to the extended port/window structure which can safely be passed to KSetPort. Not surprisingly, many of KNewWindow's arguments end up in the port part of the window structure.

An SCI program can't directly instantiate a port. If a program wants to access a specific part of the screen using ports, it has to instantiate a transparent window. In fact, SCI creates the picture window using RNewWindow, the same function that the kernel call KNewWindow ends up calling, asking for an untitled window with a transparent background - but more on that in a later article.

It must be stressed that ports are purely internal structures. Although a program can select different ports to draw in, the data structures themselves are absolutely off-limits to SCI code. KNewWindow fills a port structure with user-supplied data, but there is no way of changing that data, short of dis- posing the window and instantiating it again. The structure is frequently changed by SCI itself, though.

Only two kernel calls deal directly with ports:

KGetPort (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x14:_GetPort.28.29|the Section called Kernel function 0x14: GetPort() in Chapter 5]])<br>
KSetPort (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x15:_SetPort.28.29|the Section called Kernel function 0x15: SetPort() in Chapter 5]])

These two functions are often used in pairs (also internally), like:

<pre>var temp;

temp=KGetPort(); /* Save the old port */
KSetPort(...); /* Activate some other port */
.. /* Draw some stuff */
KSetPort(temp); /* Reactivate the old port */</pre>

==The Cursor resource==

This resource stores a simple bitmap describing the shape and texture of the mouse pointer. All information stored herein is little endian in byte order.

0x00 - 0x01

:: X coordinate of the mouse cursor hot spot as a 16 bit integer. This variable is not used in SCI0.

0x02 - 0x03

:: Y coordinate of the mouse cursor hot spot as a 16 bit integer. Only 0x03 is used in SCI0; here, if set, the hot spot is at (8,8), if not set, it is located at (0,0).

0x04 - 0x23

:: This is a list of 16 unsigned 16 bit integers constituting bitmasks for the mouse cursor's transparency map, with the MSB representing the leftmost pixel.

0x24 - 0x43

:: This is another list of 16 unsigned 16 bit integers. Each of them represents another bitmask, determining whether the mouse cursor pixel should be drawn in black (not set) or white (set).

To determine whether or not to draw a pixel, and, if it is to be drawn, in which color it should be drawn in, the corresponding bits of both bitmask lists mentioned above have to be examined. In the table below, A represents a bit from the first list, and B the corresponding bit from the lower list.

 

===Color mapping for the SCI0 mouse pointer===

<blockquote>
{| class="wikitable" width="150"
|-
! align="center" width="25" | AB
! width="120" | Result
|-
| align="center" width="25" | 00
| width="120" | Transparent
|-
| align="center" width="25" | 01
| width="120" | Transparent
|-
| align="center" width="25" | 10
| width="120" | 0x00 (Black)
|-
| align="center" width="25" | 11
| width="120" | 0x0f (White)
|}
</blockquote>

 

===Color mapping for the SCI1 mouse pointer===

Since this method of doing things wastes one combination, the table was changed for SCI01 and SCI1:

<blockquote>
{| class="wikitable" width="150"
|-
! align="center" width="25" | AB
! width="120" | Result
|-
| align="center" width="25" | 00
| width="120" | Transparent
|-
| align="center" width="25" | 01
| width="120" | 0x0f (White)
|-
| align="center" width="25" | 10
| width="120" | 0x00 (Black)
|-
| align="center" width="25" | 11
| width="120" | 0x07 (Light Gray)
|}
</blockquote>

 

==The SCI0 View Resource==

In SCI0, Views are collections of images or sprites. Each View resource contains a number of groups, which, in turn, contain one or more images. Usually, those groups contain a number of consecutive animation frames. It appears to be customary to store related animations or images in a single frame. For example, the basic movements of all protagonists (four or eight animation cycles (depending on the game)) are stored inside of a single View resource. Please note that the byte order of the following data is always little endian.

===The View Resource===

0x00 - 0x01

:: The number of image groups available.

0x02 - 0x03

:: A bitmask containing the 'mirrored' flag for each of the groups, with the LSB containing the 'mirrored' flag for group 0.

0x04 - 0x07

:: - unknown -

0x08...

:: A list of indices pointing to the start of the cell list for each image group. The number of entries is equal to the number of cells as described in 0x00 -

0x01.

===Cell List===

0x00 - 0x01

:: The number of image cells available for this group.

0x02 - 0x03

:: - unknown -

0x04...

:: A list of 16 bit pointers indexing the start of the image cell structure for each image cell. The pointers are relative to the beginning of the resource data.

===Image Cell===

0x00 - 0x01

:: The horizontal (X) size of the image.

0x02 - 0x03

:: The vertical (Y) size of the image.

0x04

:: The x placement modifier. This signed value determines the number of pixels a view cell is moved to the right before it is drawn.

0x05

:: The y placement modifier. This signed value determines the number of pixels a view cell is moved downwards before it is drawn.

0x06

:: The color key, i.e. the color number used for transparency in this cell.

0x07...

:: A list of combined color/repeat count entries. Each byte contains a color entry (low nibble) and a repeat count (high nibble). If the color is equal to the color key from index 0x06, then no drawing should be performed, although [repeat] pixels still need to be skipped. It is not known whether this list is terminated; the FreeSCI drawing algorithm stops drawing as soon as the rectangle defined in the first two cell entries has been filled.

==The SCI font resource==

SCI font resources remained unchanged during the SCI revisions and were still used in SCI32. Their format is relatively straightforward and completely sufficient for any 8 or even 16 bit character table:
<div id="AEN2349"></div>
'''Table 3-1. The SCI font resource data structure'''

{| class="wikitable" width="760"
|-
! width="85" align="center" | Offset
! width="235" | Type
! width="440" | Meaning
|-
| width="85" align="center" | 0
| width="235" | 16 bit integer, little endian encoding
| width="440" | Always zero (?)
|-
| width="85" align="center" | 2
| width="235" | 16 bit integer, little endian encoding
| width="440" | NUMCHAR: Number of characters
|-
| width="85" align="center" | 4
| width="235" | 16 bit integer, little endian encoding
| width="440" | HEIGHT: Number of pixel lines per text line
|-
| width="85" align="center" | 6 + NR * 2
| width="235" | 16 bit integer, little endian encoding
| width="440" | Absolute offset of the character #NR, where 0 <= NR < NUMCHAR
|}

HEIGHT does not affect the height of a character, though- it only tells the interpreter how far to move downwards when displaying a line of text. The characters referenced to starting at offset 6 are encoded as follows:
<div id="AEN2375"></div>
'''Table 3-2. The SCI font resource character data structure'''

{| class="wikitable" width="760"
|-
! width="85" align="center" | Offset
! width="235" | Type
! width="440" | Meaning
|-
| width="85" align="center" | 0
| width="235" | unsigned 8 bit integer
| width="440" | character <span style="color: red; text-decoration: line-through;">HEIGHT</span> WIDTH
|-
| width="85" align="center" | 1
| width="235" | unsigned 8 bit integer
| width="440" | character <span style="color: red; text-decoration: line-through;">WIDTH</span> HEIGHT
|-
| width="85" align="center" | 2...
| width="235" | bitmask, size HEIGHT * round_up(WIDTH / 8)
| width="440" | Bitmask for the character
|}

The bitmap consists of HEIGHT lines of n bytes, where n equals the number of bytes required for storing WIDTH bits. Data is stored with the MSB first, in little-endian encoding (first byte describes the 8 leftmost pixels), where a pixel is drawn iff the bit it corresponds to is set.

==The SCI0 and SCI01 pic resource==

The pic (background picture) resource format used in SCI0 is rather complex in comparison to the other graphical resource formats. It is best described as a sequence of drawing operations on a set of four 320x200 canvases, three of which are later used in the game (visual, priority, and control), and one of which is used during the drawing process for auxiliary purposes<ref group=Note>Due to the vector graphics nature of these drawing operations, they are inherently more scaleable than pixmaps.</ref>.

Note hereIn order to describe the process, we will first need to define a set of operations we base them on:

<pre>FUNCTION peek_input(): Byte; /* returns the byte pointed to by the input pointer */
FUNCTION get_input(): Byte; /* works like peek_input(), but also increminates the
** input pointer */
FUNCTION skip_input(x): Byte; /* skips x input bytes */</pre>

Using these pre-defined functions, we will now define additional helper functions used for reading specifically encoded data tuples:

<pre>FUNCTION GetAbsCoordinates(): (Integer, Integer)
VAR
x, y, coordinate_prefix : Integer;
BEGIN
coordinate_prefix := get_input();
x := get_input();
y := get_input();
x |= (coordinate_prefix & 0xf0) << 4;
y |= (coordinate_prefix & 0x0f) << 8;

RETURN (x,y)
END

FUNCTION GetRelCoordinates(x : Integer, y: Integer): (Integer, Integer)
VAR
input : Integer;
BEGIN
input := get_input();
IF (input & 0x80) THEN
x -= (input >> 4);
ELSE
x += (input >> 4);
FI

IF (input & 0x08) THEN
y -= (input & 0x7);
ELSE
y += (input & 0x7);
FI

RETURN (x,y)
END</pre>

We also need some data types based on EGACOLOR and PRIORITY, which can be thought of as integers:

<pre>TYPE Palette = ARRAY[0..39] of EGACOLOR[0..1]
TYPE Priority_Table = ARRAY[0..39] of PRIORITY

Palette default_palette =
<(0,0), (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7),
(8,8), (9,9), (a,a), (b,b), (c,c), (d,d), (e,e), (8,8),
(8,8), (0,1), (0,2), (0,3), (0,4), (0,5), (0,6), (8,8),
(8,8), (f,9), (f,a), (f,b), (f,c), (f,d), (f,e), (f,f),
(0,8), (9,1), (2,a), (3,b), (4,c), (5,d), (6,e), (8,8)>;

#define DRAW_ENABLE_VISUAL 1
#define DRAW_ENABLE_PRIORITY 2
#define DRAW_ENABLE_CONTROL 4

#define PATTERN_FLAG_RECTANGLE 0x10
#define PATTERN_FLAG_USE_PATTERN 0x20</pre>

And now for the actual algorithm:

<pre>FUNCTION DrawPic (cumulative, fill_in_black : Boolean; default_palette: Integer; visual_map, priority_map, control_map, aux_map : Map): Map^4
VAR
palette : Array [0..3] of Palette;
drawenable, priority, col1, col2, pattern_nr, pattern_code : Integer;
BEGIN
palette := (default_palette × 4);
drawenable := DRAW_ENABLE_VISUAL | DRAW_ENABLE_PRIORITY
priority := 0;
col1 := col2 := 0;
pattern_nr := 0;
pattern_code := 0;

IF (!cumulative) THEN BEGIN
visual_map := (0xf × 320 × 200);
map control := map priority := map aux := (0 × 320 × 200);
END

FOREVER DO BEGIN

opcode := get_input();

COND opcode:
0xf0 → /* PIC_OP_SET_COLOR */
code := get_input();
(col1, col2) := palette[default_palette + (code / 40)][code % 40];
drawenable |= DRAW_ENABLE_VISUAL;

0xf1 → /* PIC_OP_DISABLE_VISUAL */
drawenable &= ~DRAW_ENABLE_VISUAL;

0xf2 → /* PIC_OP_SET_PRIORITY */
code := get_input();
priority := code & 0xf;
drawenable |= DRAW_ENABLE_PRIORITY;

0xf3 → /* PIC_OP_DISABLE_PRIORITY */
drawenable &= ~DRAW_ENABLE_PRIORITY;

0xf4 → /* PIC_OP_RELATIVE_PATTERNS */
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f
FI

(x,y) := GetAbsCoordinates();

DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);

WHILE (peek_input() < 0xf0) DO BEGIN
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f
FI
(x,y) = GetRelCoordinates(x,y);
DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);
END

0xf5 → /* PIC_OP_RELATIVE_MEDIUM_LINES */
(oldx, oldy) := GetAbsCoordinates();
WHILE (peek_input() < 0xf0) DO BEGIN
temp := get_input();
IF (temp & 0x80) THEN
y := oldy - (temp & 0x7f)
ELSE
y := oldy + temp
FI
x = oldx + get_input();
DitherLine(oldx, oldy, x, y, col1, col2, priority, special, drawenable);
(oldx, oldy) := (x, y);
END

0xf6 → /* PIC_OP_RELATIVE_LONG_LINES */
(oldx, oldy) := GetAbsCoordinates()
WHILE (peek_input() < 0xf0) DO BEGIN
(x, y) := GetAbsCoordinates();
DitherLine(oldx, oldy, x, y, col1, col2, priority, special, drawenable);
(oldx, oldy) := (x, y);
END

0xf7 → /* PIC_OP_RELATIVE_SHORT_LINES */
(oldx, oldy) = GetAbsCoordinates()
WHILE (peek_input() < 0xf0) DO BEGIN
(x, y) := GetRelCoordinates(oldx, oldy);
DitherLine(oldx, oldy, x, y, col1, col2, priority, special, drawenable);
(oldx, oldy) := (x, y);
END

0xf8 → /* PIC_OP_FILL */
IF (fill_in_black) THEN
(oldc1, oldc2) := (c1, c2);
FI

WHILE (peek_unput() < 0xf0) DO BEGIN
(x, y) := GetAbsCoordinates();
DitherFill(x, y, col1, col2, priority, special, drawenable);
END

IF (fill_in_black) THEN
(c1, c2) := (oldc1, oldc2);
FI

0xf9 → /* PIC_OP_SET_PATTERN */
pattern_code := get_input() & 0x37;
pattern_size := pattern_code & 0x7;

0xfa → /* PIC_OP_ABSOLUTE_PATTERNS */
WHILE (peek_input() < 0xf0) DO
IF (pattern_code & PATTERN_FLAG_USE_PATTERN)
pattern_nr := (get_input() >> 1) & 0x7f
FI
(x, y) := GetAbsCoordinates();
DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);
END

0xfb → /* PIC_OP_SET_CONTROL */
control := get_input() & 0x0f;
drawenable |= DRAW_ENABLE_CONTROL;

0xfc → /* PIC_OP_DISABLE_CONTROL */
drawenable &= ~DRAW_ENABLE_CONTROL;

0xfd → /* PIC_OP_RELATIVE_MEDIUM_PATTERNS */
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f;
FI

(oldx, oldy) := GetAbsCoordinates();

DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);

WHILE (peek_input() < 0xf0) DO BEGIN
IF (pattern_code & PATTERN_FLAG_USE_PATTERN) THEN
pattern_nr := (get_input() >> 1) & 0x7f;
FI

temp := get_input();
IF (temp & 0x80)
y := oldy - (temp & 0x7f)
ELSE
y := oldy + temp
FI
x := oldx + get_input();
DrawPattern(x, y, col1, col2, priority, control, drawenable,
pattern_code & PATTERN_FLAG_USE_PATTERN,
pattern_size, pattern_nr, pattern_code & PATTERN_FLAG_RECTANGLE);
END

0xfd → /* PIC_OP_OPX */
COND get_input():
0x00 → /* PIC_OPX_SET_PALETTE_ENTRY */
WHILE peek_input() < 0xf0 DO BEGIN
index := get_input();
color := get_input();
palette[index / 40][color % 40] := color;
END

0x01 → /* PIC_OPX_SET_PALETTE */
palette_number := get_input();
FOR i := 0 TO 39 DO
palette[palette_number][i] := get_input();
OD

0x02 → /* PIC_OPX_MONO0 */
skip_input(41);

0x03 → /* PIC_OPX_MONO1 */
skip_input(1);

0x04 → /* PIC_OPX_MONO2 */
0x05 → /* PIC_OPX_MONO3 */
skip_input(1);

0x06 → /* PIC_OPX_MONO4 */
0x07 → /* PIC_OPX_EMBEDDED_VIEW */ /* SCI01 operation */
0x08 → /* PIC_OPX_SET_PRIORITY_TABLE */ /* SCI01 operation */

0xff → return (visual, control, priority, aux);
END OF COND
END
END</pre>

'''This algorithm uses three auxiliary algorithms, DrawPattern, DitherLine, and DitherFill, which are sketched below. All of these functions are supposed to take the four maps as implicit parameters.'''

<pre>PROCEDURE DrawPattern(x, y, col1, col2, priority, control, drawenable : Integer; solid : Boolean ; pattern_size, pattern_nr : Integer; rectangle : Boolean)</pre>

Alters (x,y) so that 0 <= (x - pattern_size), 319 >= (x + pattern_size), 189 >= (y + pattern_size) and 0 <= (y - pattern_size), then draws a rectangle or a circle filled with col1, col2, priority, control, as determined by drawenable.

If rectangle is not set, it will draw a rectangle, otherwise a circle of size pattern_size. pattern_nr is used to specify the start index in the random bit table (256 random bits)

<pre>PROCEDURE DitherLine(x, y, xend, yend, color1, color2, priority, control, drawenable : Integer)</pre>

Draws a dithered line between (x, y+10) and (xend, yend+10). If the appropriate drawenable flags
are set, it draws 'priority' to the priority map, 'control' to the control map, and 'color1' and 'color2'
(alternating) to the visual map. The auxiliary map is bitwise-or'd with the drawenable flag while this is
done.

<pre>PROCEDURE DitherFill(x, y, col0, col1, priority, control, drawenable : Integer)</pre>

Fills all layers for which drawenable is set with the appropriate content. Diagonal filling is not allowed. Boundaries are determined as follows:

<x<0, x>319, y<10, y>199 are hard boundaries. We now determine the 'boundary map' bound_map and the allowed color legal_color. If bound_map[coordinates] = legal_color, then the pixel may be filled.

<pre>IF (drawenable & DRAW_ENABLE_VISUAL)
bound_map = visual;
legal_color = 0xf;
ELSIF (drawenable & DRAW_ENABLE_PRIORITY)
bound_map = priority;
legal_color = 0;
ELSIF (drawenable & DRAW_ENABLE_CONTROL)
bound_map = control;
legal_color = 0;
ELSE
return;
FI</pre>

==Windows, Dialogs and Controls==

'''by Lars Skovlund'''

Version 1.0, 7. July 1999

I am going to start by mentioning the menus. It has nothing to do with the material I deal with in this essay. They use different kernel calls, and such things as port management are handled internally by the kernel routines. The SCI program just sets up a menu structure using the kernel calls. Since they are irrelevant to the subject of this essay, I will not spend more time on them.

The Rect structure is important (also to ports) since it is the basis for passing a screen position to the interpreter. It looks like this:

<pre>typedef struct
{
short top, left, bottom, right;
}</pre>

It will be seen from this that rectangle coordinates in SCI are not normally represented in the usual (x,y,width,height) fashion. So pay close attention to this structure! Also, it is not passed as a pointer, but rather as the four values in order. This is particularly true of SCI objects, where the property names nsTop etc. actually form a Rect structure which can be used directly by the interpreter.

Windows are created using the KNewWindow kernel function. Each window has six attributes which are passed from the script to the kernel function:

Bounding rectangle<br>
Title<br>
Type<br>
Priority<br>
Foreground color<br>
Background color

Of these, the type and priority are the most interesting, because they decide the appearance of the window. The type is a bit field:

bit 0 - transparency<br>
bit 1 - window does _not_ have a frame<br>
bit 2 - the window has a title<br>
bit 3-6 - unused<br>
bit 7 - see below

Bit 0 specifies a transparent window. KNewWindow does not save the image behind the created window - it stays on the screen until the pic is redrawn, so windows with this style definitely can't be used as message boxes. It does have some special uses, though. If this bit is not set, KNewWindow draws a rectangle in the specified background color using the bounding rectangle coordinates (using the WM port). When this bit is set,

Bit 1 specifies a window without a frame. The frame is the black shading you can see in the corner of a message box.

Bit 2 tells KNewWindow to draw a grey title bar with a title printed in white. In the version I have used for this essay, it is not possible to change the title bar colors. Note that the bounding rectangle is always specified as if the window had no title bar. If this bit is set, ten pixels are reserved above the coordinates specified. Although this bit is set, the Title parameter may still be NULL. If this is the case, an empty title bar is drawn.

Bit 7 has a special meaning; it is used only in window type 0x81, and is not tested in any other way. When this style is chosen, KNewWindow does not draw anything at all. It is the caller's responsibility to draw a window frame on the WM port. CB1 uses this style for its ornate windows, and draws the frame manually.

The picture window which I mentioned in the last article is created using style 3 (that is, TRANSPARENT | NOFRAME). The normal message box styles used in LSL3 are 0 and 4.

I have not been able to investigate the priority property yet, so the fol- lowing is based on suppositions. It is only used when drawing transparent windows. In this case, if priority is not -1 (which means not used), the window is drawn onto the priority map (with the specified priority value) as well as the screen.

There is a class called SysWindow which is just a simple wrapper around the following two kernel calls. Try breaking on SysWindow::open, then type c to inspect the current object. You can change all the parameters to KNewWindow (the Rect is split in its fields, to nsTop, nsLeft etc.)

To create a window structure, use KNewWindow (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x13:_NewWindow.28Rect.2C_HeapPtr.2C_word.2C_word.2C_word.2C_word.29|the Section called Kernel function 0x13: NewWindow(Rect, HeapPtr, word, word, word, word) in Chapter 5]]); to remove it again, apply KDisposeWindow (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x16:_DisposeWindow.28HeapPtr_Window.29|the Section called Kernel function 0x16: DisposeWindow(HeapPtr Window) in Chapter 5]]) on it.

So how do we put stuff inside these windows? That question is a little complicated to answer, because it is really a shared effort between the interpreter and the object hierarchy, and this is one case where the interpreter actually interacts with the objects itself. I will start by explaining the classes involved.

All control types are descendants of a common class (I do not know its name, since it appears to have an invalid name property). Among other things, this common class contains a type number and a state. The type number is the only thing that distinguishes the control types from each other inside the interpreter - if a wrong type is set, the interpreter might try to change a non-existent property.

The type numbers are laid out as follows:

# - Button control
# - Text control
# - Edit control
# - Icon control
# - not used
# - Selector control (as in the Save and Restore boxes)

The gauge "controls" are not really controls. I don't know how they work (yet).

Each control also has a state value. These are laid out as follows:

: bit 0 - selectable. If this bit is set, the control can be selected using the Tab key. Except for the text and icon controls, all controls are selectable.<br>
: bit 1 - unknown. Always set, except for the text and icon controls<br>
: bit 2 - disabled. When this bit is set, a button is grayed out. No other control types are affected.<br>
: bit 3 - selected. When this bit is set, a frame is drawn around the control.

Note that state 3 is by far the most common. With that explained, I'll move on to the kernel functions. There are three functions associated with controls - KDrawControl (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x17:_DrawControl.28HeapPtr.29|the Section called Kernel function 0x17: DrawControl(HeapPtr) in Chapter 5]]), KHiliteControl (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x18:_HiliteControl.28HeapPtr.29|the Section called Kernel function 0x18: HiliteControl(HeapPtr) in Chapter 5]]) and KEditControl (see [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x19:_EditControl.28HeapPtr.29|the Section called Kernel function 0x19: EditControl(HeapPtr) in Chapter 5]]). Note that there is a KOnControl kernel call which is entirely unrelated to window management.

The dialogs are implemented using not one, but two classes - Dialog and Window. While the Window class maintains the window (It is derived from SysWindow), the Dialog class is just a list of controls. It is derived from the List class, but has extended functionality to tell its members to redraw etc. There is a special function, located in script 255, which allows scripts to push information about the dialog on the stack instead of creating the Dialog object manually.

:: '''''Note''' that the internal debugger uses the same window calls as the SCI script. That is why the screen messes up if you step through drawing code - the debugger has activated the Debug window port, and "forgets" to switch back while stepping across instructions. Thus, all graphics commands are redirected to the debug window port. Not a pretty sight.''

==Pictures and movement control==

'''By Lars Skovlund'''

Version 1.0, 24. July 1999

A pic in SCI consists of three layers (called maps - they are unrelated to the map resources found in SCI1 games). The visual map, used for the picture which appears on the user's screen. The priority map which tells the interpreter which things go in front of which in the three-dimensional room. Without the priority map, a room would just be a flat, painted surface. The control map decides where game characters (called actors) can walk and where special events occur. These special events are triggered by a game character walking on a particular spot. Where the visual map is almost always very complex and using dithered fills etc., the latter two consist of large areas of solid color.

Many functions which need to access these maps do so by using a bit-field. The bits are laid out as follows (but don't set more than one at a time!)

bit 0 - Visual<br>
bit 1 - Priority<br>
bit 2 - Control

It is important to understand that, although being represented as colors on the screen, a priority/control "color" should be considered a number. The colors map to values according to the standard EGA color values.

Every animated object in SCI has a priority. As the object moves, its pri- ority changes according to the so-called priority bands, explained next (it is, however, possible for a script to lock the priority of a view). The picture window is divided vertically into 16 priority bands. The priority of an animated object is determined by the position of its "base rectangle" in one of these bands. Things are drawn in order of ascending priority, so objects with priority 15 are guaranteed to be in front of everything else. The default priority mapping gives priority 0 a fairly large space, the 42 topmost rows (including the menu bar which AFAIK is 10) in the picture. All other priority bands have the same size. A script can choose to alter this mapping, specifying the amount of space to assign to priority 0, and the number of the last row to include in the mapping calculation.

In most rooms, it is desirable to limit actor movement, confining the actor to a specific part of the screen. In other cases, special events are triggered by movement into a specific screen area. On some occasions, even room switches are implemented using control polygons. While the meaning of priorities is determined by the kernel, the meaning of control values is entirely up to the script. It is more or less a standard, however, that actors can't walk on white control areas.

As the control map is not consulted by the interpreter itself (except in a few cases), scripts need a way to do so. That way is called OnControl, and it is a kernel call. Supplied with a point or a rectangle, it returns a bit mask containing the control values of all the pixels in the desired region. If a specific control value is encountered, it is used as a bit number, and that bit is set in the output mask.

This bit mask system is also used in another place, namely the illegalBits selector of the Act (actor) class. The illegalBits selector determines in which areas the actor may not walk.

The OnControl() system call is explained in [[SCI_Specifications:_Chapter_5_(cont.)_-_Kernel_functions#Kernel_function_0x52:_OnControl.28word.2C_Point_.7C_Rect.29|the Section called Kernel function 0x52: OnControl(word, Point | Rect) in Chapter 5]].

;Notes
<references group=Note/>

 

<span style="float: left">[[SCI Specifications: Chapter_2_-_Resource_files|< Previous: Chapter 2 - Resource files]]</span><span style="float: right">[[SCI Specifications: Chapter_4_-_The_Sound_subsystem|Next: Chapter 4 - The Sound subsystem >]]</span>

 

[[Category:Control Areas]]
[[Category:SCI Resources]]
[[Category:Sierra Creative Interpreter Specifications]]

Brian Provinciano's SCI Tools

2012-10-20T18:29:24Z

Jeremiah Nellis: /* Gumby's SCI Tools */

===Gumby's SCI Tools===

SCI Development Tools by Gumby (all tools are for SCI0 games unless otherwise specified)

'''Said() String Generator''' - (based on desired user input) for development of SCI0 games
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCISaidGen.zip|SCISaidGen]]<span class="DLInfo"> (ZIP file) [2651 KB]</span>
</blockquote>
'''SCI Text Dumper''' - Dumps all text resources & then runs them through a spelling & grammar checker prior to finally loading the text resources back in.
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCITextDumper.zip|SCITextDumper]]<span class="DLInfo"> (ZIP file) [2735 KB]</span>
</blockquote>
'''SCI Vocab Editor''' - Extracts the vocabulary for a game into Excel format for manipulation & then 're-loads' the updated vocab back into the game.
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCIVocabEditor.zip|SCIVocabEditor]]<span class="DLInfo"> (ZIP file) [2993 KB]</span>
</blockquote>
'''Dummy Script Compiler''' - Utility to workaround initial compilation of scripts that contain circular dependencies (via 'use' inclusion).
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/dummyScriptCompiler.zip|DummyScriptCompiler]]<span class="DLInfo"> (ZIP file) [2993 KB]</span>
</blockquote>
'''Recreate MAP File''' - Utility to recreate a .MAP file based on a set of RESOURCE.XXX (001, 002, etc) files.
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/recreateMapFile.zip|RecreateMapFile]]<span class="DLInfo"> (ZIP file) [2993 KB]</span>
</blockquote>
'''ResDumpPack''' - Utility to dump & pack resources to/from RESOURCE.XXX files.
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/resDumpPack.zip|ResDumpPack]]<span class="DLInfo"> (ZIP file) [2993 KB]</span>
</blockquote>
'''SCI Digital Sound Pack 1 - Doors''' - Digital sounds to be used with SNDBLAST.DRV sound driver
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCIDigitalSoundPack1-Doors.zip|SCI Digital Sound Pack 1 - Doors]]<span class="DLInfo"> (ZIP file) [701 KB]</span>
</blockquote>
'''SCI Digital Sound Pack 2 - Animals''' - Digital sounds to be used with SNDBLAST.DRV sound driver
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCIDigitalSoundPack2-Animals.zip|SCI Digital Sound Pack 2 - Animals]]<span class="DLInfo"> (ZIP file) [2152 KB]</span>
</blockquote>
'''SCI Midi Pack 1 - Music''' - Midi music sounds to be used with SNDBLAST.DRV or MPUMIDI.DRV sound driver (possibly others)
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCIMidiPack1-Music.zip|SCI Midi Pack 1 - Music]]<span class="DLInfo"> (ZIP file) [378 KB]</span>
</blockquote>
'''SCI0 32bit Sound Utilities (Snd2Mid, Mid2Snd, SndPrf, ExtractWav)''' - Port of Ravi's 16 bit utilities (Snd2Mid, Mid2Snd, SndPrf) to C# and a new utility ExtractWav
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCI032bitSoundUtils(Snd2Mid,Mid2Snd,SndPrf,ExtractWav).zip|SCI0 32bit Sound Utilities]]<span class="DLInfo"> (ZIP file) [37 KB]</span>
</blockquote>
'''SCI Narrate''' - Add a narrator to your SCI fan games. Leverages the Google Translate API.
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/SCI_Narrate.zip|SCI Narrate]]<span class="DLInfo"> (ZIP file) [44 KB]</span>
</blockquote>
'''Create Text Resources Tool''' - Parses all source script files & extracts all the Print() strings and puts them into text resources
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/CreateTextRes.zip|CreateTextRes]]<span class="DLInfo"> (ZIP file) [94 KB]</span>
</blockquote>

'''sciAudio''' - Play MP3/WAV sound files external to the SCI0 virtual machine.
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/sciAudio_1.0_with_source.zip|sciAudio]]<span class="DLInfo"> (ZIP file) [199 KB]</span>
</blockquote>

'''LockerGnome Quest Redux''' - Temporary home for this demo game until it can be moved to sciprogramming
<blockquote>
* [[Image:ZIP.GIF|ZIP File]][[SCI:Gumby/GnomeQuestRedux.zip|GnomeQuestRedux]]<span class="DLInfo"> (ZIP file) [plenty of KB]</span>
</blockquote>
 

[[category:SCI Tools]]

Looking with the right mouse button

2012-09-29T15:42:16Z

Jeremiah Nellis:

To accomplish this we will use the priority colors - you can use the control colors as well.

'''Step 1:''' Trace & fill all the objects in your room with a priority color. For immediately adjacent objects, use a different color.

'''Step 2:''' Determine the bounding rectangle around each object. This will allow you to re-use a priority color more than once per room. Note that you can have overlapping bounding rectangles for objects - just make sure that the objects have different priority colors. To aid with determining the coordinates of the rectangles, temporarily include the following code in your handleEvent method to give you the cursor hotspot location on a right-click:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(== (send pEvent:type) evMOUSEBUTTON and == (send pEvent:modifiers) 515)
FormatPrint("x:%d, y:%d" (send pEvent:x) (send pEvent:y) )
)
</syntaxhighlight>

'''Step 3:''' Modify your 'look' logic
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(Said('look/box')
or
( == (send pEvent:type) evMOUSEBUTTON // mouse click
and == (send pEvent:modifiers) 515 // specifically a right mouse click
and == $0002 OnControl(ocPRIORITY (send pEvent:x) (send pEvent:y)) // on NAVY priority color

// check that the mouse is in the bounding rectangle for this object
and > (send pEvent:x) 93
and < (send pEvent:x) 132
and > (send pEvent:y) 78
and < (send pEvent:y) 110
)
)
Print("The box is closed")
)
</syntaxhighlight>

Or for much cleaner implementation, create a class and then create instances of the class for each right-clickable area:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(class MouseLookObj
(properties
priorityColor $0000
xMin 0
xMax 0
yMin 0
yMax 0
)
(method (rightClicked pEvent)
MouseLook(pEvent)
)
)

(procedure (MouseLook pEvent) of MouseLookObj
(if (== (send pEvent:type) evMOUSEBUTTON
and == (send pEvent:modifiers) 515
and == priorityColor OnControl(ocPRIORITY (send pEvent:x) (send pEvent:y))
and > (send pEvent:x) xMin
and < (send pEvent:x) xMax
and > (send pEvent:y) yMin
and < (send pEvent:y) yMax)
return(TRUE)
)
return(FALSE)
)
</syntaxhighlight>

In your room script:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(instance public BoxLook of MouseLookObj
(properties
priorityColor $0002
xMin 93
xMax 132
yMin 78
yMax 110
)
)

....

(if(Said('look/box') or BoxLook:rightClicked(pEvent))
Print("The box is closed")
)
</syntaxhighlight>

Give the ego footstep sounds

2012-09-17T03:59:47Z

Jeremiah Nellis:

Here's how to do it, using the SNDBLAST or MTBLAST drivers. I created 4 separate WAV footstep sounds & appended them to 4 empty sound resources. Then in the room script, I added a doit() method which basically checks the current loop of the ego. On two of the cells, we trigger a random sound playback of one of the footsteps.

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(local
currentCel
previousCel
loop
)

...

(method (doit)
(var randomSound)
= currentCel (send gEgo:cel)

(if (<> currentCel previousCel)
= loop (send gEgo:loop)
= randomSound Random(0 3)

// ego is walking horizontally
(if(== loop 0 or == loop 1)
(if(== currentCel 0 or == currentCel 4)
(send gTheSoundFX:
prevSignal(0)
stop()
number(randomSound)
play()
)
)
)

// ego is walking vertically
(if(== loop 2 or == loop 3)
(if(== currentCel 3 or == currentCel 0)
(send gTheSoundFX:
prevSignal(0)
stop()
number(randomSound)
play()
)
)
)
)
= previousCel currentCel
)
</syntaxhighlight>
I did have to make a modification to the ego view in the template game. The 'vertical' animations (the ones where the ego is walking toward/away from you) only had 5 cells, which made the ego sound like he was hobbling. I added an additional cell to each loop which worked, but the result is that the ego appears to be dancing. Quite humorous.

I've uploaded the demo (with source code) to the fan games section.

[[Category:Examples]]

Robust Parse Part 3:Prepositions

2012-08-04T20:43:26Z

Jeremiah Nellis:

'''Robust Parse Part 3: Prepositions'''

Up to this point, we've sort of glossed over prepostions. I briefly touched on them in the first part of this series, when we took the verb 'climb' and created two different verb definitions so we could get differentiation between 'climb up' and 'climb down'. We also faked a bit of preposition handling by burying them inside our 'verb name' text resource.

So, what happens if we run the last Robust Parse demo game and try the following inputs:

look in<br/>
run with<br/>
listen to<br/>

You'll see that we get the same output as you would get if we simply typed 'look', 'run' or 'listen'. Well, this doesn't make much sense, does it? In order to address this shortcoming, we'll put in some additional parsing of the user input the same way we extract the adjectives and nouns. Again, I'm not going to post the code here, but download the newest Robust Parse demo & you can review the code there. The script which has been modified is the GetObjDescrip.

Next, we'll have to set up some additional parsing of said strings in the ParseVerb script. Here are the relevant sections for LOOK, RUN and LISTEN.

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/********** LISTEN **********/
(if(Said('listen/*/*>'))
= Verb VERB_LISTEN
= unneededSecond TRUE
)

(if(Said('listen<*/[/*]>')) // Here is our new Said() to handle prepositions
= Verb VERB_LISTEN
= needNoun TRUE
)

(if(Said('listen/*[/!*]>'))
= Verb VERB_LISTEN
)

(if(Said('listen[/!*]>'))
= Verb VERB_LISTEN
)

/********** EXAMINE **********/
(if(Said('(examine,look)/*/*>'))
= Verb VERB_LOOK
= unneededSecond TRUE
)

(if(Said('(examine,look)<*/[/*]>')) // Here is our new Said() to handle prepositions
= Verb VERB_LOOK
= needNoun TRUE
)

(if(Said('(examine,look)/*[/*]>'))
= Verb VERB_LOOK
)

(if(Said('(examine,look)[/*]>'))
= Verb VERB_LOOK
)

/********** RUN **********/
(if(Said('run/*/*>'))
= Verb VERB_RUN
= unneededNoun TRUE
= unneededSecond TRUE
)

(if(Said('run<*/[/*]>')) // Here is our new Said() to handle prepositions
= Verb VERB_RUN
= needNoun TRUE
)

(if(Said('run/*[/!*]>'))
= Verb VERB_RUN
= unneededNoun TRUE
)

(if(Said('run[/!*]>'))
= Verb VERB_RUN
)
</syntaxhighlight>

Next, we need to modify the RobustPragmaFail script. I've left the old code commented out to see the comparisons:

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/******************************************************************************
RobustPragmaFail.sc
******************************************************************************/
(include "sci.sh")
(include "game.sh")
/******************************************************************************/
(script ROBUSTPRAGMAFAIL_SCRIPT)

(use "main")
(use "controls")
/******************************************************************************/
(procedure public (RobustPragmaFail)
(if(== needNoun TRUE and == nounSaidCnt UNSET)
//FormatPrint("What do you want to %s?" VERB_NAMES Verb)
FormatPrint("What do you want to %s?" @verbDescrip)
return(TRUE)
)

(if(== needSecond TRUE and == secondSaidCnt UNSET)
//FormatPrint("What do you want to %s the %s with?" VERB_NAMES Verb @nounDescrip)
FormatPrint("What do you want to %s the %s with?" @verbDescrip @nounDescrip)
return(TRUE)
)

(if(== unneededNoun TRUE and <> nounSaidCnt UNSET)
//FormatPrint("I understood only as far as you wanting to %s." VERB_NAMES Verb)
FormatPrint("I understood only as far as you wanting to %s." @verbDescrip)
return(TRUE)
)

(if(== unneededSecond TRUE and <> secondSaidCnt UNSET)
//FormatPrint("I understood only as far as you wanting to %s the %s." VERB_NAMES Verb @secondDescrip)
FormatPrint("I understood only as far as you wanting to %s the %s." @verbDescrip @secondDescrip)
return(TRUE)
)

return(FALSE)
)
</syntaxhighlight>

As you can see, we've removed all the references to the VERB_NAMES text resource & replaced them with a string similar to our @nounDescrip and @secondDescrip. Finally, we need to change our VERB_NAMES text resources to only hold the verb names themselves. Before this, we occassionally putting verbs and prepositions in this text resource.

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.000 (verb names) *****************/
Num Text
------ -----
0 cut
1 run
2 dig
3 listen
4 look
5 run
6 climb
</syntaxhighlight>

In addition to cleaning up the VERB_NAMES text resource, we also need to create a new text resource for all the prepositions in our game.

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.004 (preposition names) *****************/
Num Text
------ -----
0 down
1 with
2 up
3 in
4 to
5 at
</syntaxhighlight>

Let's put it to the test. Fire up the Robust Parse demo game and try these inputs:

'look in' results in 'What do you want to look in?'<br/>
'run up' results in 'What do you want to run up?'<br/>
'listen to' results in 'What do you want to listen to?'<br/>

That's it! Now our game handles prepositions properly.

[[Category:The SCI Parser]]
[[Category:Examples]]
[[Category:Tutorials]]

Robust Parse Part 2:Object Disambiguation

2012-08-04T20:42:51Z

Jeremiah Nellis:

'''Robust Parse (Adjectives & Object Disambiguation)'''

'''Parsing nouns:'''<br/>
In our previous code for parsing nouns, we were setting the noun upon a successful match of a Said() string. Now, we will introduce the possibility of multiple nouns differentiated by the use adjectives. This means that potentially multiple nouns will be matched via multiple Said()s.

For review, we were previously parsing nouns (ParseNoun.sc) similar to this:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(Said('*/rock>'))
= noun ROCK_OBJ
)

(if(Said('*/window>'))
= noun WINDOW_OBJ
)
</syntaxhighlight>
We'll need to change our technique to this:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(Said('*/rock[<small]>'))
= nounSaid[++nounSaidCnt] SMALL_ROCK_OBJ
)

(if(Said('*/window[<center]>'))
= nounSaid[++nounSaidCnt] CENTER_WINDOW_OBJ
)
</syntaxhighlight>
First off, note that we have a new array 'nounSaid' (which is defined in the Main.sc) along with a counter of how many nouns we've matched (nounSaidCnt). I'd recommend making the array size roughly 10, which is an artificial maximum for the number of times a single noun can be duplicated in a game. By duplicated, I mean the same noun but differentiated with adjectives (e.g. gold key, silver key, copper key). You probably aren't going to have more than 10 different keys in a game, but I suppose you might. If you do, make it large enough to fit your needs.

Also see that we have now introduced adjectives & that they are optional. All of your nouns in your Said()s *must* include optional adjectives. If you do not specify an adjective, that means that any adjective input by the user will match, which is inappropriate. For example, without the '[<small]' portion of the said in the first example, you could type 'small rock', 'bright rock', 'dirty rock', 'ugly rock', etc. and the Said() would evaluate to true. This doesn't mean that the adjectives must be optional. You are free to make them mandatory by removing the brackets '[]' around them which would force the user to enter 'small' every time they wanted to refer to the 'rock'.

We've also changed our object constants slightly (SMALL_ROCK_OBJ, CENTER_WINDOW_OBJ). This is because we will have multiple 'rock' and 'window' objects.

Now that we've layed the groundwork, let's make things a bit more complicated:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(Said('*/rock[<small]>'))
= nounSaid[++nounSaidCnt] SMALL_ROCK_OBJ
)

(if(Said('*/rock[<large]>'))
= nounSaid[++nounSaidCnt] LARGE_ROCK_OBJ
)

(if(Said('*/rock[<giant]>'))
= nounSaid[++nounSaidCnt] GIANT_ROCK_OBJ
)

(if(Said('*/window[<right]>'))
= nounSaid[++nounSaidCnt] RIGHT_WINDOW_OBJ
)

(if(Said('*/window[<center]>'))
= nounSaid[++nounSaidCnt] CENTER_WINDOW_OBJ
)

(if(Said('*/window[<left]>'))
= nounSaid[++nounSaidCnt] LEFT_WINDOW_OBJ
)
</syntaxhighlight>
So, now we have three rocks & three windows in our game. We will use the same pattern in the ParseSecond.sc script as well with references to an array & counter of 'secondSaid' and 'secondSaidCnt':
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(Said('*/*/rock[<small]>'))
= secondSaid[++secondSaidCnt] SMALL_ROCK_OBJ
)

(if(Said('*/*/rock[<large]>'))
= secondSaid[++secondSaidCnt] LARGE_ROCK_OBJ
)

.
.
.
</syntaxhighlight>

We'll need to update our game.sh to reflect the new objects:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
// Nouns
(define TREE_OBJ 0)
(define SAW_OBJ 1)
(define GROUND_OBJ 2)
(define SHOVEL_OBJ 3)
(define BIRD_OBJ 4)
(define HOUSE_OBJ 5)
(define DOOR_OBJ 6)
(define KEY_OBJ 7)
(define LEFT_WINDOW_OBJ 8)
(define CENTER_WINDOW_OBJ 9)
(define RIGHT_WINDOW_OBJ 10)
(define SMALL_ROCK_OBJ 11)
(define LARGE_ROCK_OBJ 12)
(define GIANT_ROCK_OBJ 13)
</syntaxhighlight>
We'll also need to update our 'Noun names' text resource:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.001 (noun names) *****************/
Num Text
------ -----
0 tree
1 saw
2 ground
3 shovel
4 bird
5 house
6 door
7 key
8 rock
9 window
</syntaxhighlight>
Don't forget to update your vocabulary with the new adjectives and nouns as well.

We will need to make some modifications to our RobustPragmaFail.sc script. Basically, we need to change the logic to be testing for the number of nouns that were matched (nounSaidCnt) since we are no longer setting the 'noun' variable (yet!). We've also changed the print statements to use a new global strings 'nounDescrip' and 'secondDescrip', which we will address next.
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(procedure public (RobustPragmaFail)
(if(== needNoun TRUE and == nounSaidCnt UNSET)
FormatPrint("What do you want to %s?" VERB_NAMES Verb)
return(TRUE)
)

(if(== needSecond TRUE and == secondSaidCnt UNSET)
FormatPrint("What do you want to %s the %s with?" VERB_NAMES Verb @nounDescrip)
return(TRUE)
)

(if(== unneededNoun TRUE and <> nounSaidCnt UNSET)
FormatPrint("I understood only as far as you wanting to %s." VERB_NAMES Verb)
return(TRUE)
)

(if(== unneededSecond TRUE and <> secondSaidCnt UNSET)
FormatPrint("I understood only as far as you wanting to %s the %s." VERB_NAMES Verb @secondDescrip)
return(TRUE)
)

return(FALSE)
)
</syntaxhighlight>
Before calling the RobustPragmaFail, we'll need to call a new procedure called GetObjectDescrip.sc. The purpose of this script is to extract *exactly* what the user inputted for the noun & second. We need to do this to support the following example: Let's say you have a 'rock' in your game. What happens when you enter an invalid adjective for your noun (perhaps 'cold rock'), but a valid adjective for some other noun in your game. Wouldn't it be nice to be able to provide a detailed error message back to them, something like: 'I don't see any ugly rock here.'

I'm not going to post the code here (you can get it from the new version of RobustParseDemo game) as it's fairly lengthly and unexciting. However, rest assured that it's only purpose is to take apart the user input and capture the noun & second as it was input into the nounDescrip and secondDescrip variables. In order to support this script, we need to create a new text resource that will be used to match adjectives. It should hold every adjective defined for your game (just like the noun names text resource).
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.002 (adjective names) *****************/
Num Text
------ -----
0 tall
1 rusty
2 hard
3 garden
4 song
5 brown
6 front
7 silver
8 left
9 center
10 right
11 small
12 large
13 giant
</syntaxhighlight>
The remainder of our changes we are making is in the ValidateNouns.sc script.

First, we will determine which nouns that were referenced are actually here:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(for (=i 0) (<= i nounSaidCnt) (++i)
// if the object is here, add it to our diambiguate string
(if ( == objectLocations[nounSaid[i]] gRoomNumber
or == objectLocations[nounSaid[i]] INVENTORY
or == objectLocations[nounSaid[i]] EVERYWHERE)
= nounsHere[nounsHereCnt] nounSaid[i]
++nounsHereCnt
)
)
</syntaxhighlight>
Then, we will determine if we need to ask the user if they need to be more specific:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(== nounsHereCnt 0)
= noun UNSET
)(else
(if(> nounsHereCnt 1)

(for (=i 0) (< i nounsHereCnt) (++i)

(if(== i 0)
StrCpy(@disambigStr "the ")
)

(if(<> i 0 and <> i (- nounsHereCnt 1))
StrCat(@disambigStr ", the ")
)

(if(== i (- nounsHereCnt 1))
StrCat(@disambigStr " or the ")
)

Format(@fullNounDesc "%s" NOUN_FULLNAMES nounsHere[i])
StrCat(@disambigStr @fullNounDesc)
)

FormatPrint("Which %s do you mean, %s?" @nounDescrip @disambigStr)
return(FALSE)
)(else
= noun nounsHere[0] // the only noun here
)
)
</syntaxhighlight>
At this point we've successfully determined which noun is being referenced, but we are still not sure if it's here in the room. Finally, we make sure that the noun is actually here:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if (== noun UNSET and > StrLen(@nounDescrip) 0)
(if ( <> objectLocations[noun] gRoomNumber
and <> objectLocations[noun] INVENTORY
and <> objectLocations[noun] EVERYWHERE)
FormatPrint("I don't see any %s here." @nounDescrip)
return(FALSE)
)
)
</syntaxhighlight>
When building our error output for disambiguating nouns, we need the full noun description (adjective + noun). For this, we will utilize a new text resource. This text resource needs to be correlated to the values that we assigned our object constants in game.sh.
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.003 (full noun names) *****************/
Num Text
------ -----
0 tall tree
1 rusty saw
2 hard ground
3 garden shovel
4 song bird
5 brown house
6 front door
7 silver key
8 left window
9 center window
10 right window
11 small rock
12 large rock
13 giant rock
</syntaxhighlight>
'''Testing:'''
Let's try it out. Start up the new RobustParseDemo game & try some things out:

'''While in the house room (there are three windows and one (small) rock there):'''<br/>
'look window' results in 'Which window do you mean, the left window, the center window or the right window?'<br/>
'look small rock' results in 'It's small. More like a pebble, actually'<br/>
'look rock' - same result as before. We don't need to specify 'small' in this case because it's the only one here.<br/>
'look brown rock' results in 'I don't see any brown rock here.' (bad adjective pairing)<br/>
'look large rock' results in 'I don't see any large rock here.' (good adjective pairing, but that object isn't in this room)<br/>

'''While in the tree room (there are two rocks there):'''<br/>
'look window' results in 'I don't see any window here'<br/>
'look rock' results in 'Which rock do you mean, the large rock or the giant rock?'<br/>
'look large rock' results in 'It's a large rock'<br/>
'look giant rock' results in 'It's a giant rock'<br/>
'cut down tree with rock' results in 'Which rock do you mean, the large rock or the giant rock?'<br/>

Multiple adjective handling:
Everything we've done above will support this, just use the supported Said() syntax for multiple adjectives:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if(Said('*/rock[<(small,tiny,miniature)]>'))
= nounSaid[++nounSaidCnt] SMALL_ROCK_OBJ
)
</syntaxhighlight>
Notes:
- If you have ambiguous objects as in these examples, it's courteous to the user to specify the valid adjectives when looking at the object. Examine the 'small rock' example above - when we typed 'look rock', it is indicated that it's small.

- Again, don't use synonyms for your adjectives. Instead use the method above of including multiple adjectives in our Said() strings.

[[Category:The SCI Parser]]
[[Category:Examples]]
[[Category:Tutorials]]

Robust Parse Part 1: A Different Way To Handle User Input

2012-07-28T14:17:10Z

Jeremiah Nellis:

'''Robust Parse: A different way to handle user input'''<br/>

Do you want your text-based user interaction to be better? Want to have parsing that beats the pants off of every single SCI Sierra game (yes, really!)? Well, here's how to do it.

I'm writing this to address some of the shortcomings with parsing the user input.
This solution was inspired by how the parsing takes place in Inform. I didn't dream this up completely on my own; I'm just applying similar techniques in SCI.

'''Existing SCI error handling constructs:'''<br/>
wordFail: 'I don't understand the word %s': Very good. Very specific and provides good feedback that the user has a typo, or worst case the game just doesn't understand their word choice. If this message comes up excessively, the game designer needs to consider putting in some synonymns into the vocab. However, this is a direct reflection of the designers' shortcomings, not the implementation of the parsing, etc.

syntaxFail: 'That doesn't appear to be a proper sentence': For example: 'up jump' (presumably instead of 'jump up'). This happens occasionally & I'm not sure if anything can be done here, except changing the message returned to the user to use a well-known standard sentence structure in the form of 'verb <noun> <prep> <noun>'.

semanticFail: 'That sentence doesn't make sense': I unfortunately do not have an example. Again, not much we can do here, short of asking the user to restate their request in a standard way, similar to syntaxFail.

pragmaFail: 'You've left me responseless': '''This is the worst possible thing a user can see.''' We've done everything we can to parse their input, but we've come up with nothing & this is the best we can do - provide a 'canned' response to the user. '''It's horrific.'''

'''Overview of Solution'''<br/>
1) Parse the verb
2) Parse the noun & 'second' noun
3) Check to make sure the verbs are utilized properly, otherwise throw error (this is the replacement for the stock 'pragmaFail' method)
4) Check to make sure that the nouns specified are 'here', otherwise throw error
5) Call an 'action' script to handle the specified verb

'''Part 1: Parse the Verb'''<br/>
In this step we performing the parsing of the verb. We will also be the flagging of missing or superfluous nouns, which will be used to build the output error message we will display to the user in Step 3.

Each verb will typically be represented with three different Said() string if statements. This is so we can determine whether a verb, verb/noun or verb/noun/noun combination was entered. Note the 'no-claim' operator ('>') at the end of each Said() string - this allows us to continue evaluating Said() statements for the nouns and 'second' nouns in the following steps.
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
= Verb UNSET // initialize it to 'nothing' before each parse

(if(Said('dig/*/*>')) // ex: dig in ground with shovel
= Verb VERB_DIG
)

(if(Said('dig/*[/!*]>')) // ex: dig in ground
= Verb VERB_DIG
= needSecond TRUE // what do you want to dig in the ground with?
)

(if(Said('dig[/!*]>')) // ex: dig
= Verb VERB_DIG
= needNoun TRUE // what do you want to dig in?
)
</syntaxhighlight>
In the code above, we have three different Said() statements, each one will apply true based on what is inputted. This represents all the possibilities for the verb 'dig' (remember, each sentence that a user inputs is always split into a maximum of 3 parts, so we've got it covered). They match a 3-part, 2-part and 1-part user input, respectively starting with the verb 'dig'.

Within each 'if' statement, the first thing we do is set our global 'Verb' variable to the verb 'dig', which we've defined in our game.sh as a constant - in this case an integer. There must be verb constants set up for every verb in our game and are ideally numbered from zero to n.

You also see references to other global variables 'needNoun' and 'needSecond'. Not shown are two other globals 'unneededNoun' and 'unneededSecond'. These 4 variables are initalized to FALSE before each parse, and are set to TRUE when the inputted sentence does not make sense.

Let's look at the first 'if' statement. It will capture a user input of something like 'dig in ground with shovel'. We set the verb global variable to VERB_DIG, we'll get into why we do this later. This if statement happens to be evaluating a 'good parse' in the game.

Next, the second 'if' statement in the example. It applies when the user enters 'dig in ground'. Again, we set our verb global. Then, since the sentence isn't specific enough for us, we set our 'needSecond' variable to true. This indicates that we are expecting a second noun to be entered and it wasn't supplied. We'll use this flag later to tell the user that they goofed & need to be more specific.

The third 'if' is just like the second, except the user has entered something even less specific, the sentence of simply 'dig'. This time we set our 'needNoun' variable to TRUE, indicating they didn't enter the first noun. We could additionally set the 'needSecond' variable to TRUE, but we don't do anything with it, as we stop reporting an error at the initial noun.

'''Part 2: Parsing the noun & 'second' noun'''<br/>
Next, we parse the remaining two portions of the user input (noun & second). This is simpler than parsing the verbs as we are just looking for a match on the nouns in the relative positions in the Said() string. Note that we also are setting the 'noun' and 'second' global variables with constants defined in a similar fashion as our verb constants.
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
= noun UNSET // initialize it to 'nothing' before each parse
(if(Said('*/ground>'))
= noun GROUND_OBJ
)

(if(Said('*/shovel>'))
= noun SHOVEL_OBJ
)
</syntaxhighlight>
and:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
= second UNSET // initialize it to 'nothing' before each parse
(if(Said('*/*/ground>'))
= second GROUND_OBJ
)

(if(Said('*/*/shovel>'))
= second SHOVEL_OBJ
)
</syntaxhighlight>
'''Part 3: A robust 'pragmaFail' method'''<br/>
In order to prepare for this part, let's check a few things. You've got all your verbs & nouns defined as constants, right? Great. Now we need to go one step further & create two text resources. One will be for verb 'names' and one for 'noun' names. This is where we store the text of the verbs and nouns so we can regurgitate them back to the user in our pragamaFail method. The index of the text resource is correlated to the value of the constant, seen below:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** game.sh *****************/
(define UNSET -1)

// Verbs
(define VERB_CUT 0)
(define VERB_CLIMBUP 1)
(define VERB_CLIMBDOWN 2)
(define VERB_DIG 3)
(define VERB_LISTEN 4)
(define VERB_LOOK 5)
(define VERB_RUN 6)

// Nouns
(define TREE_OBJ 0)
(define SAW_OBJ 1)
(define GROUND_OBJ 2)
(define SHOVEL_OBJ 3)
(define BIRD_OBJ 4)
(define HOUSE_OBJ 5)
(define DOOR_OBJ 6)
(define KEY_OBJ 7)

// Text resource numbers
(define VERB_NAMES 0)
(define NOUN_NAMES 1)
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.000 (verb names) *****************/
Num Text
------ -----
0 cut
1 climb up
2 climb down
3 dig
4 listen to
5 look at
6 run
</syntaxhighlight>

<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/***************** Text.001 (noun names) *****************/
Num Text
------ -----
0 tree
1 saw
2 ground
3 shovel
4 bird
5 house
6 door
7 key
</syntaxhighlight>
Now that we've laid the groundwork, let's proceed on to the code for Step 3:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(procedure public (RobustPragmaFail)
(if(== needNoun TRUE and == noun UNSET)
FormatPrint("What do you want to %s?" VERB_NAMES Verb)
return(TRUE)
)

(if(== needSecond TRUE and == second UNSET)
FormatPrint("What do you want to %s the %s with?" VERB_NAMES Verb NOUN_NAMES noun)
return(TRUE)
)

(if(== unneededNoun TRUE and <> noun UNSET)
FormatPrint("I understood only as far as you wanting to %s." VERB_NAMES Verb)
return(TRUE)
)

(if(== unneededSecond TRUE and <> second UNSET)
FormatPrint("I understood only as far as you wanting to %s the %s." VERB_NAMES Verb NOUN_NAMES noun)
return(TRUE)
)

return(FALSE)
)
</syntaxhighlight>
Now you can see all of the pieces from our previous two steps come together. Each if statement handles a different combination of needed (or unneeded) nouns. In our previous 'dig' example, here's the output from two different bad user inputs:

'''"dig"''' results in '''"What do you want to dig?"'''<br/>
'''"dig in ground"''' results in '''"What do you want to dig in the ground with?"'''

The last two if statements work similar to to first two if statements, but for the reverse scenario, where the user has provided too many nouns (instead of too few). The FormatPrint statements rely on looking up the verb name from the VERB_NAMES text resource (in this case text.000) and the NOUN_NAMES text resource (text.001) to give the user a warm-fuzzy about their bad input.

'''Part 4: Are the nouns here?'''<br/>
Good, so we've now implemented a much better solution for reporting bad user input back to the user. We are ready to continue our error checking. Let's suppose our user input is 'dig in ground with shovel'. Completely valid, but what if we are inside a building? Or if there is no shovel here? This just doesn't make sense in this context. We need to make sure that the nouns being referenced are actually in the current room or in the inventory.

In this example, I've implemented a global array of noun locations, and like the text resources, their indexes correspond to the noun constants. Before we launch into more code, I know that this is a non-standard way of tracking where objects are, but for this example I believe it helps with clarity. It should be easy to modify the code to use the 'ownedBy' and 'put' methods.
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
/*************** Main.sc *************/
/* global variables */
Verb
noun
second
needNoun
needSecond
unneededNoun
unneededSecond

/* The array that will track where our objects are */
objectLocations[10] // one for each object in our game

/* in the init() method of Main.sc */
= objectLocations[TREE_OBJ] TREE_ROOM
= objectLocations[SAW_OBJ] NOWHERE
= objectLocations[GROUND_OBJ] EVERYWHERE
= objectLocations[SHOVEL_OBJ] HOUSE_ROOM
= objectLocations[BIRD_OBJ] TREE_ROOM
= objectLocations[HOUSE_OBJ] HOUSE_ROOM
= objectLocations[DOOR_OBJ] HOUSE_ROOM
= objectLocations[KEY_OBJ] INVENTORY
</syntaxhighlight>
You'll notice that we've introduced more constants here: room constants. These are defined in our game.sh. Note that the the positive numbers should correspond to your room script numbers. INVENTORY, EVERYWHERE and NOWHERE are special values
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
// Rooms
(define INVENTORY -2)
(define EVERYWHERE -1)
(define NOWHERE 0)
// From here, the number should match the room script numbers
(define HOUSE_ROOM 1)
(define TREE_ROOM 2)
</syntaxhighlight>
Here's the procedure that does the checking for whether the nouns are 'in-scope':
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(procedure public (ValidateNouns)
(if(<> noun UNSET)
(if ( <> objectLocations[noun] gRoomNumber
and <> objectLocations[noun] INVENTORY
and <> objectLocations[noun] EVERYWHERE)
FormatPrint("I don't see any %s here." NOUN_NAMES noun)
return(FALSE)
)
)

(if(<> second UNSET)
(if ( <> objectLocations[second] gRoomNumber
and <> objectLocations[second] INVENTORY
and <> objectLocations[second] EVERYWHERE)
FormatPrint("I don't see any %s here." NOUN_NAMES second)
return(FALSE)
)
)

// All the nouns are here
return(TRUE)
)
</syntaxhighlight>
Let's go through it. For the first noun, we check to make sure that it's actually been specified, the check to see if the noun is either in the current room, inventory or everywhere (everywhere being specified for something like 'ground' or 'sky' if your game takes place completely outside). We do the same check for the second noun. If either of these if statements evaluate true, we return FALSE (indicating failure), otherwise we return TRUE (all good to continue parsing).

'''Part 5: Call the action script'''<br/>
At this point, we've narrowed our input down to being as legitimate as possible without knowing if the combination of verbs and nouns make sense. At this point we will create a procedure for each verb that we've specified & either perform the action that user asked for, or tell them that their verb and nouns don't make sense together.

Below is the 'CallAction' script, which is purposed to simply call another procedure based on the verb input:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(procedure public (CallAction)
(if(== Verb VERB_CUT) CutAction() return)
(if(== Verb VERB_CLIMBUP) ClimbUpAction() return)
(if(== Verb VERB_CLIMBDOWN) ClimbDownAction() return)
(if(== Verb VERB_DIG) DigAction() return)
(if(== Verb VERB_LISTEN) ListenAction() return)
(if(== Verb VERB_LOOK) LookAction() return)
(if(== Verb VERB_RUN) RunAction() return)
)
</syntaxhighlight>
Let's take a peek at the DigAction procedure:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(procedure public (DigAction)
// Could be "dig ground with shovel" or "dig with shovel in ground"
(if (<> second SHOVEL_OBJ and <> noun SHOVEL_OBJ)
Print("That doesn't have a blade adequate for digging.")
return
)

(if (<> second GROUND_OBJ and <> noun GROUND_OBJ)
Print("It would be best if you dug in something sensible!")
return
)

Print("Nice hole. What next?")
)
</syntaxhighlight>
In the case of digging, we've programmed it as a bit of a "red herring". You really don't accomplish anything, but it illustrates the point. In the first if, we are making sure that the user is trying to dig with the shovel. Next we make sure that what the user is trying to dig in is the ground. Finally, the 'good parse' results represents success; we've dug a hole.

'''Testing'''<br/>
Here are some sample inputs to test 'digging' (note that these will all work in the Robust Parse Demo game that I've created):

dig<br/>
dig in ground<br/>
dig in ground with shovel<br/>
dig in house<br/>
dig in house with bird<br/>
dig in house with key<br/>
etc... (try every noun if you wish!)<br/>

And of course try these commands in both rooms (there are only 2 in the demo) to see the varying results.

'''Conclusion:'''<br/>
You can see that getting a very robust parse takes a lot of parts & a lot of error checking along the way. However, we've gained the flexibility to apply any verb to any noun in any room and get a sensible response from the game, which results in a very satisfying and rich experience for the user.

'''Miscellaneous Notes:'''<br/>
- Memory utilization: Following this template will potentially generate some very large heap utilization. Though not necessary in the demo game, I still put in DisposeScript() calls everywhere possible to mitigate this. If memory usage becomes excessive, it will most likely be a problem in ParseVerb, ParseNoun and ParseSecond scripts. To address this, simply split the scripts in two or more pieces (e.g. ParseVerbAthruM, ParseVerbNthruZ) and change the calls to the scripts accordingly in the RobustParse routine.

- Do not have words in your vocabulary that you have not provided a successful parse for. Doing so only enables the user to use these words and make us look stupid because it will fall through to the pragmaFail method. This means dump the template game's vocabulary. Yes, dump it. Use the (nearly) empty vocab provided in the Robust Parse Demo game.

- The use of synonyms is discouraged. Instead of synonymns, use the words in the parse itself with the grouping operator (parens) . It will make troubleshooting easier. Once you have bound two words together via a synonym, it is impossible to separate them and can cause unintentional results at parse time.

- Noun disambiguation. This is where adjectives come into play - this is a whole other topic.

[[Category:The SCI Parser]]
[[Category:Examples]]
[[Category:Tutorials]]

Minimum Vocabulary To Compile Template Game

2012-06-30T16:15:49Z

Jeremiah Nellis:

Here are words necessary for compiling the template game:

'''Main.sc:''' (if you remove the sample code, you don't need these words)
object
hi

'''Menubar.sc:'''
color
all
delay
game
done
restart
restore
save

'''Don't remove these (you'll regret it):'''
* (anyword)
!* (noword)

[[Category:Examples]]

Inline If Statements

2012-02-17T15:08:10Z

Jeremiah Nellis:

''Note: This article only applies to SCI Companion''

The "if" statement does not return a value, making a the nesting of if's (inline) like this not possible:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if (> a ((if(> b c) 5)(else 9)) d) // This syntax works in SCI Studio, but will not compile in SCI Companion
...
)
</syntaxhighlight>

As indicated above, this code '''will''' work in Studio, but will not work in Companion. The way to handle this in Companion is to implement a procedure, which will return a value:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(procedure public (iif pCondition pTrue pFalse)
(if (pCondition)
return pTrue
)(else
return pFalse
)
)</syntaxhighlight>

The original statement can now be re-written as:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(if (> a iif(> b c 5 9) d)
...
)
</syntaxhighlight>

[[Category:Conditional Statements]]
[[Category:Examples]]
[[Category:Scripting]]
[[Category:Syntax]]

Goto Statements

2011-02-18T15:28:16Z

Jeremiah Nellis:

This can be accomplished with inline assembly code. Verbatim from the 'Inline Assembly' page in the SCI Studio Help File:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
// the inline assembly is quite versatile. Here's a crafty example:
(if(something)
(asm jmp _a_goto_label)
)
(asm _a_goto_label: )
</syntaxhighlight>

Note that the inline assembly code functionality is implemented in SCI Studio, but not in SCI Companion.

[[Category:Examples]]
[[Category:Scripting]]
[[Category:Syntax]]

Arrays as Object Properties

2011-02-06T21:59:59Z

Jeremiah Nellis:

According to '''Lars Skovlund''':

<blockquote>
There is no way to do what you ask. That's part of the reason why they had to introduce the Memory call in SCI01 (but that's an ugly solution to the problem.
There is a hack that you can use, however. Declare a single local variable followed by the arrays you need. Then you can (at least from the point of view of the PMachine, not sure about Brian's compiler) index into the large arrays by addressing the lone local variable and using a bit of arithmetic.

So I'm saying something like:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
(local
baseVar
array1[10]
array2[10]
)

(instance Blah of Obj
(properties
arrayPos 1
)
)

(instance Blarg of Obj
(properties
arrayPos 11
)
)
</syntaxhighlight>
</blockquote>

To access the array, you use a reference like:
<div class="CodeBlockHeader">Code:</div>
<syntaxhighlight lang="sci" class="cs">
baseVar[(Blah:arrayPos)] // Gets the 1st value from array1
baseVar[(Blarg:arrayPos)] // Get the 1st value from array2

baseVar[+ (Blah:arrayPos) 1] // Gets the 2nd value from array1
baseVar[+ (Blarg:arrayPos) 1] // Get the 2nd value from array2
</syntaxhighlight>
[[Category:Examples]]
[[Category:Syntax]]

Point and Click Tutorial: Chapter 9 - Prepare the Text for our Point and Click Rooms

2011-01-06T02:55:14Z

Jeremiah Nellis:

And to think that prior to Chapter 3 of this tutorial, you may have never before made use of any text resources, but now and when we actually get to coding the rooms, they are going to become your very best friends.

==Text Resources for the Inventory==

Now, I realize that without actually seeing the code that is going to be accessing this resource, you might not believe that we are actually going to use them, trust me on this one, I am pretty sure that you will. If not, you can always come in later and change these to something else if you don't like what I have everything set up to do. This text resource is going to handle most of the default clicks, or clicks on things that aren't handled by the room's scripts, mainly clicks on ego help, and whatnot.

Open up a new text resource and let's begin with the help statements.

<ol>
<li value="0">Welcome to %s . A point and click adventure.</li>
<li value="1">To control your characters interactions, select the desired action from the action menu. Walk, talk, look, get are all represented by icons and clicking on one will change your cursor accordingly.</li>
<li value="2">To use an inventory item, you must first open the inventory screen and select it from the items you are carrying. Clicking on the backpack icon will open the inventory screen.</li>
<li value="3">The system menu allows you to save, load, restart, quit, or change your speed and volume settings. You can reach the system screen by clicking on the center blue sphere of the menu graphic.</li>
<li value="4">To return the menu to actions simply click the smaller blue sphere to the left of the system menu option.</li>
<li value="5">Hope this has been helpful, enjoy playing %s!</li>
</ol>

Just to make sure, you have plenty of room to add in more help messages if you feel you need them, we are going to go ahead and add in a few empty lines just so you won't have to rearrange things in the future. The next line that we are actually going to start using is going to be line 10, so if you want, go ahead and just enter a space or whatever in lines 6 through 9 just in case.

Now, let's go ahead and add in a few lines for random "action" clicks on the ego.

<ol>
<li value="0">What a handsome fellow!</li>
<li value="1">Vanity is never an attractive trait.</li>
<li value="2">That's strange, I don't remember ever putting these clothes on.</li>
<li value="3">Talking to yourself has rarely ever been considered a good sign.</li>
<li value="4">Do you really think that you would find yourself that interesting?</li>
<li value="5">"Hi there me, How am I doing?"</li>
<li value="6">You sir, are no Michael Jackson, keep your hands off yourself.</li>
<li value="7">When I think about you I touch myself.</li>
<li value="8">You quickly adjust your clothes. After all who knows, there may be some fly young hotties in the next room.</li>
<li value="9">Whatever you are trying to do to yourself, knock it off</li>
<li value="10">I'm not really sure if I would want to use that on myself.</li>
<li value="11">Oh yeah, stick it my ear. That's a good idea.</li>
<li value="12">Your brilliant use for that in this way clearly illustrates that you are in a league of your own. So much so, that I am not even going to allow it, try something else.</li>
<li value="13">I am not even sure how I could use that there.</li>
<li value="14">Hmm, interesting idea... but I think we would need a permit.</li>
</ol>

That takes care of all of the clicks on the ego and random item clicks in room, I have the point and click script set up to randomly pick from three possible responses for each action, look, talk, hand, items. Now, we need to handle the texts for the "system" options, basically the
statements that are printed along with the quit and restart dialogs.

<ol>
<li value="0">Are you serious? You really want to start all the way back at the beginning again?</li>
<li value="1">Do you really want to quit?</li>
</ol>

That is all we need out of this text resource for the tutorial, save this as number 950.

Now, While we are creating texts, let's go ahead and start off with Room 1's text resource. As the point and click script is currently written, you '''will''' need a separate text resource for each room. The room number should correspond to the text resource number, so room 1 will require text resource 1.

The default clicks handled by the point and click script require that line 0, 1, and 2, be set up as the rooms default clicks (or clicks on stuff that is not handled in the rooms script specifically) as the following actions look, talk, and get.

So for instance, clicking on nothing with the look cursor will print text resource line 0, the general description of the room.

Open up another new text resource and enter this stuff.

<ol>
<li value="0">You find yourself standing in the great white void of room 1's nothingness.</li>
<li value="1">Yelling into the void, you are greeted with an eerie silence, if only there was someone here to talk to.</li>
<li value="2">Reaching out, you find, as many philosopher's have over the centuries, just how hard it is to grasp true nothingness.</li>
</ol>

Since this resource is going to be used for room 1, save it as resource number 1.

All right, that is that, we now have two text resources for the point and click room. Remember 950 holds all of the texts which are needed for the point and click menu itself, while text resource 1 holds all of the texts for room 1 specifically. As you add in more rooms, room 2 will try to access text resource 2 and so on.

That sums up the creation of the Point and Click Text resources!

 

<span style="float: left">[[Point and Click Tutorial: Chapter 8 - Ordering the Additional Cursors|< Previous: Chapter 8 - Ordering the Additional Cursors]]</span>
<span style="float: right">[[Point and Click Tutorial: Chapter 10 - Point and Click Menu Views|Next: Chapter 10 - Point and Click Menu Views >]]</span>

 

[[Category:Text Resources]]
[[Category:Tutorials]]