Difference between revisions of "Sacred"

From XentaxWiki
Jump to: navigation, search
m
(→‎RES)
Line 2: Line 2:
  
 
Choose archive extension:  
 
Choose archive extension:  
 +
 +
== RES ==
 +
 +
* ''' Format Type ''':    Strings <br>
 +
* ''' [http://en.wikipedia.org/wiki/Endianness Endian Order] ''': Little Endian <br>
 +
 +
 +
=== Format Specifications ===
 +
 +
<tt><b>
 +
<br>
 +
uint32 {4}&nbsp;&nbsp; - Number of Strings <br>
 +
<br>
 +
: <font color="blue"> ''' // for each string ''' </font> <br>
 +
:: uint32 {4}&nbsp;&nbsp; - String ID <br>
 +
:: uint32 {4}&nbsp;&nbsp; - Offset <font color="purple"> '' (see note below)</font> <br>
 +
:: uint32 {4}&nbsp;&nbsp; - Unknown <font color="purple"> '' (either 0 or 1)</font> <br>
 +
:: uint32 {4}&nbsp;&nbsp; - String byte length <br>
 +
<br>
 +
: <font color="blue"> ''' // for each string ''' </font> <br>
 +
:: byte {X}&nbsp;&nbsp; - string, in unicode UTF-8 <font color="purple"> '' each character is coded into 2 bytes '' </font> <br>
 +
</b></tt>
 +
<br>
 +
 +
=== Note about the Offset ===
 +
 +
<tt>
 +
The <b>Offset</b> does not count the first 4 bytes of the file. It skip the <b>Number of Strings</b> data. So if you get for instance an offset = 295216, it means in fact that the string begin at <b>File offset</b> 295216 + 4 = 295220.
 +
</tt>
 +
<br>
 +
 +
  
 
== PAK ==  
 
== PAK ==  

Revision as of 16:39, 19 April 2006

Choose archive extension:

RES


Format Specifications


uint32 {4}   - Number of Strings

// for each string
uint32 {4}   - String ID
uint32 {4}   - Offset (see note below)
uint32 {4}   - Unknown (either 0 or 1)
uint32 {4}   - String byte length


// for each string
byte {X}   - string, in unicode UTF-8 each character is coded into 2 bytes


Note about the Offset

The Offset does not count the first 4 bytes of the file. It skip the Number of Strings data. So if you get for instance an offset = 295216, it means in fact that the string begin at File offset 295216 + 4 = 295220.


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}   - Header Type Always == 66
uint32 {4}   - Offset
uint32 {4}   - Header Byte Size 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 {55}    - Unknown
char {32}    - Filename (null)
byte {X}     - File Data

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

// PAK\Items*.pak ? There's no 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
uint32 {4} - Number Of Files
uint32 {4} - File index where to find the first Motion
uint32 {4} - Unknown
uint32 {4} - Tag_4AA Always 0x000004AA
uint32 {4} - Offsets Table Start File Offset where start the Offsets Table
uint32 {4} - Unknown
byte {X}   - null Normally 228 bytes


// (Offsets table) for each file
// First comes all the Models, only after comes all the Motions
uint32 {4} - File Type 64 = Model, 65 = Motion
uint32 {4} - Offset
uint32 {4} - Size Must be corrected, see note below


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

}
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){

uint32 {4}   - Number Of Files
uint32 {4}   - null
uint32 {4}   - null
byte {240}   - padding All set to 0xCC


// for each file
uint32 {4}   - Header Type 135 in World\Floor.pak, 134 in World\Static.pak
uint32 {4}   - Offset
uint32 {4}   - Header Byte Size 16 in World\Floor.pak, 64 in World\Static.pak


// for each file
if (Header Type == 135){
// World\Floor.pak
uint32 {4}   - File Index Always same as current file entry
uint32 {4}   - Unknown
uint32 {4}   - Tag_CDCDCDCD Always == 0xCDCDCDCD
uint32 {4}   - Next File Index Either 0, or File Index + 1
}
else if (Header Type == 134){
// World\Static.pak
byte {64}    - 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

if (Type ID == 4){

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)

}
else if (Type ID == 6){

This is a raw 32bpp image (not compressed). Each pixel is an unsigned dword (32 bits). It contains Alpha, Red, Green and Blue componant values, and each are 8 bits. A mapping of these bits would give :

(highest bit) AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB (lowest bit)

The encoding of the pixel is Top to Bottom, and for each line is Left to Right.

}

MDL (models) PAK, a note about the SIZE

The size may need adjustement, as follow :
    * If type == 64 (Models), TRUE_SIZE = (SIZE + 1194) / 2
    * For type == 65 (Motions), SIZE don't have to be changed

1194 is certainly not a random value. It's the size of the very first entry in Models*.PAK files, which is INVALID_MODEL and has a size of 1194.

Two Examples :
    * Models.pak, Entry 10 (RABBIT.GRN) has a type of 64 and a size of 94226. Its true size is in fact (94226 + 1194) / 2 = 47710 bytes. If you compare with the file offsets of this file and the one of the next entry, it's the same result.

    * Models.pak, Entry 1035 (RABT_IDLE_BH.GRN) has a type of 65 and a size of 35464. As having type of 65, it's already the correct size. If you compare with the file offsets of this file and the one of the next entry, it's the same result.

File Data Format in MDL (models) PAK

The format is still unknown, but we have a strong hint : each File Data start with a string of the original filename. For instance we find :
    * INVALID_MODEL
    * BEAR.GRN
    * DARKELVE_HELMET_METAL.GRN
    * AMAZONE_ARMOUR_LHARNISCH.GRN
    * DRAGON_SIRITHCAM.GRN
    * GIGANT_SPIDER.GRN
And GRN is the extention of Granny files, by RAD Game Tools : ([1])

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

Retrieved from "http://wiki.xentax.com/index.php?title=Sacred&oldid=2609"