SPEC Format
The SPEC format is used by Abuse to store levels, save games, and graphical data. Level files can be edited using the built-in editor while Satan Paint can load and save graphics archives, as well as including handling for special tile properties like collision boundaries.
SPEC files store multiple-byte numbers in little endian form. This appears to be the case even in ports for systems that are natively big endian (e.g. Motorola-based Macintosh computers).
File format
The header is as follows:
| Data type | Description |
|---|---|
| ASCIIZ | Format label, "SPEC1.0" |
| INT16LE | number of entries in the index |
Next comes an array of index entries:
| Data type | Description |
|---|---|
| INT8 | Type (see specs.hpp) |
| INT8 | Length of file name (NB: not the length of the file itself) |
| ASCIIZ | File name string, of the length specified immediately prior |
| INT8 | ! ceninan says "a flag of some sort; I don't think this was ever implemented, and probably had to do with linking files...?" |
| INT32LE | Entry size (0 is an allowed value, for "tag" entries that exist only for the entry name) |
| INT32LE | Offset (Absolute from start of SPEC file) |
The actual entries follow, with the handling for them usually, but not always, decided by the type value specified in the index.
Entry type 2 - SPEC_PALETTE
A fairly standard palette format, with the addition of being able to handle variable numbers of colors.
| Data type | Description |
|---|---|
| INT16LE | Number of colors |
An array of colors, according to the number above, follows:
| Data type | Description |
|---|---|
| INT8 | Red component |
| INT8 | Green component |
| INT8 | Blue component |
Entry type 5 - SPEC_FORETILE
Foreground tiles - ! editor manual says a tile is (always?) 30x15, so varying sizes probably mean varying bounding polys. For these entries, the name of the tile lump appears to be used as the editor's tile number. It appears that Abuse allows tiles to have polygonal boundaries for collision, the exact format for these needs to be confirmed.
| Data type | Description |
|---|---|
| INT16LE | Width |
| INT16LE | Height |
| INT8 array | Pixels, as palette indices |
| INT16LE | ! "next"? |
| INT8 | ! ignored (unimplemented feature?) |
| UINT8 | ! should be count of boundary points? |
! ? variable length boundary (array of int8 x,y coordinate pairs defining the solid space of the tile, e.g. a rectangle) this appears to draw a polygon from dot to dot so for a rectangle, five points are needed? (duplicate of the first to be last) is there a formal count? (i.e. is the prior 05 in the observed tiles part of this, rather than just "to end of file"?)
Entry type 6 - SPEC_BACKTILE
! Are these always 60x30? Name of the tile lump appears to be used as tile number.
TENTATIVE:
| Data type | Description |
|---|---|
| INT16LE | Width |
| INT16LE | Height |
| INT8 array | Pixels, as palette indices |
| INT16LE | ! "create_descriptor" maybe always 0 for backtiles |
Entry type 18 - SPEC_GRUE_FGMAP
Used in levels, ! probably for foreground layout? (lump name is probably important)
| Data type | Description |
|---|---|
| INT32LE | Width |
| INT32LE | Height |
| INT16LE array of width*height | Tile values |
Entry type 19 - SPEC_GRUE_BGMAP
Used in levels, ! probably for background layout? (lump name is probably important)
| Data type | Description |
|---|---|
| INT32LE | Width |
| INT32LE | Height |
| INT16LE array of width*height | Tile values |
Entry type 20 - SPEC_DATA_ARRAY
! This is sort of a "catchall" entry type, and the file name of the entry matters to its interpretation. These are particularly frequently used in level files.
Credits
Some basic information on the container format was published by ceninan. Further investigation into the data format specifications, based on both hex examination of the files and a reading of the released Abuse source code, is being added by Mysterioso AKA ETTiNGRiNDER.