Raptor PIC Format

From ModdingWiki
Jump to: navigation, search
Raptor PIC Format
320px
There is no example of an image in this format — upload one!
Format typeImage
HardwareVGA
Colour depth8-bit (VGA)
Minimum size (pixels)0×0
Maximum size (pixels)2147483648×2147483648
PaletteShared
Plane count1
Transparent pixels?No
Hitmap pixels?No
Games

The Raptor PIC Format is used by Raptor to store various images, sprites and tiles. The format is raw VGA data with a custom header.

File format

Data type Name Description
UINT32LE unknown1 Always 1 when iLineCount is 0
UINT32LE unknown2 Always 1 when iLineCount is 0
UINT32LE iLineCount Number of non-transparent image lines?
UINT32LE width Width of the image, in pixels
UINT32LE height Height of the image, in pixels
UINT8 data[] 8bpp raw VGA data, one byte per pixel; or sprite layout blocks

! The first two values are unknown. Possibly they might be hotspot coordinates. If iLineCount is 0 then the two values are always 1.

If iLineCount is 0, then the rest of the file are the raw pixel values (width*height bytes total) and the image has no transparent parts.

If iLineCount is NOT 0, then the rest of the file consists of multiple blocks in the following format:

 0 | UINT32LE     | iPosX		relative to left edge of image
 4 | UINT32LE     | iPosY		relative to top edge of image
 8 | UINT32LE     | iLinearOffset	relative to top-left pixel
12 | UINT32LE     | iCount		number of pixels to write (in that row)
16 | BYTE[iCount] | bPixels		pixels to write

The iLinearOffset value can be used to speed up the drawing process to a 320x200 pixel VGA video buffer. The iLinearOffset value could also be calculated like this:

iLinearOffset = iPosX + 320*iPosY

This formula could also be used as a validity check.

The actual value of iLineCount should not be used to detect the end of the image data. The PIC files appear to always end with a terminating data block where both iLinearOffset and iCount are set to -1 (0xFFFFFFFF) with no additional pixel data following that block.

Credits

This file format, including the decryption algorithm, was reverse engineered by Malvineous. Sprite format reverse engineered by K1n9_Duk3. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)