Open main menu

SCI/Specifications/Graphics/SCI1 palettes

< SCI‎ | Specifications‎ | Graphics
Revision as of 13:34, 6 January 2009 by Timofonic (talk | contribs) (Merging of the SCI documentation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

SCI1 palettes

Palette types

There are two kinds of palettes in SCI: Local palettes and global palettes. Local palettes are associated with a graphical resource, while the global palette resides in a separate resource. In SCI1.0, both kinds hold exactly 256 elements, and only synchronous palette operations can be initiated by the VM. SCI1.1 changes the palette format radically and introduces the ability to perform asynchronous palette cross-fades. The exact format of SCI1.1 palettes is not known and will not be described here, nor will the associated kernel calls.

The global palette is updated on several occasions:

  • On game startup, the global palette is loaded from the 999.pal resource.
  • It may be replaced at any time using the appropriate kernel call.
  • When a graphical resource is loaded for display, its palette entries are merged into the global palette (“installing” it – see section 3.10 for more information), and all further operations are carried out on the global palette. Functions that only return view metadata do not touch the global palette.
  • The game may explicitly request installation of a view's palette (SCI1.1 only).


The local palette entries are usually placed in the right spot in the local palette, such that installing them is a simple matter of copying. This is not always the case, however.


The palette format

A SCI1.0 palette, whether global or local, consists of the following items:

  1. A mapping of each color index into the global palette (the global palette and most, if not all, palettes on disk have the identity function here).
  2. A 32-bit time stamp for internal use (it is always zero in the resources).
  3. A list of FRGB tuples where F is a flag byte telling if the index is in use and if it is the victim of an approximate mapping (see section 3.10). The flag bits are given in figure 3.9 - the remaining bits were perhaps used during development.

In addition to these, the global palette contains, for each color, a brightness value. It is measured in percent, and is kept separate from the RGB triples to avoid interfering with color matching. This is not stored in the resources, but defaults to 100. The values may be changed by the game, for example to allow the same pic to be used in day and night scenes.

A palette is assumed always to contain pure black and pure white with indices 0 and 255, respec­tively. This is enforced when performing cross-fades in SCI1.1, and in addition, those entries are ignored by certain operations, brightness control in particular.


Installing a palette

When installing a palette, there are two different modes. They are shown in table 3.10 and described in detail below. No, the numbers in the table are not reversed, it just happens that the least-used mode has the value 0.


Forced mapping
As the name indicates, target palette entries are always overwritten by the correspond­ing source entry. If a source entry is unused, the corresponding target entry is left untouched.
Normal merge
When using this method, five steps are taken in an attempt to map each source entry to a target entry. In each case, the source palette is updated to indicate the new mapping. If one step fails, the next is executed, and so on:


  1. If the i’th source entry is not used, skip to the next.
  2. If the i’th target entry is not used, then the source entry is mapped to it.
  3. Try to find an exact match in the target palette and map to it if one is found.
  4. Try to find an unused index in the target palette and map to it if one is found.
  5. Map to the closest color in the target palette, with infinite tolerance. Because infinite tolerance is used, this step will never fail. In addition, flag bit 4 in the target palette entry may be set by some SCI versions to indicate an approximate mapping.


Forced mapping is used implicitly almost everywhere within the interpreter. Thus, there is no real need for removing palette entries explicitly, because a large part of the palette is (in practice, though not in theory) replaced in strategic places. When loading palettes explicitly, the game may specify a different mapping strategy. Brightness values are left untouched during all implicit palette operations. Thus, it is not safe to add new cels to a scene while using brightness adjustment.


Figure 3.1 Flag bits in each palette entry

Bit Description
0 The entry is used
4 Another color has been inexactly mapped to this one


Figure 3.2 The palette installation modes

Mode Description
0 Merge into the global palette
2 Force insertion