XFF 2.0 (XPK) - MajickTek/XFF-SPEC GitHub Wiki

With everything put together, the pseudocode will be like this:

HEADER
{
  signature    U24
  version      U8
  length       U32
}

FILE
{
  header        HEADER
  imageCount    U16
  imageList     IMAGE[imageCount]
  soundCount    U16
  soundList     SOUND[soundCount]
  dataCount     U16
  dataList      DATA[dataCount]
}

IMAGE
{
  id            STRING
  width         U16
  height        U16
  compressed    U8
  dataLength    U32
  data          U8[dataLength]
}

STRING
{
  dataLength    U16
  data          U8[dataLength]
}

SOUND
{
  id            STRING
  dataFormat    U8
  dataLength    U32

  // 8-bit samples
  if( dataFormat == 0x00 )
  {
    data U8[dataLength]
  }

  // 16-bit samples
  if( dataFormat == 0x01 )
  {
    data U16[dataLength]
  }

  // 32-bit samples
  if( dataFormat == 0x02 )
  {
    data U32[dataLength]
  }
}

DATA
{
  id         STRING
  compressed U8
  dataFormat U8
  dataLength U32
  data       U8[dataLength]
}

And together this file is collectively named XFF 2.0, or XPK (eXtensible PacKage).

This file supports ZLib-compressing image data as well as generic data, and supports sound data with 8, 16, and 32-bit samples.

Using a bit of work the formats could potentially be separated from the XFF 2.0 file (.xff), to make new files named respectively to their data formats:

• .XPK for storing other files
• .XDAT for generic data
• .XSND for sound
• .XIMG for images
• and others

A video format could be created by embedding multiple images into a file (the images being compressed with ZLib). Sound would also be embedded in the file. A graphical program could play through all the images and play back the sound at the same time, and it would look like a video. In fact, this is how basic video formats work!