The PlayKISS Preferences window consists of a help button, a set of 4 action buttons and a scrolling window. If unrolled, the scrolling window would appear as shown below. For information on the effect of the various preferences, simply click on control in the image.
This group of preferences control the appearance of the PlayKISS windows and menus, and defines the way that PlayKISS handles certain KISS characteristics.
This option button controls whether PlayKISS will fade the set and palette controls (menu items and toolbar buttons) for missing sets and palettes.
This option button allows the user to disable all French KISS scripting commands.
If enabled, the mouse pointer will change to a "hand" when over the PlayKISS window.
Some dolls (accidentally or deliberately) position objects partially or completely outside the playfield. If "Expand to fit" is enabled, the playfield will be automatically expanded to encompass all such objects.
Although still supported, this preference is deprecated. It is recommended that this option is disabled, and either the "FKISS Only" or "Limited" form of bounds checking is enabled instead.
Normally, parsing errors reported by PlayKISS are sent to a special window. However, if this option is enabled, the software development "throwback" system is used instead, which makes it much easier to locate the error in the source file.
For throwback to work, a throwback-aware text editor must be running. Unfortunately, the built-in !Edit is not throwback-aware. You will need !Zap, !StrongEd or !SrcEdit.
The "Fix" attribute of an object defines how easy it is to move. Originally, this attribute had the range 0-100; objects with a fix of 100 (or greater) were permanently fixed.
The main translation of the original Japanese specification, however, missed this upper limit, and as a result, doll creators have used a range of values to define permanently fixed objects.
If this option is disabled, PlayKISS uses the original definition; if enabled, PlayKISS will apply a rule-of-thumb to attempt to deduce the doll creator's intent.
If this option is enabled, PlayKISS will report the loading of each cel as it is read.
PlayKISS will normally only put scrollbars onto the doll window if it will not fit on the screen. However, the "zoom" function will currently only work if the window has scrollbars. This option will force PlayKISS to use scrollbars for all dolls, enabling the zoom function to work for all dolls.
The original KISS/GS specification only allows a palette of up to 256 colours. Some more recent dolls exceed this limit, and use the "Extended palette" (or "Enhanced palette") colour model, which limits each cel to 256 colours, but allows a larger combined palette.
This option will allow the use of extended palette colour model. If not enabled, such dolls will cause an error during load.
PlayKISS will normally handle partial transparency in cels by using 16 or 32-bit colour for the playfield for all dolls that use partially transparent cels (which requires that the wimp display mode is at least 16 bit).
However, memory requirements can be reduced (both for display memory and for PlayKISS internal use) by enabling this option, at the expense of a reduced-quality image.
When you try to move an object that is almost (but not quite) free to move, the object will move slightly but then snap back to its original position. The snapback can be made to occur immediately the distance the object is dragged exceeds that allowed (early snapback), or it can be deferred until the mouse button is released (late snapback).
This option button selects between those alternatives (if enabled, early snapback is used; if disabled, late snapback is used).
Classic KISS uses early snapback, but some FKISS dolls work better with late snapback.
Some FKISS functions display text to the user, but the FKISS specification leaves it to the player software to decide how such display is handled. PlayKISS has two distinct techniques - a scrolling window that pops up whenever text is added, or a Wimp alert box. This preference specified when each approach is used:
Setting | Meaning |
---|---|
Never | The window will never be used - all text output will use a Wimp alert box. This will mean that all text display functions will interrupt any drags in progress. |
Always | The window will always be used. This will mean that text display functions invoked as part of the doll closedown will probably be missed, due to the very short time they will be displayed. |
Except @ end | The window will be used for all text output, unless the function is invoked as part of the doll closedown procedure. Text functions triggered during doll closedown will use a Wimp alert box. |
Classic KISS required that player software should not allow objects to be moved outside the playfield (either by user drags or, more recently, by FKISS functions). However, many players have included different ways of ignoring this limitation, and some dolls will fail if classic bounds checking is enforced. This control tells PlayKISS which form of bounds checking to use.
Setting | Effect on | |
---|---|---|
User drags | FKISS functions | |
Full | This is "classic" bounds checking. Objects cannot be moved even partially off-screen. | |
FKISS Only | Unconstrained.
Objects can be dragged off the playfield. |
Full bounds checking applies. |
Visible | That part of an object that is mapped (i.e. configured to be displayed) cannot be moved off-playfield. However, unmapped portions of the object can be moved off-playfield. | |
Limited | As for "FKISS Only". | As for "Visible" |
This text field is used to specify the search path for extension dolls that use the "INCLUDE" directive. When PlayKISS encounters an INCLUDE directive, it will first check the directory containing the extension doll for the specified base doll. If it is not found there, a hierarchical search of the search path and subordinate directories is made.
You can either type the name of a directory, or you can drag a directory from the filer to the text field.
This group is used to control the flashing of FKISS-active cels (triggered from the "Show active" submenu).
This menu can disable flashing altogether (Off) or select one of three flash rates (Slow, Medium or Fast).
This control is used to specify the number of times that the active cels will flash.
The defaults group is used to define the initial setting of some of the menu items on the "Options" submenu.
This option specifies whether PlayKISS will use the Virtualise virtual memory module (if present) be default. This can be overridden by the "Virtualise" menu entry on the Options submenu.
This option specifies whether PlayKISS will add a control toolbar to the playfield window. It can be overridden by the "Toolbar" menu entry on the Options submenu.
This option specifies whether PlayKISS will perform strict parsing checks when reading a doll's configuration file. It can be overridden by the "Strict checks" menu entry on the Options submenu.
This group of preferences controls the processor and memory burdens that PlayKISS will put on your computer.
True-colour "Cherry KISS" dolls may put considerable demands on available memory and processing speed. PlayKISS can use either 32 bits per pixel (bpp) or 16 bpp for Cherry KISS, and this preference controls which is used.
This preference is used to specify the size of the dynamic area used to store cels.
This preference can somewhat reduce the processor burden of dolls that use a lot of complex FKISS, especially timers. The higher the setting, the less the processor burden of the doll. As high values also reduce the responsiveness of the doll to user interaction, it should be set as low as possible. In practice, a StrongARM or XScale is normally perfectly happy with a latency of 1.
Irrespective of how much updating is going on internally, the visible image is
only updated at regular intervals; this preference defines how frequently the image
is updated. Roughly speaking, the image is updated 100/latency
times per
second, so the lower the latency the more responsive the doll will be. In practice,
few dolls impose such demands that an update latency of higher than 1 is required on
a StrongARM-powered machine, unless there are other processor-intensive tasks going on
at the same time.