SHA Format
From ModdingWiki
The SHA file contains all the graphical elements in the game, grouped in tile sets.
Contents |
File format
The file starts with an array of 128 32-bit unsigned integers. Only the first half of these contain actual values. The second half are null. These numbers represent the position of the first byte, of each tile set in the file.
The file continues with an array of 128 16-bit unsigned shorts. Again, only the first 64 contain values. These numbers represent the length, in bytes, of each respective tile set.
The tile set objects start at byte 768, i.e. ((128 * 4) + (128 * 2)).
It is important to note that these values are stored little-endian. This means that for example the offset 768 is stored as the four bytes 00-03-00-00, not as 00-00-03-00. This is true for both offsets and lengths.
Tile Set Objects
| Data type | Description |
|---|---|
| UINT8 | NumShapes number of tiles in the tile set. |
| UINT16 | NumRots (as documented in the Xargon source code) doesn't seem to have any use and is generally 1. |
| UINT16 | LenCGA how many bytes of memory will be used for data in CGA mode after decompression. |
| UINT16 | LenEGA how many bytes of memory will be used for data in EGA mode after decompression. |
| UINT16 | LenVGA how many bytes of memory will be used for data in VGA mode after decompression. |
| UINT8 | NumColorBits bits of depth in color. 3=8 colors, 4=16 colors, 8=256 colors, etc. 0 means there is no palette so the colors are mapped directly to the current palette (for example 1=1, etc) |
| UINT16 | Flags Defines how the data should be treated: +1 = SHM_FONTF (font) +4 = SHM_BLFLAG (level tile set) |
Color Table (for indexed color under 8 bits)
Following the tile set data is an array of colour values if the Bits Per Color value is less than 8. Each array item contains 4 unsigned bytes, representing CGA, EGA and VGA, respectively, and then a null value. The array is as long as the number of colours, determined by the colour mode value. Each byte maps to the index of a colour in the palette. If there are no colours required, the bytes stored in the shape directly correlate with the game's palette.
Tiles
Following palette is the array of tile objects. Each tile has a three byte header: two unsigned bytes representing the width and height of the tile image and a third byte representing the compression type. See Compression Types below.
There is then a string of bytes, as long as the image area (width * height). Each byte represents a pixel. The first byte is the pixel at 0, 0 and the last byte is the pixel at w, h. The byte's value maps to a colour in the tile set's colour palette.
Full palettes stored in the SHA file
While no current Jill games use this feature, it's part of the game's code to accept palette substitutions. For this to work, the entry must be 8-bit color and 64x12 in size. Additionally, it must be "requested" by the game. Instead of reading this as a standard shape, the game will instantly use this as the new palette.
Compression Types
| Value | Compression | Description |
|---|---|---|
| 0 | BYTE | Each pixel is one byte regardless of bit depth. |
| 1 | PLAIN | Pixels are represented in their raw form. There are 8 bits per byte. So if your image is 4 bits it will store 2 pixels per byte and with 2 bits it will store 4 pixels per byte. |
| 2 | RLE |
Jill of the Jungle uses the earliest known version of the engine, which doesn't support anything but BYTE. Kiloblaster is a further updated version of the engine which supports PLAIN, at least. It's likely that these compression features were planned but not implemented until after a few releases of the engine.
