021A and 021B graphics formats-revision 1.00

These two formats have been designed for use in THE WRATH OF SONA, but they
could theoretically be used anywhere. The extension is 021, however, the
format is slightly different for the two types.

FEATURES:
-Virtually infinite number of graphical arrays in a file
-Easy pointer selection of images
-Comprehensive format and header information
-Designed for use with Microsoft QuickBASIC series

021A SPECIFICATIONS:
-HEADER-
ID-STRING * 30 "KaddashEncodedGraphicArray021A"
The ID is designed to identify this format.
Height-INTEGER
The height of all graphic arrays in the file. This must be consistant to
keep header size to a minimum and to speed access time.
Width-INTEGER
The width of all graphic arrays in the file. This must be consistant to
keep header size to a minimum and to speed access time.
-DATA-
Starts at byte 35. Encoded using QB's standard signed integer (two bytes)
array format, the first two integers of the standard graphic array have been
stripped to reduce filesize.

021B SPECIFICATIONS:
-HEADER-
ID-STRING * 30 "KaddashEncodedGraphicArray021B"
The ID is designed to identify this format.
Height-INTEGER
The height of all graphic arrays in the file. This must be consistant to
keep header size to a minimum and to speed access time.
Width-INTEGER
The width of all graphic arrays in the file. This must be consistant to
keep header size to a minimum and to speed access time.
-DATA-
Starts at byte 35. Encoded using QB's standard signed integer (two bytes)
array format, the first two integers of the standard graphic array have been
stripped to reduce filesize. In version B of the format, 48 bytes follow the
image data. This is the palette information, arranged in an R G B order, using
a six-bit palette. If eight bits are encountered, divide all entries by 4.

FURTHER INFORMATION:
THE WRATH OF SONA uses a 64X64 array for these files, and uses two files:
FACENP.021-Version A of the format.
FACEWP.021-Version B of the format.
These are held in the FACES subdirectory.

In Windows (any version), you can associate the extension 021 with the program
VIEW021.EXE (available at http://lostsock.bored.org). VIEW021 is an 021 viewer
and indexer application. As well as being a general viewer, it can make use of
4DOS description files. Of course, VIEW021 can also be used in plain DOS.

LSS has also created the MAINT021.EXE program, which is a maintainance appli-
cation for the 021 format. You can create new 021A or 021B files, add/remove
images from any position, even import and export in several formats. Cropping
and resizing is available, as well as some color reduction options. MAINT021
is VERY powerful, and may be available now (or maybe not...)

IN THE FUTURE:
Four more formats will be added to the specification. The KBV6B compression
theory in A and B types, and the LZW compression theory in A and B types.
KBV6B is a complex, reasonably good RLE compression theory, and LZW is the
very powerful Unisys compression theory used in GIF images. If anybody wishes
to contribute a LOSSLESS compression theory, please contact us:

kaddash@rocketmail.com

The current versions are uncompressed. However, this means maximum speed in
indexing and loading, but also maximum space taken on a disk. When we add the
compression theories to the format, seek time will slow down, and the header
will grow as well, as we will have to build a byte index to the images.
However, the size of the files will probably be reduced overall.

Any suggestions, feel free to contact us at the above address!
-nekrophidius of lost sock software

COPYRIGHT INFORMATION:
LWZ is patented by Unisys Corporation and is a registered trademark.
QuickBASIC is copyrighted by Microsoft Corporation and is a registered trade-
mark.
KBV6B is a trademark of Kaddash Enterprises, Incorporated.
021A and 021B are released into the public domain. This means that no copy-
right or trademark has or can be established. This was done by our own free
will to advance the education and usefulness of QB.

------------------------------------------------------------------------------

EXAMPLE OF LOADING
To load a type A file, all you need to know is the header information and then
use the file pointer to point to the file you need. For example:

------------------------------------------------------------------------------

'Set up an object for this routine

TYPE GfxArray
        ID      AS STRING * 30
        Height  AS INTEGER
        Width   AS INTEGER
END TYPE

DIM Gfx AS GfxArray

'Load the header information

OPEN "TEST.021" FOR BINARY AS #1
GET #1, , Gfx

'Create an array to hold the image

ArraySize! = (Gfx.Height * Gfx.Wide) / 2 + 1
DIM Sprite (ArraySize!)

'Determine your sprite number and start to fill the array

SpriteNumber = 12
Sprite(0) = Gfx.Wide * 8  'For QB compatibility
Sprite(1) = Gfx.Height    'For QB compatibility

'Point your file pointer to the proper location

SEEK 1, ((Gfx.Height * Gfx.Wide) * SpriteNumber) + 35

'Load your sprite data now!

FOR a = 2 TO ArraySize!
GET #1, , Sprite(a)
NEXT a

'Done!

CLOSE 1

------------------------------------------------------------------------------

Loading a Type B file is similar, with a couple of exceptions. First of all,
you need to take into account the presence of a palette in the image. The
indexing method is slightly different. You need to give yourself an extra 48
bytes of pointer space per image skipped so things load properly. This can be
done fairly easy:

------------------------------------------------------------------------------

'Point your file pointer to the proper location

SEEK 1, (((Gfx.Height * Gfx.Wide) * SpriteNumber) + 35) + SpriteNumber * 48)

------------------------------------------------------------------------------

If SpriteNumber is 0, the 48 * 0 is going to equal 0. Otherwise, you will skip
an extra 48 bytes per image index. This is to account for the 48 byte palette
that accompanies all images in a type B file.

The second difference in the type B format is the palette itself. You should
load it into a 48-byte STRING (if using QB) or a 48-byte array (other langs).
Example given for QB only:

------------------------------------------------------------------------------

'Load the palette after the image

DIM Pal AS STRING * 48
GET #1, , Pal

------------------------------------------------------------------------------

What you do with it from there is up to you.

There is a way of determining how many graphic arrays are in a single 021
file, but as an extra exercise for you, see if you can come up with the
formula. Here's a hint-it has everything to do with file SIZE...

------------------------------------------------------------------------------

So as you can see, the 021 formats are comprehensive and quick. These two
qualities make for great potential in the QB game world, and I hope that more
people make use of this kind of technique. This technique can be applied to
most any file type, as long as the read code is programmed to do indexing.

------------------------------------------------------------------------------

Some of us happened to miss a certain drawback to the SEEK method...apparently
SEEK can only SEEK so high into a file, this means that it is very possible
that we will have to use more than two face files in WOS. We'll keep you
posted.
