| author | ecalot
<ecalot> 2006-01-22 14:18:35 UTC |
| committer | ecalot
<ecalot> 2006-01-22 14:18:35 UTC |
| parent | 06fef75cfd52e57d80b03729d99d1861b59b3fb1 |
| FP/doc/FormatSpecifications | +148 | -65 |
| FP/doc/FormatSpecifications.tex | +148 | -65 |
diff --git a/FP/doc/FormatSpecifications b/FP/doc/FormatSpecifications index 50baa24..9e5c253 100644 --- a/FP/doc/FormatSpecifications +++ b/FP/doc/FormatSpecifications @@ -33,8 +33,8 @@ Table of Contents 4.8. Binary files ..................................................... 780 5. DAT v2.0 Format Specifications ..................................... 787 5.1. General file specs, index and checksums .......................... 790 -5.2. The master index ................................................. 817 -5.3. The slave indexes ................................................ 855 +5.1.1. The master index ............................................... 817 +5.1.2. The slave indexes .............................................. 855 6. PLV v1.0 Format Specifications ..................................... 875 6.1. User data ........................................................ 901 6.2. Allowed Date format .............................................. 931 @@ -381,13 +381,13 @@ Table of Contents This table has a summary of the blocks to be used in this section, you can referr it from the text below. - Table 4.1: Level blocks - ~~~~~~~~~~~~~~~~~~~~~~~ + Table 4.1: DAT 1.0 Level blocks + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Length Offset Block Name ~~~~~~ ~~~~~~ ~~~~~~~~~~ 720 0 wall - 720 720 background + 720 720 pop1_background 256 1440 door I 256 1696 door II 96 1952 links @@ -405,7 +405,7 @@ Table of Contents 16 2287 unknown VI (d) 2 2303 0F 09 (2319) - All levels has a size of 2305, except in the original game, that the + All levels have a size of 2305, except in the original game, that the potion level has a size of 2304 (may be it was wrong trimmed). 4.4.1 Unknown blocks @@ -428,26 +428,25 @@ Table of Contents 4.4.2 Room mapping This section explains how the main walls and objects are stored. The - blocks involved here are "wall" and "background" + blocks involved here are "wall" and "pop1_background" - In a level you can store a maximum of 24 screens (also called rooms) of 30 + In a level you can store a maximum of 24 rooms (also called screens) of 30 tiles each, having three stages of 10 tiles each. Screens are numbered - from 1 to 24 (not 0 to 23) because the 0 was reserved special cases. + from 1 to 24 (not 0 to 23) because the 0 was reserved for special cases. - The wall and background blocks have 24 sub-blocks inside. Those sub-blocks - has a size of 30 bytes each and has a screen associated. So, for example, - the sub-block staring in 0 corresponds to the screen 1 and the sub-block - starting in 690 corresponds to the screen 24. - It is reserved 1 byte from the wall block and one from the background + The wall and pop1_background blocks have 24 sub-blocks inside. Those + sub-blocks have a size of 30 bytes each and has a room associated. So, for + example, the sub-block staring in 0 corresponds to the room 1 and the + sub-block starting in 690 corresponds to the room 24. + It is reserved 1 byte from the wall block and one from the pop1_background block for each tile. To locate the appropriate tile you have to do the - following calculation: tile=(screen-1)*30+tileOffset where tileOffset is a - number - from 0 to 29 that means a tile from 0 to 9 if in the upper stage, from + following calculation: tile=(room-1)*30+tileOffset where tileOffset is a + number from 0 to 29 that means a tile from 0 to 9 if in the upper stage, from 10 to 19 if in the middle stage and 20 to 29 if in the bottom stage. We define this as the location format and will be used also in the start position. Allways looking from the left to the right. - So there is a wall and background byte for each tile in the level and this + So there is a wall and pop1_background byte for each tile in the level and this is stored this way. The wall part of the tile stores the main tile form according to the table @@ -500,7 +499,7 @@ Table of Contents 0x1E 11110 none Torch with Debris 0x1F 11111 none Null - The background part of the tile stores a modifier or attribute of the + The pop1_background part of the tile stores a modifier or attribute of the wall part of the tile. This works independently of the modifier bit in the code. The tile modifier depends on the group the tile belongs which are wall, chomp, event, ttop, potion, tapp, gate, spike and free. @@ -565,8 +564,8 @@ Table of Contents 4.4.2.1 Wall drawing algorithm This section doesn't have a direct relation with the format because it - describes how the walls must be drawn on the screen. However, as this - information should be usefull to recreate a cloned screen read from the + describes how the walls must be drawn on the room. However, as this + information should be usefull to recreate a cloned room read from the format we decided to include this section to the document. Wall drawing depends on what is in the right panel. If the right panel @@ -580,13 +579,13 @@ Table of Contents those 53 panels. This array has indexes from 1 to 53 included. To calculate what value take from the array this calculation must be - performed: panelInfo=seedArray[screenNumber+wallPosition] + performed: panelInfo=seedArray[roomNumber+wallPosition] where panelInfo is the result modifier information that will be applied to the base image; seedArray is this array that will be described above as a - table; screenNumber is the number of the screen the wall is (from 1 to 24) + table; roomNumber is the number of the room the wall is (from 1 to 24) and wallPosition is the position the wall is (from 0 to 29), using the location format specified in section 4.4.2. This means the first value is - 1 (screenNumber=1 and wallPosition=0) and the last is 53 (screenNumber=24 + 1 (roomNumber=1 and wallPosition=0) and the last is 53 (roomNumber=24 and wallPosition=29). Modifiers affects the corners of a stone. There are three stone rows per @@ -634,31 +633,31 @@ Table of Contents 4.4.3 Room linking This section describes the links block. - Each screen is linked to another by each of the four sides. Each link - is stored. There is no screen mapping, just screen linking. + Each room is linked to another by each of the four sides. Each link + is stored. There is no room mapping, just room linking. The links block has 24 sub-blocks of 4 bytes each. All those sub-blocks - has its own correspondence with a screen (the block starting at 0 is - related to the screen 1 and the block starting at with 92 is related to - screen 24). - Each block of 4 bytes stores the links this screen links to reserving one + has its own correspondence with a room (the block starting at 0 is + related to the room 1 and the block starting at with 92 is related to + room 24). + Each block of 4 bytes stores the links this room links to reserving one byte per each side in the order left (0), right (1), up (2), down (3). - The number 0 is used when there is no screen there. - Cross links should be made to allow the kid passing from a screen to - another and then coming back to the same screen but it's not a must. + The number 0 is used when there is no room there. + Cross links should be made to allow the kid passing from a room to + another and then coming back to the same room but it's not a must. 4.4.4 Guard handling This section specifies the blocks: guard_location, guard_direction, guard_skill and guard_colour. - Each guard section has 24 bytes, each byte of them corresponds to a screen - so byte 0 is related to screen 1 and byte 13 is related to screen 24. - This screen is where the guard is located. The format only allows one - guard per screen. Each block describes a part of the guard. + Each guard section has 24 bytes, each byte of them corresponds to a room + so byte 0 is related to room 1 and byte 13 is related to room 24. + This room is where the guard is located. The format only allows one + guard per room. Each block describes a part of the guard. - The guard_location part of a guard describes where in the screen the guard - is located, this is a number from 0 to 29 if the guard is in the screen or - 30 if there is no guard in this screen. Other values are allowed but are + The guard_location part of a guard describes where in the room the guard + is located, this is a number from 0 to 29 if the guard is in the room or + 30 if there is no guard in this room. Other values are allowed but are equivalent to 30. The number from 0 to 29 is in the location format specified in section 4.4.2 @@ -698,11 +697,11 @@ Table of Contents This section describes the start_position block. This block stores where and how the kid starts in the level. Note that all - level doors that are on the starting screen will be closed in the moment + level doors that are on the starting room will be closed in the moment the level starts. This block has 3 bytes. - The first byte is the screen, allowed values are from 1 to 24. + The first byte is the room, allowed values are from 1 to 24. The second byte is the location, see the section 4.4.2 for the location format specifications. The third byte is the direction, see 4.4.4 for the direction format @@ -735,7 +734,7 @@ Table of Contents located in the byte 30 of each block. There is a door I part of an event line and a door II part of it. We'll define them as byte I and byte II. - You can find there: the door screen, the door location, and the + You can find there: the door room, the door location, and the trigger-next flag. The format is the following: Let's define: @@ -788,7 +787,7 @@ Table of Contents ~~~ ~~~~ ~~~~~~ ~~~~~~~~~~~~~~ 5.1. General file specs, index and checksums - POP2 DAT files aren't much different from their predecessors from POP1. + POP2 DAT files aren't much different from their POP1 predecessors. The format is similar in almost each way. The main difference is in the index. As DAT v1.0 used an index in the high data, the DAT v2.0 indexes are two level encapsulated inside a high data. So there is an index of @@ -814,7 +813,7 @@ Table of Contents call this index the \xabmaster index\xbb and the sub index the \xabslave indexes\xbb. Slave indexes are the real file contents index. -5.2. The master index +5.1.1. The master index The master index is made with: - Offset HighDataOffset, size 2, type US: NumberOfSlaveIndexes (the number of the high data sections) @@ -841,25 +840,26 @@ Table of Contents Table 5.1: Section ID strings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - ID Size in records - ~~ ~~~~~~~~~~~~~~~ - cust custom - font fonts - fram frames - palc CGA Palette - pals SVGA Palette - palt TGA Palette - piec Pieces - psl ? - scr Screens (images that have the full screen) - shap Shapes (normal graphics) - shpl Shape palettes - strl Str - snd Sound - seqs Midi sequences - txt4 Text - -5.3. The slave indexes + ID Stored Size in records + ~~ ~~~~~~ ~~~~~~~~~~~~~~~ + cust TSUC Custom + font TNOF Fonts + fram MARF Frames + palc CLAP CGA Palette + pals SLAP SVGA Palette + palt TLAP TGA Palette + piec CEIP Pieces + psl LSP# ? + scr RCS# Screens (images that have the full room) + shap PAHS Shapes (normal graphics) + shpl LPHS Shape palettes + strl LRTS Text + snd DNS# Sound + seqs SQES Midi sequences + txt4 4TXT Text + #### Levels + +5.1.2. The slave indexes All encapsulated sections are indexes. The slave index is made with: - Offset SlaveIndexOffset, size 2, type US: NumberOfItems @@ -875,10 +875,93 @@ Table of Contents - Relative offset 6, size 2, type US: Size of the item (not including the checksum byte) - Relative offset 8, size 3, type binary: A flags mask - (in PAHS indexes it's allways 0x40 0x00 0x00; + (in SHAP indexes it's allways 0x40 0x00 0x00; in others 0x00 0x00 0x00) +5.2. Levels + + This table has a summary of the blocks to be used in this section, + you can refer it from the text below. + + Table 5.2: DAT 2.0 Level blocks + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Length Offset Block Name + ~~~~~~ ~~~~~~ ~~~~~~~~~~ + 960 0 wall + 3840 960 pop2_background + 1280 4800 unknown I (doors) + 128 6080 links (as explained in section 4.4.3 but having 32 rooms) + 32 6208 unknown II + 3 6240 start_position (as explained in section 4.4.5) + 5782 6243 unknown III + + All levels have a size of 12025. + +5.2.1 Room mapping + You should read section 4.4.2 before reading this one. + A POP2 level can store a maximum of 32 rooms of 30 tiles each, having + three stages of 10 tiles each. Rooms are numbered from 1 to 32 (not 0 to + 31) because the 0 is be reserved to the null-room. + + The wall block has 32 sub-blocks inside. Each sub-block has a size of 30 + bytes and has a room associated. For each byte in this room there is a tile + in the game. Each byte has a code to represent a tile. There are additional + attributes to this tile also. + + To locate the 7th tile in the bottom floor of the room 27 you have to do the + same calculation as in 4.4.2: + tile=(room-1)*30+tileOffset=(27-1)*30+2*10+7=807 + + + Table 5.3: Foreground Walls + ~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Hex Binary Group Description + ~~~~ ~~~~~~ ~~~~~ ~~~~~~~~~~~ + 0x00 000000 (?) Empty + 0x01 000001 (?) Floor + 0x02 000010 (?) Wall with spikes + 0x03 000011 (?) One floor pillar + 0x04 000100 (?) Door + 0x06 000110 (?) Loose I + 0x07 000111 (?) Linked loose + 0x08 001000 (?) Big pillar base + 0x09 001001 (?) Big pillar top + 0x0A 001010 (?) Potion + 0x0B 001011 (?) Loose II + 0x0E 001110 (?) Debris + 0x10 010000 (?) Exit door left + 0x11 010001 (?) Exit door right + 0x12 010010 (?) Magic tappet (?) + 0x13 010011 (?) Torch + 0x14 010100 (?) Wall + 0x17 010111 (?) Lava (left) + 0x18 011000 (?) Lava (right) + 0x1B 011011 (?) Special activator (?) + 0x21 100001 (?) Stalactites I + 0x22 100010 (?) Activator (floor shooter or door) + 0x23 100011 (?) Stalactites II + 0x24 100100 (?) Floor shooter + + The pop2_background is an expansion if the pop1_background and it is sized + 4 times bigger. For each tile there are 4 additional bytes in the + pop2_background block to specify further actions or attributes. + This block is sized 4 bytes/tile * 10 tiles/floor * 3 floors/room * 32 rooms + that is 3840 bytes. + We call background mask to each block of 4 bytes associated to a tile. To + locate a background mask you have to do the following operation: + 960+(room-1)*30*4+tileOffset*4 + Background masks are stored consecutively each after another until the 960 + tiles are specified. + + The second byte in a background mask is the attribute byte. For example 0x18 + modifies the tile 0x01 and adds two small stalactites. + + We believe the doors uses the 3rd or 4th byte. + + 6. PLV v1.0 Format Specifications ~~~ ~~~~ ~~~~~~ ~~~~~~~~~~~~~~ diff --git a/FP/doc/FormatSpecifications.tex b/FP/doc/FormatSpecifications.tex index 50baa24..9e5c253 100644 --- a/FP/doc/FormatSpecifications.tex +++ b/FP/doc/FormatSpecifications.tex @@ -33,8 +33,8 @@ Table of Contents 4.8. Binary files ..................................................... 780 5. DAT v2.0 Format Specifications ..................................... 787 5.1. General file specs, index and checksums .......................... 790 -5.2. The master index ................................................. 817 -5.3. The slave indexes ................................................ 855 +5.1.1. The master index ............................................... 817 +5.1.2. The slave indexes .............................................. 855 6. PLV v1.0 Format Specifications ..................................... 875 6.1. User data ........................................................ 901 6.2. Allowed Date format .............................................. 931 @@ -381,13 +381,13 @@ Table of Contents This table has a summary of the blocks to be used in this section, you can referr it from the text below. - Table 4.1: Level blocks - ~~~~~~~~~~~~~~~~~~~~~~~ + Table 4.1: DAT 1.0 Level blocks + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Length Offset Block Name ~~~~~~ ~~~~~~ ~~~~~~~~~~ 720 0 wall - 720 720 background + 720 720 pop1_background 256 1440 door I 256 1696 door II 96 1952 links @@ -405,7 +405,7 @@ Table of Contents 16 2287 unknown VI (d) 2 2303 0F 09 (2319) - All levels has a size of 2305, except in the original game, that the + All levels have a size of 2305, except in the original game, that the potion level has a size of 2304 (may be it was wrong trimmed). 4.4.1 Unknown blocks @@ -428,26 +428,25 @@ Table of Contents 4.4.2 Room mapping This section explains how the main walls and objects are stored. The - blocks involved here are "wall" and "background" + blocks involved here are "wall" and "pop1_background" - In a level you can store a maximum of 24 screens (also called rooms) of 30 + In a level you can store a maximum of 24 rooms (also called screens) of 30 tiles each, having three stages of 10 tiles each. Screens are numbered - from 1 to 24 (not 0 to 23) because the 0 was reserved special cases. + from 1 to 24 (not 0 to 23) because the 0 was reserved for special cases. - The wall and background blocks have 24 sub-blocks inside. Those sub-blocks - has a size of 30 bytes each and has a screen associated. So, for example, - the sub-block staring in 0 corresponds to the screen 1 and the sub-block - starting in 690 corresponds to the screen 24. - It is reserved 1 byte from the wall block and one from the background + The wall and pop1_background blocks have 24 sub-blocks inside. Those + sub-blocks have a size of 30 bytes each and has a room associated. So, for + example, the sub-block staring in 0 corresponds to the room 1 and the + sub-block starting in 690 corresponds to the room 24. + It is reserved 1 byte from the wall block and one from the pop1_background block for each tile. To locate the appropriate tile you have to do the - following calculation: tile=(screen-1)*30+tileOffset where tileOffset is a - number - from 0 to 29 that means a tile from 0 to 9 if in the upper stage, from + following calculation: tile=(room-1)*30+tileOffset where tileOffset is a + number from 0 to 29 that means a tile from 0 to 9 if in the upper stage, from 10 to 19 if in the middle stage and 20 to 29 if in the bottom stage. We define this as the location format and will be used also in the start position. Allways looking from the left to the right. - So there is a wall and background byte for each tile in the level and this + So there is a wall and pop1_background byte for each tile in the level and this is stored this way. The wall part of the tile stores the main tile form according to the table @@ -500,7 +499,7 @@ Table of Contents 0x1E 11110 none Torch with Debris 0x1F 11111 none Null - The background part of the tile stores a modifier or attribute of the + The pop1_background part of the tile stores a modifier or attribute of the wall part of the tile. This works independently of the modifier bit in the code. The tile modifier depends on the group the tile belongs which are wall, chomp, event, ttop, potion, tapp, gate, spike and free. @@ -565,8 +564,8 @@ Table of Contents 4.4.2.1 Wall drawing algorithm This section doesn't have a direct relation with the format because it - describes how the walls must be drawn on the screen. However, as this - information should be usefull to recreate a cloned screen read from the + describes how the walls must be drawn on the room. However, as this + information should be usefull to recreate a cloned room read from the format we decided to include this section to the document. Wall drawing depends on what is in the right panel. If the right panel @@ -580,13 +579,13 @@ Table of Contents those 53 panels. This array has indexes from 1 to 53 included. To calculate what value take from the array this calculation must be - performed: panelInfo=seedArray[screenNumber+wallPosition] + performed: panelInfo=seedArray[roomNumber+wallPosition] where panelInfo is the result modifier information that will be applied to the base image; seedArray is this array that will be described above as a - table; screenNumber is the number of the screen the wall is (from 1 to 24) + table; roomNumber is the number of the room the wall is (from 1 to 24) and wallPosition is the position the wall is (from 0 to 29), using the location format specified in section 4.4.2. This means the first value is - 1 (screenNumber=1 and wallPosition=0) and the last is 53 (screenNumber=24 + 1 (roomNumber=1 and wallPosition=0) and the last is 53 (roomNumber=24 and wallPosition=29). Modifiers affects the corners of a stone. There are three stone rows per @@ -634,31 +633,31 @@ Table of Contents 4.4.3 Room linking This section describes the links block. - Each screen is linked to another by each of the four sides. Each link - is stored. There is no screen mapping, just screen linking. + Each room is linked to another by each of the four sides. Each link + is stored. There is no room mapping, just room linking. The links block has 24 sub-blocks of 4 bytes each. All those sub-blocks - has its own correspondence with a screen (the block starting at 0 is - related to the screen 1 and the block starting at with 92 is related to - screen 24). - Each block of 4 bytes stores the links this screen links to reserving one + has its own correspondence with a room (the block starting at 0 is + related to the room 1 and the block starting at with 92 is related to + room 24). + Each block of 4 bytes stores the links this room links to reserving one byte per each side in the order left (0), right (1), up (2), down (3). - The number 0 is used when there is no screen there. - Cross links should be made to allow the kid passing from a screen to - another and then coming back to the same screen but it's not a must. + The number 0 is used when there is no room there. + Cross links should be made to allow the kid passing from a room to + another and then coming back to the same room but it's not a must. 4.4.4 Guard handling This section specifies the blocks: guard_location, guard_direction, guard_skill and guard_colour. - Each guard section has 24 bytes, each byte of them corresponds to a screen - so byte 0 is related to screen 1 and byte 13 is related to screen 24. - This screen is where the guard is located. The format only allows one - guard per screen. Each block describes a part of the guard. + Each guard section has 24 bytes, each byte of them corresponds to a room + so byte 0 is related to room 1 and byte 13 is related to room 24. + This room is where the guard is located. The format only allows one + guard per room. Each block describes a part of the guard. - The guard_location part of a guard describes where in the screen the guard - is located, this is a number from 0 to 29 if the guard is in the screen or - 30 if there is no guard in this screen. Other values are allowed but are + The guard_location part of a guard describes where in the room the guard + is located, this is a number from 0 to 29 if the guard is in the room or + 30 if there is no guard in this room. Other values are allowed but are equivalent to 30. The number from 0 to 29 is in the location format specified in section 4.4.2 @@ -698,11 +697,11 @@ Table of Contents This section describes the start_position block. This block stores where and how the kid starts in the level. Note that all - level doors that are on the starting screen will be closed in the moment + level doors that are on the starting room will be closed in the moment the level starts. This block has 3 bytes. - The first byte is the screen, allowed values are from 1 to 24. + The first byte is the room, allowed values are from 1 to 24. The second byte is the location, see the section 4.4.2 for the location format specifications. The third byte is the direction, see 4.4.4 for the direction format @@ -735,7 +734,7 @@ Table of Contents located in the byte 30 of each block. There is a door I part of an event line and a door II part of it. We'll define them as byte I and byte II. - You can find there: the door screen, the door location, and the + You can find there: the door room, the door location, and the trigger-next flag. The format is the following: Let's define: @@ -788,7 +787,7 @@ Table of Contents ~~~ ~~~~ ~~~~~~ ~~~~~~~~~~~~~~ 5.1. General file specs, index and checksums - POP2 DAT files aren't much different from their predecessors from POP1. + POP2 DAT files aren't much different from their POP1 predecessors. The format is similar in almost each way. The main difference is in the index. As DAT v1.0 used an index in the high data, the DAT v2.0 indexes are two level encapsulated inside a high data. So there is an index of @@ -814,7 +813,7 @@ Table of Contents call this index the \xabmaster index\xbb and the sub index the \xabslave indexes\xbb. Slave indexes are the real file contents index. -5.2. The master index +5.1.1. The master index The master index is made with: - Offset HighDataOffset, size 2, type US: NumberOfSlaveIndexes (the number of the high data sections) @@ -841,25 +840,26 @@ Table of Contents Table 5.1: Section ID strings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - ID Size in records - ~~ ~~~~~~~~~~~~~~~ - cust custom - font fonts - fram frames - palc CGA Palette - pals SVGA Palette - palt TGA Palette - piec Pieces - psl ? - scr Screens (images that have the full screen) - shap Shapes (normal graphics) - shpl Shape palettes - strl Str - snd Sound - seqs Midi sequences - txt4 Text - -5.3. The slave indexes + ID Stored Size in records + ~~ ~~~~~~ ~~~~~~~~~~~~~~~ + cust TSUC Custom + font TNOF Fonts + fram MARF Frames + palc CLAP CGA Palette + pals SLAP SVGA Palette + palt TLAP TGA Palette + piec CEIP Pieces + psl LSP# ? + scr RCS# Screens (images that have the full room) + shap PAHS Shapes (normal graphics) + shpl LPHS Shape palettes + strl LRTS Text + snd DNS# Sound + seqs SQES Midi sequences + txt4 4TXT Text + #### Levels + +5.1.2. The slave indexes All encapsulated sections are indexes. The slave index is made with: - Offset SlaveIndexOffset, size 2, type US: NumberOfItems @@ -875,10 +875,93 @@ Table of Contents - Relative offset 6, size 2, type US: Size of the item (not including the checksum byte) - Relative offset 8, size 3, type binary: A flags mask - (in PAHS indexes it's allways 0x40 0x00 0x00; + (in SHAP indexes it's allways 0x40 0x00 0x00; in others 0x00 0x00 0x00) +5.2. Levels + + This table has a summary of the blocks to be used in this section, + you can refer it from the text below. + + Table 5.2: DAT 2.0 Level blocks + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Length Offset Block Name + ~~~~~~ ~~~~~~ ~~~~~~~~~~ + 960 0 wall + 3840 960 pop2_background + 1280 4800 unknown I (doors) + 128 6080 links (as explained in section 4.4.3 but having 32 rooms) + 32 6208 unknown II + 3 6240 start_position (as explained in section 4.4.5) + 5782 6243 unknown III + + All levels have a size of 12025. + +5.2.1 Room mapping + You should read section 4.4.2 before reading this one. + A POP2 level can store a maximum of 32 rooms of 30 tiles each, having + three stages of 10 tiles each. Rooms are numbered from 1 to 32 (not 0 to + 31) because the 0 is be reserved to the null-room. + + The wall block has 32 sub-blocks inside. Each sub-block has a size of 30 + bytes and has a room associated. For each byte in this room there is a tile + in the game. Each byte has a code to represent a tile. There are additional + attributes to this tile also. + + To locate the 7th tile in the bottom floor of the room 27 you have to do the + same calculation as in 4.4.2: + tile=(room-1)*30+tileOffset=(27-1)*30+2*10+7=807 + + + Table 5.3: Foreground Walls + ~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Hex Binary Group Description + ~~~~ ~~~~~~ ~~~~~ ~~~~~~~~~~~ + 0x00 000000 (?) Empty + 0x01 000001 (?) Floor + 0x02 000010 (?) Wall with spikes + 0x03 000011 (?) One floor pillar + 0x04 000100 (?) Door + 0x06 000110 (?) Loose I + 0x07 000111 (?) Linked loose + 0x08 001000 (?) Big pillar base + 0x09 001001 (?) Big pillar top + 0x0A 001010 (?) Potion + 0x0B 001011 (?) Loose II + 0x0E 001110 (?) Debris + 0x10 010000 (?) Exit door left + 0x11 010001 (?) Exit door right + 0x12 010010 (?) Magic tappet (?) + 0x13 010011 (?) Torch + 0x14 010100 (?) Wall + 0x17 010111 (?) Lava (left) + 0x18 011000 (?) Lava (right) + 0x1B 011011 (?) Special activator (?) + 0x21 100001 (?) Stalactites I + 0x22 100010 (?) Activator (floor shooter or door) + 0x23 100011 (?) Stalactites II + 0x24 100100 (?) Floor shooter + + The pop2_background is an expansion if the pop1_background and it is sized + 4 times bigger. For each tile there are 4 additional bytes in the + pop2_background block to specify further actions or attributes. + This block is sized 4 bytes/tile * 10 tiles/floor * 3 floors/room * 32 rooms + that is 3840 bytes. + We call background mask to each block of 4 bytes associated to a tile. To + locate a background mask you have to do the following operation: + 960+(room-1)*30*4+tileOffset*4 + Background masks are stored consecutively each after another until the 960 + tiles are specified. + + The second byte in a background mask is the attribute byte. For example 0x18 + modifies the tile 0x01 and adds two small stalactites. + + We believe the doors uses the 3rd or 4th byte. + + 6. PLV v1.0 Format Specifications ~~~ ~~~~ ~~~~~~ ~~~~~~~~~~~~~~