| Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
trs:fundamentals [2017/01/05 13:22]
zdimension [File Types] |
trs:fundamentals [2017/02/04 17:30]
stohrendorf ↷ Page moved from trs:fundamentals to trs:savegame:trs:fundamentals |
| ===== File Types ===== | ===== File Types ===== |
| |
| Tomb Raider is driven by various sets of files — [[file_formats|level files]], [[scripting_tr2_tr3|script]] [[scripting_tr4_tr5|files]], FMVs, [[sound#audio_tracks|audio tracks]] and [[sound#sound_files|sound files]]. In TR4 and TR5, there is also specific file type which contains cutscene data — [[cutseq|cutseq pack]]. | Tomb Raider is driven by various sets of files — [[trs:savegame:trs:file_formats|level files]], [[trs:scripting_tr2_tr3|script]] [[trs:scripting_tr4_tr5|files]], FMVs, [[trs:sound#audio_tracks|audio tracks]] and [[trs:sound#sound_files|sound files]]. In TR4 and TR5, there is also specific file type which contains cutscene data — [[trs:savegame:trs:cutseq|cutseq pack]]. |
| |
| ==== The Script Files ==== | ==== The Script Files ==== |
| Since TR4, the level file is divided into //several chunks//, each of them being compressed with //zlib//. Usually, each chunk of compressed data is preceded by two 32-bit unsigned integers defining the //uncompressed size// of the chunk and the //compressed size// of the chunk. Therefore, the engine allocates an empty buffer equal to the //uncompressed size// of a specific chunk, and another buffer equal to the //compressed size//. The compressed data is loaded directly within it based on the //compressed size//. The compressed data is then decompressed into the result buffer and the buffer containing the compressed data is destroyed. In TR5, those chunks aren’t compressed anymore. | Since TR4, the level file is divided into //several chunks//, each of them being compressed with //zlib//. Usually, each chunk of compressed data is preceded by two 32-bit unsigned integers defining the //uncompressed size// of the chunk and the //compressed size// of the chunk. Therefore, the engine allocates an empty buffer equal to the //uncompressed size// of a specific chunk, and another buffer equal to the //compressed size//. The compressed data is loaded directly within it based on the //compressed size//. The compressed data is then decompressed into the result buffer and the buffer containing the compressed data is destroyed. In TR5, those chunks aren’t compressed anymore. |
| |
| > **Note** | <note> |
| > | It’s good to note the origins of level file extension. While it is obvious that TR2/TR4/TRC extensions specify abbreviations of the game name. ''%%.PHD%%'' is actually the initials of the //Lead Programmer// for Tomb Raider 1: //Paul Howard Douglas//. Looks like this programmer contributed a lot of the code during early development stages of Tomb Raider. This is suggested because the //phd// initials also became a prefix for several helper functions in the original source code, for instance: ''%%phd_sin%%'', ''%%phd_cos%%'' etc. Most likely, he was also responsible for developing the level file structure for Tomb Raider. |
| > It’s good to note the origins of level file extension. While it is obvious that TR2/TR4/TRC extensions specify abbreviations of the game name. ''%%.PHD%%'' is actually the initials of the //Lead Programmer// for Tomb Raider 1: //Paul Howard Douglas//. Looks like this programmer contributed a lot of the code during early development stages of Tomb Raider. This is suggested because the //phd// initials also became a prefix for several helper functions in the original source code, for instance: ''%%phd_sin%%'', ''%%phd_cos%%'' etc. Most likely, he was also responsible for developing the level file structure for Tomb Raider. | </note> |
| |
| ==== FMVs (Full Motion Videos) ==== | ==== FMVs (Full Motion Videos) ==== |
| There are certain cases where special caution must be paid. A multiplication $f = f_1 \cdot f_2$ must be calculated as | There are certain cases where special caution must be paid. A multiplication $f = f_1 \cdot f_2$ must be calculated as |
| |
| $f = f_1 \cdot f_2 \Leftrightarrow (p_1/2^{16}) \cdot (p_1/2^{16}) \Leftrightarrow f = \frac{p_1 \cdot p_2}{2^{16}} \Leftrightarrow p \cdot 2^{16} = \frac{p_1 \cdot p_2}{2^{16}} \Leftrightarrow p = \frac{p_1 \cdot p_2}{2^{32}}$ | $f = f_1 \cdot f_2 \Leftrightarrow f = (p_1/2^{16}) \cdot (p_1/2^{16}) \Leftrightarrow f = p/2^{16} = \frac{p_1 \cdot p_2}{2^{32}} \Leftrightarrow p = \frac{p_1 \cdot p_2}{2^{16}}$ |
| |
| ==== Data Alignment ==== | ==== Data Alignment ==== |
| ==== Colours ==== | ==== Colours ==== |
| |
| All colours in TR are specified either explicitly (using either the [[fundamentals#tr_colour|[tr_colour]]] structure, described below, 16-bit structures or 32-bit structures) or implicitly, by indexing one of the palettes. However, it is only applicable to TR1-3 — there is no palette in TR4 and TR5. | All colours in TR are specified either explicitly (using either the [[trs:fundamentals#tr_colour|[tr_colour]]] structure, described below, 16-bit structures or 32-bit structures) or implicitly, by indexing one of the palettes. However, it is only applicable to TR1-3 — there is no palette in TR4 and TR5. |
| |
| In TR1-3, mesh surfaces could be either //coloured// or //textured//. //Coloured// surfaces are “painted” with a single colour that is either specified explicitly or using an index into the palette. | In TR1-3, mesh surfaces could be either //coloured// or //textured//. //Coloured// surfaces are “painted” with a single colour that is either specified explicitly or using an index into the palette. |
| //Textured// surfaces map textures (bitmapped images) from the texture tiles (textiles) to each point on the mesh surface. This is done using conventional UV mapping, which is specified in “Object Textures” below; each object texture specifies a mapping from a set of vertices to locations in the textile, and these texture vertices are associated with position vertices specified here. Each textile is a 256x256 pixels wide area. | //Textured// surfaces map textures (bitmapped images) from the texture tiles (textiles) to each point on the mesh surface. This is done using conventional UV mapping, which is specified in “Object Textures” below; each object texture specifies a mapping from a set of vertices to locations in the textile, and these texture vertices are associated with position vertices specified here. Each textile is a 256x256 pixels wide area. |
| |
| The 16-bit textile array, which contains [[fundamentals#tr_textile16|[tr_textile16]]] structures, specifies colours using 16-bit ARGB, where the highest bit (''%%0x8000%%'') is a crude alpha channel (really just simple transparency — //0 = transparent//, //1 = opaque//). The next 5 bits (''%%0x7C00%%'') specify the red channel, the next 5 bits (''%%0x03E0%%'') specify the green channel, and the last 5 bits (''%%0x001F%%'') specify the blue channel, each on a scale from 0..31. | The 16-bit textile array, which contains [[trs:fundamentals#tr_textile16|[tr_textile16]]] structures, specifies colours using 16-bit ARGB, where the highest bit (''%%0x8000%%'') is a crude alpha channel (really just simple transparency — //0 = transparent//, //1 = opaque//). The next 5 bits (''%%0x7C00%%'') specify the red channel, the next 5 bits (''%%0x03E0%%'') specify the green channel, and the last 5 bits (''%%0x001F%%'') specify the blue channel, each on a scale from 0..31. |
| |
| {{:icons:tr1.png?nolink|TR1 only}}{{:icons:tr2.png?nolink|TR2 only}}{{:icons:tr3.png?nolink|TR3 only}} If, for some reason, 16-bit textures are turned off, all colours and textures use an 8-bit palette that is stored in the level file. This palette consists of a 256-element array of [[fundamentals#tr_colour|[tr_colour]]] structures, each designating some colour; textures and other elements that need to reference a colour specify an index (0..255) into the ''%%Palette[]%%'' array. There is also a 16-bit palette, which is used for identifying colours of solid polygons. The 16-bit palette contains up to 256 four-byte entries; the first three bytes are a [[fundamentals#tr_colour|[tr_colour]]], while the last byte is ignored (set to 0). | {{:icons:tr1.png?nolink|TR1 only}}{{:icons:tr2.png?nolink|TR2 only}}{{:icons:tr3.png?nolink|TR3 only}} If, for some reason, 16-bit textures are turned off, all colours and textures use an 8-bit palette that is stored in the level file. This palette consists of a 256-element array of [[trs:fundamentals#tr_colour|[tr_colour]]] structures, each designating some colour; textures and other elements that need to reference a colour specify an index (0..255) into the ''%%Palette[]%%'' array. There is also a 16-bit palette, which is used for identifying colours of solid polygons. The 16-bit palette contains up to 256 four-byte entries; the first three bytes are a [[trs:fundamentals#tr_colour|[tr_colour]]], while the last byte is ignored (set to 0). |
| |
| {{:icons:tr4.png?nolink|TR4 only}}{{:icons:tr5.png?nolink|TR5 only}} The 32-bit textile array, which contains [[fundamentals#tr4_textile32|[tr4_textile32]]] structures, specifies colours using 32-bit ARGB, where the highest byte (A) is unused. The next bytes specify (in this order) the red / green / blue channels. The 16-bit and 32-bit textile arrays depict the same graphics data, but of course the 32-bit array has a better colour resolution. It’s the one used if you select a 32-bit A8R8G8B8 texture format in the setup menu from TR4 and TR5. | {{:icons:tr4.png?nolink|TR4 only}}{{:icons:tr5.png?nolink|TR5 only}} The 32-bit textile array, which contains [[trs:fundamentals#tr4_textile32|[tr4_textile32]]] structures, specifies colours using 32-bit ARGB, where the highest byte (A) is unused. The next bytes specify (in this order) the red / green / blue channels. The 16-bit and 32-bit textile arrays depict the same graphics data, but of course the 32-bit array has a better colour resolution. It’s the one used if you select a 32-bit A8R8G8B8 texture format in the setup menu from TR4 and TR5. |
| |
| ==== Meshes and Sprites ==== | ==== Meshes and Sprites ==== |
| The only difference is the extra field ''%%Effects%%''. It has this layout: | The only difference is the extra field ''%%Effects%%''. It has this layout: |
| |
| * //Bit 0:// if set, face has //additive alpha blending// (same meaning that when the ''%%Attribute%%'' field of [[miscellany#tr_object_texture|[tr_object_texture]]] is 2, but this flag overrides it). | * //Bit 0:// if set, face has //additive alpha blending// (same meaning that when the ''%%Attribute%%'' field of [[trs:miscellany#tr_object_texture|[tr_object_texture]]] is 2, but this flag overrides it). |
| |
| |{{:illustrations:face_blend.jpg?nolink|illustrations/face_blend.jpg}}|{{:illustrations:face_noblend.jpg?nolink|illustrations/face_noblend.jpg}}| | |{{:illustrations:face_blend.jpg?nolink|illustrations/face_blend.jpg}}|{{:illustrations:face_noblend.jpg?nolink|illustrations/face_noblend.jpg}}| |
| }; | }; |
| </code> | </code> |
| All the info about ''%%Texture%%'' and ''%%Effects%%'' fields is also similar to same info from [[fundamentals#tr_face4|[tr_face4]]] and [[fundamentals#tr4_mesh_face4|[tr4_mesh_face4]]] respectively. | All the info about ''%%Texture%%'' and ''%%Effects%%'' fields is also similar to same info from [[trs:fundamentals#tr_face4|[tr_face4]]] and [[trs:fundamentals#tr4_mesh_face4|[tr4_mesh_face4]]] respectively. |
| |
| ==== 8-bit Texture Tile ==== | ==== 8-bit Texture Tile ==== |
