hi

does any one have the file structure for spr & pal files
found on lemmingswin

ta.

Lemmings for Windows sprite format (*.SPR)

The "SPR" files start with the ID "SRLE", followed by two words in little endian format representing the number of animation frames stored within this file and the offset to the first frame:

"SRLE" (numOfFrames) (firstFrameOffset) ....

In some cases, there is data stored between the file header and the first animation frame. Dunno what this is, maybe colour/transparency information or data to group the frames within the file (e.g. all animation frames of all lemmings are stored in one file, so one would have to figure out which frames belong together.

Each animation frame starts with a header consisting of 6 words:
xOffset, yOffset, maxDataWidth, dataHeight, imageWidth, imageHeight.

This file format seems to be optimized for objects surrounded by transparent pixels, since surrounding transparent pixels are not stored at all. The size of the image to be created is given by imageWidth and imageHeight - however only dataHeight lines of information are stored inside the file. Each line can contain up to maxDataWidth bytes, where each byte represents one pixel (256 colour indexed mode). xOffset and yOffset determine where the the stored subimage (data) is located inside the target picture. E.g. if the image is 16x16 pixels in size but only data for 8x8 pixels is stored, offsets of 4 (x,y) would mean that the subimage is surroundes by a transparent frame with a width of 4 pixels:

    xofs
  y ................
  o ................
  f ................
  s ................
    ....xxxxxxxx....
    ....xxxxxxxx....
    ....xxxxxxxx....
    ....xxxxxxxx....
    ....xxxxxxxx....
    ....xxxxxxxx....
    ....xxxxxxxx....
    ....xxxxxxxx....
    ................
    ................
    ................
    ................

   
After the 6 word frame header, the image data follows line by line. Note that there are as many lines as given by dataHeight.
The lines have the following format:
[x offset] (0x80+len) ... len bytes ... (0x80)

The x offset can be omitted - then it's 0. Obviously it can't be larger than 0x7f, since then it could not be distinguished from the start of line character, which includes the length of the line (0x80 + len).
This also means that a line can't be larger than 0x7f since else it wouldn't fit into a byte.
Interesting enough, there are frames which are wider than 0x7f pixels, e.g. in ES.SPR where a width of 0x88 is used. However, still the start byte can't be larger than 0xff, so 0xff means: 0x7f bytes to follow.

E.g. the line
0x84 0xAA 0xBB 0xCC 0xDD 0x80
represents four bytes image data (AA,BB,CC,DD) starting at offset 0.

0x03 0x85 0xAA 0xBB 0xCC 0xDD 0xEE 0x80
represents 5 bytes image data (AA,BB,CC,DD,EE) starting at offset 3.

So each line can have a different length, but (excluding start and stop byte) must not exceed the maximum width given in the header (probably for memory allocation issues).

If there is more than one frame, the header (6 words) of the next frame follows directly after the last line of the previous frame.

Since the file must end with a data line, each files ends with the "end of line" marker, namely 0x80.

Special rules:
A data line might consist of several sub lines:
05 84 30 2C 2C 2C ## 02 84 30 30 2C 2C 80
At the (virtual) position "##", no 0x80 is found: this means, the line is continued after the following offset (0x02). Only if a 0x80 is found after the end of a (sub) line, the line is finished.

Also empty lines are defined (start = 0x80, no end character):
80

Furthermore the large tile sets have an additional line offset: if the start character is 0x7f, which whould normally just be an offset of 0x7f, there is always (?) a 2nd byte which is added to the first one:
7F 0B 94 1A 0B 18 ...
The offset here is not 0x7f, but 0x7f+0x0b, the following 0x94 is the start character for a data line of 0x14 elements.

The extended offsets marked by 0x7f can be appended multiple times. E.g.  
7f 7f 7f 11
means 0x7f + 0x7f + 0x7f + 0x11


Palette files (*.PAL)
The spr files rely on the according style palette to be loaded with a higher index.
Each palette file contains 0x40 32bit entries (each in ARGB format). However the indeces used in the sprites usually start at 0x80 (or something).
Therefore the palette has to be copied to a higher position or the indices have to be patched.

    xofs
 y ................
 o ................
 f ................
 s ................
   ....xxxxxxxx....
   ....xxxxxxxx....
   ....xxxxxxxx....
   ....xxxxxxxx....
   ....xxxxxxxx....
   ....xxxxxxxx....
   ....xxxxxxxx....
   ....xxxxxxxx....
   ................
   ................
   ................
   ................

Teletyping makes that more readable.

Here's my FreeBASIC code for reading SPR files, if it's of any use to you. (It doesn't do palettes.)

I was a bit vague about palettes, so here again:
PAL files start with 0x20,P,A,L, followed by the number of entries (16bit little endian), followed by
the entries: 32bit (little endian) for one RGB value.
Some SPR files (e.g. styles) rely on the according style palette to be loaded with a higher index.
These palettes only contain 0x40 values instead of 0x100 like FE.PAL.
However the indeces used in the "styles" sprites start at 0x80.
Therefore the palette has to be copied to a higher position or the indices have to be patched.