Difference between revisions of "Sacred"
Paul Siramy (talk | contribs) m |
Paul Siramy (talk | contribs) (→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} - Number of Strings <br> | ||
+ | <br> | ||
+ | : <font color="blue"> ''' // for each string ''' </font> <br> | ||
+ | :: uint32 {4} - String ID <br> | ||
+ | :: uint32 {4} - Offset <font color="purple"> '' (see note below)</font> <br> | ||
+ | :: uint32 {4} - Unknown <font color="purple"> '' (either 0 or 1)</font> <br> | ||
+ | :: uint32 {4} - String byte length <br> | ||
+ | <br> | ||
+ | : <font color="blue"> ''' // for each string ''' </font> <br> | ||
+ | :: byte {X} - 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 Type : Strings
- Endian Order : Little Endian
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
- uint32 {4} - String ID
- // for each string
- byte {X} - string, in unicode UTF-8 each character is coded into 2 bytes
- 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 Type : Archive
- Endian Order : Little Endian
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
- uint32 {4} - Type ID
- // 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
- char {32} - Filename (null)
}
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
- uint32 {4} - Header Type Always == 66
- // 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
- char {32} - Filename (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
- 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
- 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
- uint32 {4} - Type ID
}
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
- uint32 {4} - Type ID
- // for each file
- byte {55} - Unknown
- char {32} - Filename (null)
- byte {X} - File Data
- byte {55} - Unknown
}
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
- uint32 {4} - Type ID
- // for each file
- char {32} - Filename (null)
- byte {X} - File Data
- char {32} - Filename (null)
}
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
- uint32 {4} - File Type 64 = Model, 65 = Motion
- // for each file
- byte {X} - File Data
- 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
- uint32 {4} - Header Type 135 in World\Floor.pak, 134 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
- // World\Floor.pak
- }
- else if (Header Type == 134){
- // World\Static.pak
- byte {64} - Unknown
- // World\Static.pak
- }
- if (Header Type == 135){
}
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
- 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)
- (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)
- (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