I may add images to this page at some time in the future, but for now, it's just text.
Bear with me.
If you open a KiSS archive - say, kissdoll.lzh - in a viewer, you will be presented
with a screen in which are arranged the items of the KiSS set; typically, a human figure, the
"base doll", and its clothes. You can drag the clothes over the doll with the mouse, and while
the clothing will mostly overlap the doll, some parts of the clothing - T-shirt backs, for
instance - may disappear under it. The screen itself may have numbers from 0 to 9 at the top,
with the 0 greyed out to indicate that you are now on the first of the ten pages, or sets as
they are also called. (To avoid confusion with the word "set" meaning the collection of files that
make up a KiSS doll, I will call them pages.) There may also be a row of buttons numbered 0 to 9
for the ten palette groups.
If you uncompress a KiSS archive, you will find: one or more files with the extension .CNF;
probably one or more files with the extension .KCF; a long, long list of files with the
extension .CEL; and other optional files such as sound files, midi files and README.TXT files.
The .CEL files are the images you see in the screen when you open the set. They are called
cels and, like the cel files in animation, are laid on top of each other. It's not easy to see
when they're spread all over the screen, but if you were to drag them all to the same spot,
you'll find that every image lies under another image and over another image. Each cel is a
layer, and the cutting up of an image to fit it around another image - for instance, a T-shirt
that has a back which goes under the base doll, and a front that goes over the base doll - is
what is referred to as layering. The base doll itself can be layered, as when it's drawn with
its legs crossed and the topmost leg is a separate cel overlaying the other leg, or when the doll's
hair consists of a part behind the face and an part (usually the bangs) covering the face.
The cels would not even be visible (unless they were CKiSS cels; see
What is KiSS) without a palette file. The .KCF or palette files are colour values arranged in
a numbered order. Sound confusing? ^_^ Suppose you had a box of identical wooden blocks, each painted
in a different colour. You then lay these blocks out in a row of sixteen. Computers start
counting at zero, so the first block would be block zero, the second block one, and so on until
block fifteen. Now the first block might be red, the second yellow, the third purple and so on;
that means the colour zero is red, colour 1 is yellow etc. Now, you could lay them out in a different
order, starting with the yellow block followed by the green block, the blue block etc. Now yellow
is the colour zero, green is colour 1 andsoforth. The importance of this is that the colour
zero is the transparent colour. People who make animated gifs will know what a transparent
colour is. It is the colour that is used as the background colour, because it allows any different
colour number to show through it. If cels didn't have a transparent colour, each cel would show as
a solid rectangle covering up everything underneath.
Cel files themselves contain no colour; each pixel in a cel file refers to a colour number
in a palette file. Putting colour in a cel is like painting by numbers:
there's a line drawing with numbers in the blank areas to tell you what colour to fill them with.
This number doesn't refer to the colour itself, but to the tube of paint containing this colour. Suppose
the paint tubes were lined up from number 0 to number 15, like the blocks in the example above.
Tube 1 contains pink paint, tube 2 leaf-green paint and so on, because this painting shows a bunch of
flowers. Now I take a different line drawing, which is of a boat on a stormy sea. The areas to paint in
are also labelled 0 to 15, but obviously this picture will contain no pinks or leafy greens. The
numbers now refer to a different set of colours; tube 1 would contain dark blue, tube 2 off-white
and so on. The first set of tubes has different colour values from the second set of tubes,
but as they are both arranged in rows of 16, the first tube will be colour 0 in either case, the
second tube will be colour 1 in either case, and so on. The colour value (usually defined
as RGB, the amount of red, green and blue in the colour) is not the same as the colour number.
A palette file is like a row of tubes, numbered to correspond with the numbers in a cel file. Since
different cels need different colours, there can be more than one palette file. A cel must be
connected to the right palette file. What would happen if I took the flower drawing and the sea
drawing and switched the set of paint tubes needed to colour them? I'd get strange blue flowers
and a very pastel sea. Exactly the same happens when you assign the wrong palette to a cel.
(As colour number and colour value have nothing to do with each other, you could have the same
colour twice in a palette, or a palette with sixteen times the colour green. You could even make
colour 0 the same colour as, say, colour 5. The reason tutorials will advise you to use
a background colour that's different from all the other colours used is that paint programs
may work along the lines of "hey, this bit is colour 0 and this bit is colour 5, but they're
both lilac. Let's both make them colour 0." Then the cel will suddenly be transparent in
unexpected places.)
How do you connect a palette and a cel? How do you stack the cels in the right order? How do you make them appear in the viewer at all? It's done with the .CNF file, or simply cnf. This file contains:
KiSS palette files can have two formats; they either contain 16 colours numbered from 1 to
15, or 256 colours numbered from 0 to 255. Altogether, a KiSS set may contain 256 colours,
which means that you can use either one 256-colour .KCF file or seventeen 16-colour .KCF
files. Um, don't I mean sixteen 16-colour .KCF files? No, because the first colour in every
.KCF file is the transparent colour 0 and is only counted once, so you have one 16-colour
palette and sixteen 15-colour palettes. And as if that's not confusing enough, both
256-colour palette files and 16-colour palette files have ten internal palette groups,
bringing the maximum number of colours a KiSS set can display up to 4096.
So, what is a palette group? Let's go back to the example of a palette as a row of
paint tubes numbered 0 to 15. Suppose this row of tubes was lying on a tray. The tray
is labelled "0". I lift the tray, and there's another tray underneath it, also
with sixteen numbered paint tubes on it, and this tray is labelled "1". The contents
of tray 1 look exactly the same as the contents of tray 0, but I happen to know that
the top tray contains the greens and pastels I need to paint in the flower picture,
and the tray under that contains the blues and whites I need to paint in the sea
picture. The tray under that might contain a different range of colours, or it might
be empty, in which case all trays underneath it will automatically also be empty.
There are ten trays in total, and they're labeled 0 to 9. This label is the palette
group.
Having multiple palettes in one palette file may sound very exciting, but its use is
limited. A cel can be connected with only one palette file. You can't make it
change colours by connecting it with a different palette file once the set is opened
in the viewer. You can merge up to ten palettes in one file, which means that you
fill all the trays in the .KCF file rather than just tray 0, and
switch to a different palette group
once the set is opened, which has the effect of suddenly changing the cel's colours.
But changing the palette group affects every palette file in the set. So if
I use two 16-colour .KCF files, one for a bunch of flowers and one for a backdrop,
and change the colour of the flowers by switching to palette group 1, I may also be
changing the colour or the backdrop. Not every tray in every palette file is filled,
and if I switch to a palette group which is empty in a particular palette
file - say, my flower palette file has two trays filled, but the backdrop palette
file only has its top tray filled - then all cels connected with that palette file
are rendered using its palette group 0, ie., the colours from the top tray. In the
flower example, when the palette group becomes 1, the flowers would change colour,
but the backdrop wouldn't.
The default palette group for each page can be set in the cnf. So if I want a
flower cel to be blue on page 5 but yellow on page 6, and blue is colour 2 in
palette group 0 while yellow is colour 2 in palette group 1 of the palette file,
I'll make 0 the default palette group for page 5, and 1 for page 6. The palette
groups are in the object position block of the cnf. What's the object position
block of the cnf? Nevermind, look for a dollar sign. To the right of the dollar
sign is a number between 0 and 9, and after that is a string of number pairs with
comma's between them. There are up to ten of these little blocks of number pairs
that start with a dollar sign; the number pairs are the coordinates of the
objects on that page, and the number to the right of the dollar sign is that page's
default palette group.
Okay, this is where it gets technical.
A cnf has four parts, one of which is optional. It always starts with
a header, followed by an object declaration block; next is the object
position block and last is the optional FKiSS block, which may be inserted
before the object position block. (These are not the "official" terms;
I don't know if there are any official terms for the cnf's component
parts. But I find they make it easier to explain.) The header contains
a list of palette file names, preceded by a "%". These are not
numbered, but from the order in which they are listed, the viewer
deduces that the first palette is palette file 0, the second palette
is palette file 1 etc. As the maximum number of colours is 256, there
should be only one 256-colour .KCF file or up to seventeen 16-colour .KCF
files in this list. When the total number of colours in all the .KCF files
exceeds 256, the KiSS set is said to be an enhanced (or
extended) palette set. Not every viewer can handle this!
The object declaration block consists of lines that look like this:
#12 flower.cel *0: 0 1 3 4; This is a flower
#14 field.cel *2: 0 2 ; This is a field
The number with "#" is the object number. Next comes the name
of the cel file. The number with the asterix is the palette connected
to that cel, and refers to the list of palettes in the header. The
numbers after the colon are the pages on which the cel is displayed.
What follows after the semicolon is simply a comment. All comments
in the cnf are preceded by a semicolon.
I said the object declaration block was an inventory of cel files?
That's almost true, but not quite. A cel is a real file, that can be
viewed in a cel viewer. An object is a placeholder for one
or more cels. You can compare it to the IMG tag in a HTML page.
Suppose I have a picture file called PICTURE.GIF and a HTML file
called PICTURE.HTM. When I put the line "< IMG SRC=picture.gif >" in
the HTML file and view it in a browser,
it displays PICTURE.GIF. If I copy that line so it
occurs twice in the HTML file, the browser displays two pictures instead
of one, although there is still only one PICTURE.GIF in the directory.
Each picture displayed is an instance of PICTURE.GIF, a copy
placed on the screen. The IMG tag helps determine where on the
screen this copy is displayed. The object number determines exactly
where on the screen the copy of a cel is displayed; in the object
positioning block - the section where the lines start with "$" - you
will see the coordinates for each object on every page where it's
displayed, starting at object #0. If I want to manually change the
position of the flowers on the first page, I'd open the cnf in
Notepad and edit the thirteenth set of coordinates in the coordinates
list of page 0.
Since objects, not cels, have coordinates, it is only through connecting
a cel name to an object number that you can have it shown anywhere on a
page. Any movement of the item is also applied to the object number, not
the cel name. So if I drag a T-shirt with the mouse, I'm dragging
object #n, not cel "t-shirt.cel". This illustrates another function
of the object number: keeping together the cels that belong to one
item. This T-shirt, being layered to slide over and under the base
doll, consists of "t-shirt.cel" and "t-shirt_.cel" (the T-shirt's back)
which both have object number #15, and therefore move in unison.
If they didn't have the same object number, and I dragged the T-shirt
with the mouse, the T-shirt's back would remain hanging in mid-air.
There is a difference between object positioning and cel
layering! Which cel lies over which depends on the order in
which they're listed in the object declaration block of the cnf:
first one goes on top, last one
lies at the bottom. Object numbers have nothing to
do with the layering order, and needn't even be consecutive. In
fact, since objects are only placeholders for cels, you could use
the same cel file name with three object numbers, for instance,
three lines in the cnf that assign "flower.cel" to objects #1, #2
and #3. On opening the screen, you will see three identical
flowers that you can drag around independently. These are three
instances of the physical file FLOWER.CEL. The object
declaration block, therefore, is a list of cel instances, rather
than of the cels themselves. This is not important for KiSS-only
sets, but is something to keep in mind when adding FKiSS commands
that refer to cel names.
That's a whole different subject. Go to the
next page.
As a KiSS set consists of images, first and foremost, a bunch of images, or
a paint program to make the images with; preferably one that allows you to
edit the order of the colours in a palette. Second, a program to turn your image
files into cels and palette files. There are a number of programs that do this,
and most are freeware. Third, an ASCII editor to write the cnf with. Fourth,
a KiSS viewer so you can actually see what you made, and position all the
images on the pages; most KiSS viewers also write the cnf for you,
although you'll often have to tweak the cnf with something like Notepad.
Fifth, if you're going to distribute your set: LHArc (the DOS program
LHA.EXE) or another compression program that compresses to .LZH format.
Sixth, a lot of free time. It's not essential, but it helps.
These are just the basics. For more specialized help, see the
list of tutorials.
