Difference between revisions of "Sacred"

From XentaxWiki
Jump to: navigation, search
m (Change ID into Version. Added place for Headers yet to decode. Wrote which .pak file use which header)
(Notes and ideas about World / Tiles image relations)
Line 150: Line 150:
 
<br>
 
<br>
 
The encoding of the pixel is Top to Bottom, and for each line is Left to Right. Note : the Alpha channel IS really used (it's not just for padding), check H_KEULE_02_1.TGA from texture00.pak for a good example (16 levels of alpha here)<br>
 
The encoding of the pixel is Top to Bottom, and for each line is Left to Right. Note : the Alpha channel IS really used (it's not just for padding), check H_KEULE_02_1.TGA from texture00.pak for a good example (16 levels of alpha here)<br>
 +
<br>
 +
</tt>
 +
 +
=== Some notes and ideas about World / Tiles relations ===
 +
 +
<tt>
 +
For the purpose of only extracting images, PAK\Tiles.pak is useless. It has nothing really more than what the files PAK\Texture*.pak contain. Tiles.pak looks like just a huge collection of tiles reference... That's why it's maybe related to the system the game use to build its world.<br>
 +
<br>
 +
Take 1 image from Texture.pak, name ISOxxxx.TGA. It's an image of 256*256 pixels, containing up to 18 tiles of 100*50 pixels each. In Tiles.pak, we have enties for all such tiles of each image, so for an image with 18 tiles we have 1 entry in Texture.pak but 18 entries in Tiles.pak. Let's take an example :<br>
 +
<br>
 +
:In Texture.pak, the entry 1257 is ISO01.TGA. Once extracted, we have an image of 256*256 pixels, that contains 18 tiles (rock, earth and 2 kind of grass).<br>
 +
<br>
 +
:In Tiles.pak, the entries 18 to 35 use all the same filename (iso01.tga), but each entry has a diferent Tile position (from 0 to 17).<br>
 +
<br>
 +
So here's how it is *maybe* working... When a map tells to the game that a certain tile is to be displayed at coordinate X & Y, it's a uint16 number (16 bits). This is the index entry in Tiles.pak. The game look in Tiles.pak, in the offset table, at the entry. It find an offset and go there. It then extract the block of data for that tile. It learns the Texture.pak index entry, and the Tile position within that image. Now it open Texture.pak, read the appropriate offset and go there, and find the datas of the image. It extract the image (256*256), and use only 1 tile within this image (using the Tile position).<br>
 +
<br>
 +
In sumary, there are chances that the world map format use only 16bits number for the floors. Using Tiles.pak and Texture.pak one after the other, it knows which tile image to display. By the way, in Sacred+, Tiles.pak contains 47099 entries, Texture.pak 17400, Texture00.pak 64 and Texture01.pak 346 entries.<br>
 
<br>
 
<br>
 
</tt>
 
</tt>

Revision as of 23:41, 26 October 2005

Choose archive extension:

PAK


Format Specifications

byte {3}     - Header
byte {1}     - Version

if (header == TEX && version == 3){

// PAK\Texture*.pak
uint32 {4}   - Number Of Files
uint32 {4}   - Unknown
byte {244}   - null


// for each file
uint32 {4}   - Type ID
uint32 {4}   - Offset
uint32 {4}   - Compressed Size


// for each file
char {32}    - Filename (null)
uint16 {2}   - X Image Size
uint16 {2}   - Y Image Size
byte {1}     - Type ID
uint32 {4}   - Compressed Size
byte {39}    - null Padding
byte {X}     - File Data

}
else if (header == ISO && version == 3){

// PAK\Tiles.pak
uint32 {4}   - Number Of Files
uint32 {4}   - Number Of Files Yep, again
byte {244}   - null


// for each file
uint32 {4}   - Tag_66 Always = 66
uint32 {4}   - Offset
uint32 {4}   - Tag_64 Always = 64


// for each file
char {32}    - Filename (null)
uint32 {4}   - Entry Index within the file PAK\Texture.pak (Header = TEX)
uint32 {4}   - Tile position within texture image Range from 0 to 17
byte {6}     - null
byte {1}     - Tag_1 Always = 1
byte {17}    - null

}
else if (header == CIF && version == 0){

// PAK\Creature.pak
uint32 {4}   - Number Of Files
uint32 {4}   - Unknown
byte {244}   - null


// for each file
byte {64}    - File Data

}
else if (header == WPN && version == 8){

// PAK\Weapon.pak
uint32 {4}   - Number Of Files
uint32 {4}   - Unknown


// for each file
byte {322}   - File Data

}
else if (header == SND && version == 1){

// PAK\Sound.pak
uint32 {4}   - Number Of Files
uint32 {4}   - Unknown
byte {244}   - null


// for each file
uint32 {4}   - Type ID
uint32 {4}   - Offset
uint32 {4}   - Compressed Size

}
else if (header == ITM && version == 5){

// PAK\Items*.pak
uint32 {4}   - Number Of Files
uint32 {4}   - Unknown
byte {244}   - null


// for each file
uint32 {4}   - Type ID
uint32 {4}   - Offset
uint32 {4}   - Compressed Size


// for each file
byte {56}    - Unknown
char {32}    - Filename (null)
byte {X}     - File Data

}
else if (header == ITM && version == 3){

// PAK\Items*.pak ? I don't have ITM file(s) with version = 3, in Sacred+
uint32 {4}   - Number Of Files
uint32 {4}   - Unknown
byte {244}   - null


// for each file
uint32 {4}   - Type ID
uint32 {4}   - Offset
uint32 {4}   - Compressed Size


// for each file
char {32}    - Filename (null)
byte {X}     - File Data

}
else if (header == MDL && version == 3){

// PAK\Models*.pak
Unknown

}
else if (header == MHP && version == 1){

// PAK\Motions.pak
Unknown

}
else if (header == MIX && version == 0){

// PAK\Mixed.pak
Unknown

}
else if (header == OBJ && version == 1){

// World\Floor.pak, World\Static.pak,
Unknown

}
else if (header == SPF && version == 1){

// PAK\sndProfiles.pak
Unknown

}
else if (header == TRG && version == 1){

// World\Triggers.pak
Unknown

}

File Data Format in TEX (textures) PAK

This is a simple zlib-compressed image, as the first character of the File Data indicates (it's an 'x'). The size of this File Data is 'Compressed Size' bytes, the size of the uncompressed file is :

   Uncompressed File Data Size = (X Image Size) * (Y Image Size) * 2

Once uncompressed, you have directly the pixels. Each pixel is an unsigned word (16 bits). It contains Alpha, Red, Green and Blue componant values, and each are 4 bits. A mapping of these bits would give :

   (highest bit) AAAARRRRGGGGBBBB (lowest bit)

The encoding of the pixel is Top to Bottom, and for each line is Left to Right. Note : the Alpha channel IS really used (it's not just for padding), check H_KEULE_02_1.TGA from texture00.pak for a good example (16 levels of alpha here)

Some notes and ideas about World / Tiles relations

For the purpose of only extracting images, PAK\Tiles.pak is useless. It has nothing really more than what the files PAK\Texture*.pak contain. Tiles.pak looks like just a huge collection of tiles reference... That's why it's maybe related to the system the game use to build its world.

Take 1 image from Texture.pak, name ISOxxxx.TGA. It's an image of 256*256 pixels, containing up to 18 tiles of 100*50 pixels each. In Tiles.pak, we have enties for all such tiles of each image, so for an image with 18 tiles we have 1 entry in Texture.pak but 18 entries in Tiles.pak. Let's take an example :

In Texture.pak, the entry 1257 is ISO01.TGA. Once extracted, we have an image of 256*256 pixels, that contains 18 tiles (rock, earth and 2 kind of grass).


In Tiles.pak, the entries 18 to 35 use all the same filename (iso01.tga), but each entry has a diferent Tile position (from 0 to 17).


So here's how it is *maybe* working... When a map tells to the game that a certain tile is to be displayed at coordinate X & Y, it's a uint16 number (16 bits). This is the index entry in Tiles.pak. The game look in Tiles.pak, in the offset table, at the entry. It find an offset and go there. It then extract the block of data for that tile. It learns the Texture.pak index entry, and the Tile position within that image. Now it open Texture.pak, read the appropriate offset and go there, and find the datas of the image. It extract the image (256*256), and use only 1 tile within this image (using the Tile position).

In sumary, there are chances that the world map format use only 16bits number for the floors. Using Tiles.pak and Texture.pak one after the other, it knows which tile image to display. By the way, in Sacred+, Tiles.pak contains 47099 entries, Texture.pak 17400, Texture00.pak 64 and Texture01.pak 346 entries.

MultiEx BMS Script

Not written yet

Compatible Programs