Crash Bandicoot Hacking Wiki - User contributions [en]

List of game discs

2019-10-27T16:10:47Z

Chekwob: /* Prerelease discs */ Added redlinks for the 4 known leaked builds

== Release discs ==

=== Crash 1 ===
{|class="wikitable"
! Disc ID
! Region
|-
| [[SCUS-94900]]
| NTSC-U/C
|-
| [[SCES-00344]]
| PAL
|-
| [[SCPS-10031]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91057.

=== Crash 2 ===
{|class="wikitable"
! Disc ID
! Region
|-
| [[SCUS-94154]]
| NTSC-U/C
|-
| [[SCES-00967]]
| PAL
|-
| [[SCPS-10047]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91092.

=== Crash 3 ===
{|class="wikitable"
! Disc ID
! Region
|-
| [[SCUS-94244]]
| NTSC-U/C
|-
| [[SCES-01420]]
| PAL
|-
| [[SCPS-10073]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91164 and SCPS-91318.

== Prerelease discs ==

=== Crash 1 ===
* [[Crash 1 Proto APR08]] aka "Prototype"
* [[Crash 1 Proto MAY11]] aka "E3 Demo"

=== Crash 2 ===
* [[Crash 2 Proto AUG08]]

=== Crash 3 ===
* [[Crash 3 Proto AUG15]]

== Demo discs ==

{|class="wikitable"
! Disc ID
! Region
! Name
|-
| [[PBPX-95007]]
| PAL
| Demo One EUROPE
|-
| [[PBPX-95008]]
| PAL
| Demo One EUROPE
|-
| [[SCED-00273]]
| PAL
| Autumn/Christmas Releases
|-
| [[SCED-00364]]
| PAL
| Crash Bandicoot / Supersonic Racers / Die Hard Trilogy / Broken Sword / F1
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00457]]
| PAL
| Demo One german
|-
| [[SCED-00678]]
| PAL
| Euro Demo 13 GER
|-
| [[SCED-00777]]
| PAL
| Euro Demo 14 FRE
|-
| [[SCED-00823]]
| PAL
| Euro Demo 27
|-
| [[SCED-00936]]
| PAL
| Registered User Demo 02
|-
| [[SCED-00938]]
| PAL
| Essential Playstation IV
|-
| [[SCED-00986]]
| PAL
| Winter Releases - '97 demo 01
|-
| [[SCED-01049]]
| PAL
| Playstation Sampler / Nightmare Creatures / Kurushi / Rapid Racer / ...
|-
| [[SCED-01118]]
| PAL
| Euro Demo 25 fra
|-
| [[SCED-01120]]
| PAL
| Euro Demo 27 fra
|-
| [[SCED-01127]]
| PAL
| Euro Demo 10/98 ger
|-
| [[SCED-01128]]
| PAL
| Euro Demo 11/98 ger
|-
| [[SCED-01129]]
| PAL
| Euro Demo 12/98 ger
|-
| [[SCED-01139]]
| PAL
| Essential Playstation VIII
|-
| [[SCED-01141]]
| PAL
| Essential Playstation X
|-
| [[SCED-01148]]
| PAL
| Euro Demo 38
|-
| [[SCED-01150]]
| PAL
| Euro Demo 40
|-
| [[SCED-01229]]
| PAL
| PlayStation Kids
|-
| [[SCED-01230]]
| PAL
| Registered Users Demo 03
|-
| [[SCED-01385]]
| PAL
| Registered Users Demo
|-
| [[SCED-01441]]
| PAL
| Winter Releases '98
|-
| [[SCED-01570]]
| PAL
| Australian Summer Special
|-
| [[SCED-01636]]
| PAL
| Registered Users Demo
|-
| [[SCED-01713]]
| PAL
| M-6 PlayStation Demo fre
|-
| [[SCED-01739]]
| PAL
| Katalog Spezial Demo ger
|-
| [[SCED-01828]]
| PAL
| Euro Demo 54
|-
| [[SCED-01837]]
| PAL
| Euro Demo 06/99 GER
|-
| [[SCED-01860]]
| PAL
| Euro Demo 40 FRA
|-
| [[SCED-01861]]
| PAL
| Euro Demo 41 FRA
|-
| [[SCED-01988]]
| PAL
| Registered Users Demo 06
|-
| [[SCED-02122]]
| PAL
| OPSM Platinum Special Demo (All)
|-
| [[SCED-02327]]
| PAL
| The Best Games Ever
|-
| [[SCED-02570]]
| PAL
| M6 PlayStation - Best Of Kids Demo
|-
| [[SCED-02655]]
| PAL
| Euro Demo (France) 51
|-
| [[SCED-02851]]
| PAL
| OPSM Best Ever Ever Games Demo
|-
| [[SCED-03103]]
| PAL
| PlayStation Speziale Italia
|-
| [[SCED-03452]]
| PAL
| Euro Demo 75
|-
| [[SCED-03454]]
| PAL
| OPSM Demo 77
|-
| [[SCED-03472]]
| PAL
| Euro Demo Germany 09/01 Deutsch
|-
| [[SCED-03473]]
| PAL
| Euro Demo Germany 10/01 Deutsch
|-
| [[SCED-03790]]
| PAL
| Official PlayStation Magazine 87 EUR
|-
| [[SCED-03791]]
| PAL
| Official PlayStation Magazine 88 EUR
|-
| [[SCED-03905]]
| PAL
| Euro Demo (Germany) 03/04-2003
|-
| [[SCED-04076]]
| PAL
| Euro Demo (Future) 97
|-
| [[SCED-04077]]
| PAL
| Euro Demo (Future) 98
|-
| [[SLED-01633]]
| PAL
| PlayStation Zone CD Vol. 1
|-
| [[SLED-01724]]
| PAL
| PlayStation Zone CD Vol. 2
|-
| [[SLED-01773]]
| PAL
| PlayStation Zone CD Vol. 3
|-
| [[SLED-01783]]
| PAL
| PlayStation Zone CD Vol. 4
|-
| [[SLED-01898]]
| PAL
| PlayStation Zone CD Vol. 5
|-
| [[SLED-02042]]
| PAL
| PlayStation Zone CD Vol. 7
|-
| [[SLED-02078]]
| PAL
| PlayStation Zone CD Vol. 8
|-
| [[SLED-02139]]
| PAL
| PlayStation Zone CD Vol. 9
|}

Level ID

2019-05-19T14:16:52Z

Chekwob: Fixed up level names and made them into wiki links

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.

== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| ''(none)''
|-
| <code>01</code>
| <code>1</code>
| ''(none)''
|-
| <code>02</code>
| <code>2</code>
| ''(none)''
|-
| <code>03</code>
| <code>3</code>
| [[Cortex Power]]
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| [[Generator Room]]
|-
| <code>06</code>
| <code>6</code>
| [[Heavy Machinery]]
|-
| <code>07</code>
| <code>7</code>
| [[Toxic Waste]]
|-
| <code>08</code>
| <code>8</code>
| [[Pinstripe|Pinstripe (Boss 4)]]
|-
| <code>09</code>
| <code>9</code>
| [[N. Sanity Beach]]
|-
| <code>0A</code>
| <code>a</code>
| [[Papu Papu|Papu Papu (Boss 1)]]
|-
| <code>0B</code>
| <code>b</code>
| ''(none)''
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| ''(none)''
|-
| <code>0E</code>
| <code>e</code>
| [[Boulders]]
|-
| <code>0F</code>
| <code>f</code>
| [[Upstream]]
|-
| <code>10</code>
| <code>g</code>
| ''(none)''
|-
| <code>11</code>
| <code>h</code>
| [[Hog Wild]]
|-
| <code>12</code>
| <code>i</code>
| [[The Great Gate]]
|-
| <code>13</code>
| <code>j</code>
| [[Boulder Dash]]
|-
| <code>14</code>
| <code>k</code>
| [[Road to Nowhere]]
|-
| <code>15</code>
| <code>l</code>
| [[Rolling Stones]]
|-
| <code>16</code>
| <code>m</code>
| [[The High Road]]
|-
| <code>17</code>
| <code>n</code>
| [[Ripper Roo (C1)|Ripper Roo (Boss 2)]]
|-
| <code>18</code>
| <code>o</code>
| [[Up The Creek]]
|-
| <code>19</code>
| <code>p</code>
| [[Map (C1)|Map, Main Menu, Title Sequence]]
|-
| <code>1A</code>
| <code>q</code>
| [[Native Fortress]]
|-
| <code>1B</code>
| <code>r</code>
| [[Nitrus Brio|Nitrus Brio (Boss 5)]]
|-
| <code>1C</code>
| <code>s</code>
| [[Temple Ruins]]
|-
| <code>1D</code>
| <code>t</code>
| [[Jaws of Darkness]]
|-
| <code>1E</code>
| <code>u</code>
| [[Whole Hog]]
|-
| <code>1F</code>
| <code>v</code>
| [[Dr. Neo Cortex (C1)|Dr. Neo Cortex (Boss 6)]]
|-
| <code>20</code>
| <code>w</code>
| [[The Lost City]]
|-
| <code>21</code>
| <code>x</code>
| [[Koala Kong|Koala Kong (Boss 3)]]
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' [[Stormy Ascent]]
|-
| <code>23</code>
| <code>z</code>
| [[Sunset Vista]]
|-
| <code>24</code>
| <code>A</code>
| [[Bonus Round (C1)|Bonus Round]] (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| [[Bonus Round (C1)|Bonus Round]] (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| [[Bonus Round (C1)|Bonus Round]] '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| ''(none)''
|-
| <code>28</code>
| <code>E</code>
| [[Lights Out]]
|-
| <code>29</code>
| <code>F</code>
| [[The Lab]]
|-
| <code>2A</code>
| <code>G</code>
| [[Fumbling in the Dark]]
|-
| <code>2B</code>
| <code>H</code>
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| [[The Great Hall]]
|-
| <code>2D</code>
| <code>J</code>
| [[Level Completion Screen]]
|-
| <code>2E</code>
| <code>K</code>
| [[Slippery Climb]]
|-
| <code>2F</code>
| <code>L</code>
| ''(none)''
|-
| <code>30</code>
| <code>M</code>
| ''(none)''
|-
| <code>31</code>
| <code>N</code>
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| [[Bonus Round (C1)|Bonus Round]] (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| [[Bonus Round (C1)|Bonus Round]] (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| [[Castle Machinery]]
|-
| <code>38</code>
| <code>U</code>
| [[Intro (C1)|Intro]]
|-
| <code>39</code>
| <code>V</code>
| [[Ending (C1)|Ending]]
|-
| <code>3A</code>
| <code>W</code>
| ''(none)''
|-
| <code>3B</code>
| <code>X</code>
| ''(none)''
|-
| <code>3C</code>
| <code>Y</code>
| ''(none)''
|-
| <code>3D</code>
| <code>Z</code>
| ''(none)''
|-
| <code>3E</code>
| <code>_</code>
| ''(none)''
|-
| <code>3F</code>
| <code>!</code>
| ''(none)''
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| [[Test Area]]
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| [[Cavern Level]]
|-
| <code>0B</code>
| <code>b</code>
| [[Cliff Level]]
|-
| <code>0D</code>
| <code>d</code>
| [[Waterfall Level]]
|-
| <code>10</code>
| <code>g</code>
| [[2D Donkey Kong]]
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).

Each ID for a level is also used for that level's crystal and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level ID which does not have a box gem. These extra gem associations are listed below.
{| class="wikitable"
!Hex
!#
!Level name
! Associated gem
|-
| <code>01</code>
| <code>1</code>
| ''(none)''
| Second gem for [[Hang Eight]]
|-
| <code>02</code>
| <code>2</code>
| [[Warp Room (C2)|Warp Room]] (en/ja)
| Second gem for [[Air Crash]]
|-
| <code>03</code>
| <code>3</code>
| [[Tiny Tiger (C2)|Tiny Tiger (Boss 3)]]
| Second gem for [[Sewer or Later]]
|-
| <code>04</code>
| <code>4</code>
| ''(none)''
| Second gem for [[Road to Ruin]]
|-
| <code>05</code>
| <code>5</code>
| ''(none)''
| Second gem for [[Piston It Away]]
|-
| <code>06</code>
| <code>6</code>
| [[Ripper Roo (C2)|Ripper Roo (Boss 1)]]
| Second gem for [[Night Fight]]
|-
| <code>07</code>
| <code>7</code>
| [[Dr. Neo Cortex (C2)|Dr. Neo Cortex (Boss 5)]]
| Second gem for [[Spaced Out]]
|-
| <code>08</code>
| <code>8</code>
| [[Komodo Bros.|Komodo Bros. (Boss 2)]]
| Second gem for [[Diggin' It]]
|-
| <code>09</code>
| <code>9</code>
| [[N. Gin (C2)|N. Gin (Boss 4)]]
| Second gem for [[Cold Hard Crash]]
|-
| <code>0A</code>
| <code>a</code>
| [[Sewer or Later]]
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| (none); Test jungle level (jungle1)
| ''(none)''
|-
| <code>0C</code>
| <code>c</code>
| [[Night Fight]]
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
| [[Hangin' Out]]
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
| [[Snow Go]]
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
| [[Ruination]]
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
| [[Piston it Away]]
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
| [[Snow Biz]]
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
| [[Rock It]]
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
| [[Cold Hard Crash]]
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| ''(none)''
| ''(none)''
|-
| <code>15</code>
| <code>l</code>
| [[Diggin' It]]
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
| [[Road to Ruin]]
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
| [[Un-Bearable]]
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
| [[Crash Dash]]
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
| [[Hang Eight]]
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
| [[Pack Attack]]
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
| [[Crash Crush]]
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
| [[Intro (C2)|Intro]]
| ''(none)''
|-
| <code>1D</code>
| <code>t</code>
| [[Bear It]]
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
| [[Turtle Woods]]
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
| [[The Pits]]
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
| [[Air Crash]]
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
| [[Plant Food]]
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
| [[Bear Down]]
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
| [[The Eel Deal]]
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
| [[Bee-Having]]
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
| [[Totally Bear]]
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
| [[Spaced Out]]
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
| [[Totally Fly]]
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
| [[100% Ending (C2)|100% Ending]]
| ''(none)''
|-
| <code>29</code>
| <code>F</code>
| [[Normal Ending (C2)|Normal Ending]]
| ''(none)''
|-
| <code>2A</code>
| <code>G</code>
| ''(none)''
| ''(none)''
|-
| <code>2B</code>
| <code>H</code>
| ''(none)''
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| ''(none)''
| ''(none)''
|-
| <code>2D</code>
| <code>J</code>
| [[Warp Room (C2)|Warp Room]] (es; PAL only)
| ''(none)''
|-
| <code>2E</code>
| <code>K</code>
| [[Warp Room (C2)|Warp Room]] (fr; PAL only)
| ''(none)''
|-
| <code>2F</code>
| <code>L</code>
| [[Warp Room (C2)|Warp Room]] (de; PAL only)
| ''(none)''
|-
| <code>30</code>
| <code>M</code>
| [[Warp Room (C2)|Warp Room]] (it; PAL only)
| ''(none)''
|-
| <code>31</code>
| <code>N</code>
| ''(none)''
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| ''(none)''
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| ''(none)''
| ''(none)''
|-
| <code>34</code>
| <code>Q</code>
| ''(none)''
| ''(none)''
|-
| <code>35</code>
| <code>R</code>
| ''(none)''
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| ''(none)''
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| ''(none)''
| ''(none)''
|-
| <code>38</code>
| <code>U</code>
| ''(none)''
| ''(none)''
|-
| <code>39</code>
| <code>V</code>
| ''(none)''
| Second gem for [[Ruination]]
|-
| <code>3A</code>
| <code>W</code>
| ''(none)''
| Second gem for [[Snow Go]] (red)
|-
| <code>3B</code>
| <code>X</code>
| [[Game Over (C2)|Game Over]]
| Second gem for [[The Eel Deal]] (green)
|-
| <code>3C</code>
| <code>Y</code>
| [[Title Screen (C2)|Title Screen]]
| Second gem for [[Bee-Havin']] (purple)
|-
| <code>3D</code>
| <code>Z</code>
| ''(none)''
| Second gem for [[Turtle Woods]] (blue)
|-
| <code>3E</code>
| <code>_</code>
| ''(none)''
| Second gem for [[Plant Food]] (yellow)
|}

== Crash 3 ==
{{todo|Add gem ID's for [[Area 51?]], [[Rings of Power]], and the all-gold-relics reward from Coco.}}
Each ID for a level is also used for that level's crystal, relic, and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level which does not have a box gem. These extra gem associations are listed below.

{| class="wikitable"
! Hex
! #
! Level Name
! Associated Gem
|-
| <code>00</code>
| <code>0</code>
| ''(none)''
|-
| <code>01</code>
| <code>1</code>
| ''(none)''
| Second gem for [[Bone Yard]]
|-
| <code>02</code>
| <code>2</code>
| [[Warp Room]]
| Second gem for [[Tomb Time]]
|-
| <code>03</code>
| <code>3</code>
| [[Dingodile|Dingodile (Boss 2)]]
| Second gem for [[Dino Might!]]
|-
| <code>04</code>
| <code>4</code>
| [[N. Tropy|N. Tropy (Boss 3)]]
| Second gem for [[Sphynxinator]]
|-
| <code>05</code>
| <code>5</code>
| [[N. Gin (C3)|N. Gin (Boss 4)]]
| Second gem for [[Future Frenzy]]
|-
| <code>06</code>
| <code>6</code>
| [[Tiny (C3)|Tiny (Boss 1)]]
| Second gem for [[Gone Tomorrow]]
|-
| <code>07</code>
| <code>7</code>
| [[Dr. Neo Cortex (C3)|Dr. Neo Cortex (Boss 5)]]
| Second gem for [[Bug Lite]]
|-
| <code>08</code>
| <code>8</code>
| ''(none)''
|-
| <code>09</code>
| <code>9</code>
| ''(none)''
|-
| <code>0A</code>
| <code>a</code>
| [[Orient Express]]
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| [[Toad Village]]
| ''Box gem''
|-
| <code>0C</code>
| <code>c</code>
| [[Bone Yard]]
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
| [[Tell No Tales]]
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
| [[Under Pressure]]
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
| [[Gee Wiz]]
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
| [[Dino Might!]]
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
| [[Midnight Run]]
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
| [[Tomb Time]]
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
| [[Bye Bye Blimps]]
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| [[Road Crash]]
| ''Box gem''
|-
| <code>15</code>
| <code>l</code>
| [[Hog Ride]]
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
| [[Hang'em High]]
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
| [[Mad Bombers]]
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
| [[Tomb Wader]]
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
| [[Makin' Waves]]
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
| [[High Time]]
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
| [[Future Frenzy]]
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
| [[Deep Trouble]]
| ''Box gem''
|-
| <code>1D</code>
| <code>t</code>
| [[Double Header]]
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
| [[Sphynxinator]]
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
| [[Rings of Power]]
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
| [[Orange Asphalt]]
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
| [[Ski Crazed]]
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
| [[Flaming Passion]]
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
| [[Gone Tomorrow]]
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
| [[Bug Lite]]
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
| [[Area 51?]]
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
| [[Eggipus Rex]]
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
| [[Hot Coco]]
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
| [[Opening Cutscene (C3)|Opening Cutscene]] (en/ja)
|-
| <code>29</code>
| <code>F</code>
| [[Normal Ending (C3)|Any% Ending]]
|-
| <code>2A</code>
| <code>G</code>
| [[100% Ending (C3)|100% Ending]]
|-
| <code>2B</code>
| <code>H</code>
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| ''(none)''
|-
| <code>2D</code>
| <code>J</code>
| [[Opening Cutscene (C3)|Opening Cutscene]] (es; PAL only)
|-
| <code>2E</code>
| <code>K</code>
| [[Opening Cutscene (C3)|Opening Cutscene]] (fr; PAL only)
|-
| <code>2F</code>
| <code>L</code>
| [[Opening Cutscene (C3)|Opening Cutscene]] (de; PAL only)
|-
| <code>30</code>
| <code>M</code>
| [[Opening Cutscene (C3)|Opening Cutscene]] (it; PAL only)
|-
| <code>31</code>
| <code>N</code>
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| ''(none)''
|-
| <code>34</code>
| <code>Q</code>
| ''(none)''
|-
| <code>35</code>
| <code>R</code>
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| ''(none)''
|-
| <code>38</code>
| <code>U</code>
| ''(none)''
|-
| <code>39</code>
| <code>V</code>
| ''(none)''
|-
| <code>3A</code>
| <code>W</code>
| [[Intermission Vortex]]
| Second gem for [[Deep Trouble]] (red)
|-
| <code>3B</code>
| <code>X</code>
| [[Game Over (C3)|Game Over]]
| Second gem for [[Flaming Passion]] (green)
|-
| <code>3C</code>
| <code>Y</code>
| [[Title Screen (C3)|Title Screen]]
| Second gem for [[High Time]] (purple)
|-
| <code>3D</code>
| <code>Z</code>
| ''(none)''
| Second gem for [[Tomb Wader]] (blue)
|-
| <code>3E</code>
| <code>_</code>
| ''(none)''
| Second gem for [[Hang'em High]] (yellow)
|-
| <code>3F</code>
| <code>!</code>
| ''(none)''
|}

Level <code>v</code> (1F), [[Rings of Power]], appears in the S2 directory rather than S1.

Level ID

2019-05-19T14:14:55Z

Chekwob: Removed the basic blank table which was commented out

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.

== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| (none)
|-
| <code>03</code>
| <code>3</code>
| Cortex Power
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| Generator Room
|-
| <code>06</code>
| <code>6</code>
| Heavy Machinery
|-
| <code>07</code>
| <code>7</code>
| Toxic Waste
|-
| <code>08</code>
| <code>8</code>
| Pinstripe (Boss 4)
|-
| <code>09</code>
| <code>9</code>
| N. Sanity Beach
|-
| <code>0A</code>
| <code>a</code>
| Papu Papu (Boss 1)
|-
| <code>0B</code>
| <code>b</code>
| (none)
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| (none)
|-
| <code>0E</code>
| <code>e</code>
| Boulders
|-
| <code>0F</code>
| <code>f</code>
| Upstream
|-
| <code>10</code>
| <code>g</code>
| (none)
|-
| <code>11</code>
| <code>h</code>
| Hog Wild
|-
| <code>12</code>
| <code>i</code>
| The Great Gate
|-
| <code>13</code>
| <code>j</code>
| Boulder Dash
|-
| <code>14</code>
| <code>k</code>
| Road to Nowhere
|-
| <code>15</code>
| <code>l</code>
| Rolling Stones
|-
| <code>16</code>
| <code>m</code>
| The High Road
|-
| <code>17</code>
| <code>n</code>
| Ripper Roo (Boss 2)
|-
| <code>18</code>
| <code>o</code>
| Up The Creek
|-
| <code>19</code>
| <code>p</code>
| Map, Main Menu, Title Sequence
|-
| <code>1A</code>
| <code>q</code>
| Native Fortress
|-
| <code>1B</code>
| <code>r</code>
| Nitrus Brio (Boss 5)
|-
| <code>1C</code>
| <code>s</code>
| Temple Ruins
|-
| <code>1D</code>
| <code>t</code>
| Jaws of Darkness
|-
| <code>1E</code>
| <code>u</code>
| Whole Hog
|-
| <code>1F</code>
| <code>v</code>
| Dr. Neo Cortex (Boss 6)
|-
| <code>20</code>
| <code>w</code>
| The Lost City
|-
| <code>21</code>
| <code>x</code>
| Koala Kong (Boss 3)
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' Stormy Ascent
|-
| <code>23</code>
| <code>z</code>
| Sunset Vista
|-
| <code>24</code>
| <code>A</code>
| Bonus Round (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| Bonus Round (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| Bonus Round '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| (none)
|-
| <code>28</code>
| <code>E</code>
| Lights Out
|-
| <code>29</code>
| <code>F</code>
| The Lab
|-
| <code>2A</code>
| <code>G</code>
| Fumbling in the Dark
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| The Great Hall
|-
| <code>2D</code>
| <code>J</code>
| Level Completion Screen
|-
| <code>2E</code>
| <code>K</code>
| Slippery Climb
|-
| <code>2F</code>
| <code>L</code>
| (none)
|-
| <code>30</code>
| <code>M</code>
| (none)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| Bonus Round (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| Bonus Round (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| Castle Machinery
|-
| <code>38</code>
| <code>U</code>
| Intro
|-
| <code>39</code>
| <code>V</code>
| Ending
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
| (none)
|-
| <code>3C</code>
| <code>Y</code>
| (none)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| Test Area
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| Cavern Level
|-
| <code>0B</code>
| <code>b</code>
| Cliff Level
|-
| <code>0D</code>
| <code>d</code>
| Waterfall Level
|-
| <code>10</code>
| <code>g</code>
| 2D Donkey Kong
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).

Each ID for a level is also used for that level's crystal and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level ID which does not have a box gem. These extra gem associations are listed below.
{| class="wikitable"
!Hex
!#
!Level name
! Associated gem
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Hang Eight
|-
| <code>02</code>
| <code>2</code>
|English Warp Room
| Second gem for Air Crash
|-
| <code>03</code>
| <code>3</code>
|Tiny Tiger
| Second gem for Sewer or Later
|-
| <code>04</code>
| <code>4</code>
| (none)
| Second gem for Road to Ruin
|-
| <code>05</code>
| <code>5</code>
| (none)
| Second gem for Piston It Away
|-
| <code>06</code>
| <code>6</code>
|Ripper Roo
| Second gem for Night Fight
|-
| <code>07</code>
| <code>7</code>
|Dr. Neo Cortex
| Second gem for Spaced Out
|-
| <code>08</code>
| <code>8</code>
|Komodo Bros.
| Second gem for Diggin' It
|-
| <code>09</code>
| <code>9</code>
|N. Gin
| Second gem for Cold Hard Crash
|-
| <code>0A</code>
| <code>a</code>
|Sewer or Later
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| (none); Test jungle level (jungle1)
| ''(none)''
|-
| <code>0C</code>
| <code>c</code>
|Night Fight
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
|Hangin' Out
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
|Snow Go
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
|Ruination
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
|Piston it Away
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
|Snow Biz
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
|Rock It
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
|Cold Hard Crash
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| (none)
| ''(none)''
|-
| <code>15</code>
| <code>l</code>
|Diggin' It
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
|Road to Ruin
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
|Un-Bearable
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
|Crash Dash
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
|Hang Eight
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
|Pack Attack
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
|Crash Crush
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
|Intro
| ''(none)''
|-
| <code>1D</code>
| <code>t</code>
|Bear It
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
|Turtle Woods
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
|The Pits
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
|Air Crash
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
|Plant Food
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
|Bear Down
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
|The Eel Deal
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
|Bee-Having
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
|Totally Bear
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
|Spaced Out
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
|Totally Fly
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
|100% Ending
| ''(none)''
|-
| <code>29</code>
| <code>F</code>
|Normal Ending
| ''(none)''
|-
| <code>2A</code>
| <code>G</code>
| (none)
| ''(none)''
|-
| <code>2B</code>
| <code>H</code>
| (none)
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| (none)
| ''(none)''
|-
| <code>2D</code>
| <code>J</code>
|Spanish Warp Room (PAL only)
| ''(none)''
|-
| <code>2E</code>
| <code>K</code>
|French Warp Room (PAL only)
| ''(none)''
|-
| <code>2F</code>
| <code>L</code>
|German Warp Room (PAL only)
| ''(none)''
|-
| <code>30</code>
| <code>M</code>
|Italian Warp Room (PAL only)
| ''(none)''
|-
| <code>31</code>
| <code>N</code>
| (none)
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| (none)
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| (none)
| ''(none)''
|-
| <code>34</code>
| <code>Q</code>
| (none)
| ''(none)''
|-
| <code>35</code>
| <code>R</code>
| (none)
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| (none)
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| (none)
| ''(none)''
|-
| <code>38</code>
| <code>U</code>
| (none)
| ''(none)''
|-
| <code>39</code>
| <code>V</code>
| (none)
| Second gem for Ruination
|-
| <code>3A</code>
| <code>W</code>
| (none)
| Second gem for Snow Go (red)
|-
| <code>3B</code>
| <code>X</code>
|Game Over Screen
| Second gem for The Eel Deal (green)
|-
| <code>3C</code>
| <code>Y</code>
|Title Screen
| Second gem for Bee-Havin' (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Turtle Woods (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Plant Food (yellow)
|}

== Crash 3 ==
{{todo|Add gem ID's for ''Area 51?'', ''Rings of Power'', and the all-gold-relics reward from Coco.}}
Each ID for a level is also used for that level's crystal, relic, and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level which does not have a box gem. These extra gem associations are listed below.

{| class="wikitable"
! Hex
! #
! Level Name
! Associated Gem
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Bone Yard
|-
| <code>02</code>
| <code>2</code>
| Warp Room (English or Japanese)
| Second gem for Tomb Time
|-
| <code>03</code>
| <code>3</code>
| Dingodile (Boss 2)
| Second gem for Dino Might!
|-
| <code>04</code>
| <code>4</code>
| N. Tropy (Boss 3)
| Second gem for Sphynxinator
|-
| <code>05</code>
| <code>5</code>
| N. Gin (Boss 4)
| Second gem for Future Frenzy
|-
| <code>06</code>
| <code>6</code>
| Tiny (Boss 1)
| Second gem for Gone Tomorrow
|-
| <code>07</code>
| <code>7</code>
| Dr. Neo Cortex (Boss 5)
| Second gem for Bug Lite
|-
| <code>08</code>
| <code>8</code>
| (none)
|-
| <code>09</code>
| <code>9</code>
| (none)
|-
| <code>0A</code>
| <code>a</code>
| Orient Express
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| Toad Village
| ''Box gem''
|-
| <code>0C</code>
| <code>c</code>
| Bone Yard
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
| Tell No Tales
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
| Under Pressure
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
| Gee Wiz
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
| Dino Might!
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
| Midnight Run
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
| Tomb Time
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
| Bye Bye Blimps
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| Road Crash
| ''Box gem''
|-
| <code>15</code>
| <code>l</code>
| Hog Ride
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
| Hang'em High
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
| Mad Bombers
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
| Tomb Wader
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
| Makin' Waves
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
| High Time
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
| Future Frenzy
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
| Deep Trouble
| ''Box gem''
|-
| <code>1D</code>
| <code>t</code>
| Double Header
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
| Sphynxinator
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
| Rings of Power
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
| Orange Asphalt
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
| Ski Crazed
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
| Flaming Passion
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
| Gone Tomorrow
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
| Bug Lite
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
| Area 51?
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
| Eggipus Rex
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
| Hot Coco
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
| Opening Cutscene (English and Japanese)
|-
| <code>29</code>
| <code>F</code>
| Any% Ending Cutscene
|-
| <code>2A</code>
| <code>G</code>
| 100% Ending Cutscene
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
| Opening Cutscene (Spanish, PAL only)
|-
| <code>2E</code>
| <code>K</code>
| Opening Cutscene (French, PAL only)
|-
| <code>2F</code>
| <code>L</code>
| Opening Cutscene (German, PAL only)
|-
| <code>30</code>
| <code>M</code>
| Opening Cutscene (Italian, PAL only)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| Intermission Vortex
| Second gem for Deep Trouble (red)
|-
| <code>3B</code>
| <code>X</code>
| Game Over Screen
| Second gem for Flaming Passion (green)
|-
| <code>3C</code>
| <code>Y</code>
| Title Screen
| Second gem for High Time (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Tomb Wader (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Hang'em High (yellow)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>v</code> (1F), ''Rings of Power'', appears in the S2 directory rather than S1.

MediaWiki:Common.css

2019-04-29T16:02:36Z

Chekwob: Added some right-side padding to noticeboxes

/* CSS placed here will be applied to all skins */

.noticebox {
display: table;
padding-left: 16px;
padding-right: 16px;
min-width: 30%;
border-radius: 0px 16px 16px 0px;
font-size: 1.2em;
}

.noticebox-todo {
background-color: BlanchedAlmond;
}

Category:Pages with TODO

2019-04-29T15:59:08Z

Chekwob: Created page with "Pages are placed into this category because they contain an instance of the Todo template. This indicates that some information in the page is incomplete or..."

Pages are placed into this category because they contain an instance of the [[Template:Todo|Todo template]]. This indicates that some information in the page is incomplete or in need of verification or correction.

Level ID

2019-04-29T15:54:23Z

Chekwob: /* Crash 3 */ Fix gone tomorrow ID placement

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.



== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| (none)
|-
| <code>03</code>
| <code>3</code>
| Cortex Power
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| Generator Room
|-
| <code>06</code>
| <code>6</code>
| Heavy Machinery
|-
| <code>07</code>
| <code>7</code>
| Toxic Waste
|-
| <code>08</code>
| <code>8</code>
| Pinstripe (Boss 4)
|-
| <code>09</code>
| <code>9</code>
| N. Sanity Beach
|-
| <code>0A</code>
| <code>a</code>
| Papu Papu (Boss 1)
|-
| <code>0B</code>
| <code>b</code>
| (none)
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| (none)
|-
| <code>0E</code>
| <code>e</code>
| Boulders
|-
| <code>0F</code>
| <code>f</code>
| Upstream
|-
| <code>10</code>
| <code>g</code>
| (none)
|-
| <code>11</code>
| <code>h</code>
| Hog Wild
|-
| <code>12</code>
| <code>i</code>
| The Great Gate
|-
| <code>13</code>
| <code>j</code>
| Boulder Dash
|-
| <code>14</code>
| <code>k</code>
| Road to Nowhere
|-
| <code>15</code>
| <code>l</code>
| Rolling Stones
|-
| <code>16</code>
| <code>m</code>
| The High Road
|-
| <code>17</code>
| <code>n</code>
| Ripper Roo (Boss 2)
|-
| <code>18</code>
| <code>o</code>
| Up The Creek
|-
| <code>19</code>
| <code>p</code>
| Map, Main Menu, Title Sequence
|-
| <code>1A</code>
| <code>q</code>
| Native Fortress
|-
| <code>1B</code>
| <code>r</code>
| Nitrus Brio (Boss 5)
|-
| <code>1C</code>
| <code>s</code>
| Temple Ruins
|-
| <code>1D</code>
| <code>t</code>
| Jaws of Darkness
|-
| <code>1E</code>
| <code>u</code>
| Whole Hog
|-
| <code>1F</code>
| <code>v</code>
| Dr. Neo Cortex (Boss 6)
|-
| <code>20</code>
| <code>w</code>
| The Lost City
|-
| <code>21</code>
| <code>x</code>
| Koala Kong (Boss 3)
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' Stormy Ascent
|-
| <code>23</code>
| <code>z</code>
| Sunset Vista
|-
| <code>24</code>
| <code>A</code>
| Bonus Round (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| Bonus Round (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| Bonus Round '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| (none)
|-
| <code>28</code>
| <code>E</code>
| Lights Out
|-
| <code>29</code>
| <code>F</code>
| The Lab
|-
| <code>2A</code>
| <code>G</code>
| Fumbling in the Dark
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| The Great Hall
|-
| <code>2D</code>
| <code>J</code>
| Level Completion Screen
|-
| <code>2E</code>
| <code>K</code>
| Slippery Climb
|-
| <code>2F</code>
| <code>L</code>
| (none)
|-
| <code>30</code>
| <code>M</code>
| (none)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| Bonus Round (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| Bonus Round (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| Castle Machinery
|-
| <code>38</code>
| <code>U</code>
| Intro
|-
| <code>39</code>
| <code>V</code>
| Ending
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
| (none)
|-
| <code>3C</code>
| <code>Y</code>
| (none)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| Test Area
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| Cavern Level
|-
| <code>0B</code>
| <code>b</code>
| Cliff Level
|-
| <code>0D</code>
| <code>d</code>
| Waterfall Level
|-
| <code>10</code>
| <code>g</code>
| 2D Donkey Kong
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).

Each ID for a level is also used for that level's crystal and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level ID which does not have a box gem. These extra gem associations are listed below.
{| class="wikitable"
!Hex
!#
!Level name
! Associated gem
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Hang Eight
|-
| <code>02</code>
| <code>2</code>
|English Warp Room
| Second gem for Air Crash
|-
| <code>03</code>
| <code>3</code>
|Tiny Tiger
| Second gem for Sewer or Later
|-
| <code>04</code>
| <code>4</code>
| (none)
| Second gem for Road to Ruin
|-
| <code>05</code>
| <code>5</code>
| (none)
| Second gem for Piston It Away
|-
| <code>06</code>
| <code>6</code>
|Ripper Roo
| Second gem for Night Fight
|-
| <code>07</code>
| <code>7</code>
|Dr. Neo Cortex
| Second gem for Spaced Out
|-
| <code>08</code>
| <code>8</code>
|Komodo Bros.
| Second gem for Diggin' It
|-
| <code>09</code>
| <code>9</code>
|N. Gin
| Second gem for Cold Hard Crash
|-
| <code>0A</code>
| <code>a</code>
|Sewer or Later
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| (none); Test jungle level (jungle1)
| ''(none)''
|-
| <code>0C</code>
| <code>c</code>
|Night Fight
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
|Hangin' Out
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
|Snow Go
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
|Ruination
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
|Piston it Away
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
|Snow Biz
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
|Rock It
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
|Cold Hard Crash
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| (none)
| ''(none)''
|-
| <code>15</code>
| <code>l</code>
|Diggin' It
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
|Road to Ruin
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
|Un-Bearable
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
|Crash Dash
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
|Hang Eight
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
|Pack Attack
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
|Crash Crush
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
|Intro
| ''(none)''
|-
| <code>1D</code>
| <code>t</code>
|Bear It
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
|Turtle Woods
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
|The Pits
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
|Air Crash
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
|Plant Food
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
|Bear Down
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
|The Eel Deal
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
|Bee-Having
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
|Totally Bear
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
|Spaced Out
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
|Totally Fly
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
|100% Ending
| ''(none)''
|-
| <code>29</code>
| <code>F</code>
|Normal Ending
| ''(none)''
|-
| <code>2A</code>
| <code>G</code>
| (none)
| ''(none)''
|-
| <code>2B</code>
| <code>H</code>
| (none)
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| (none)
| ''(none)''
|-
| <code>2D</code>
| <code>J</code>
|Spanish Warp Room (PAL only)
| ''(none)''
|-
| <code>2E</code>
| <code>K</code>
|French Warp Room (PAL only)
| ''(none)''
|-
| <code>2F</code>
| <code>L</code>
|German Warp Room (PAL only)
| ''(none)''
|-
| <code>30</code>
| <code>M</code>
|Italian Warp Room (PAL only)
| ''(none)''
|-
| <code>31</code>
| <code>N</code>
| (none)
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| (none)
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| (none)
| ''(none)''
|-
| <code>34</code>
| <code>Q</code>
| (none)
| ''(none)''
|-
| <code>35</code>
| <code>R</code>
| (none)
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| (none)
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| (none)
| ''(none)''
|-
| <code>38</code>
| <code>U</code>
| (none)
| ''(none)''
|-
| <code>39</code>
| <code>V</code>
| (none)
| Second gem for Ruination
|-
| <code>3A</code>
| <code>W</code>
| (none)
| Second gem for Snow Go (red)
|-
| <code>3B</code>
| <code>X</code>
|Game Over Screen
| Second gem for The Eel Deal (green)
|-
| <code>3C</code>
| <code>Y</code>
|Title Screen
| Second gem for Bee-Havin' (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Turtle Woods (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Plant Food (yellow)
|}

== Crash 3 ==
{{todo|Add gem ID's for ''Area 51?'', ''Rings of Power'', and the all-gold-relics reward from Coco.}}
Each ID for a level is also used for that level's crystal, relic, and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level which does not have a box gem. These extra gem associations are listed below.

{| class="wikitable"
! Hex
! #
! Level Name
! Associated Gem
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Bone Yard
|-
| <code>02</code>
| <code>2</code>
| Warp Room (English or Japanese)
| Second gem for Tomb Time
|-
| <code>03</code>
| <code>3</code>
| Dingodile (Boss 2)
| Second gem for Dino Might!
|-
| <code>04</code>
| <code>4</code>
| N. Tropy (Boss 3)
| Second gem for Sphynxinator
|-
| <code>05</code>
| <code>5</code>
| N. Gin (Boss 4)
| Second gem for Future Frenzy
|-
| <code>06</code>
| <code>6</code>
| Tiny (Boss 1)
| Second gem for Gone Tomorrow
|-
| <code>07</code>
| <code>7</code>
| Dr. Neo Cortex (Boss 5)
| Second gem for Bug Lite
|-
| <code>08</code>
| <code>8</code>
| (none)
|-
| <code>09</code>
| <code>9</code>
| (none)
|-
| <code>0A</code>
| <code>a</code>
| Orient Express
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| Toad Village
| ''Box gem''
|-
| <code>0C</code>
| <code>c</code>
| Bone Yard
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
| Tell No Tales
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
| Under Pressure
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
| Gee Wiz
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
| Dino Might!
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
| Midnight Run
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
| Tomb Time
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
| Bye Bye Blimps
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| Road Crash
| ''Box gem''
|-
| <code>15</code>
| <code>l</code>
| Hog Ride
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
| Hang'em High
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
| Mad Bombers
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
| Tomb Wader
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
| Makin' Waves
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
| High Time
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
| Future Frenzy
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
| Deep Trouble
| ''Box gem''
|-
| <code>1D</code>
| <code>t</code>
| Double Header
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
| Sphynxinator
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
| Rings of Power
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
| Orange Asphalt
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
| Ski Crazed
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
| Flaming Passion
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
| Gone Tomorrow
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
| Bug Lite
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
| Area 51?
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
| Eggipus Rex
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
| Hot Coco
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
| Opening Cutscene (English and Japanese)
|-
| <code>29</code>
| <code>F</code>
| Any% Ending Cutscene
|-
| <code>2A</code>
| <code>G</code>
| 100% Ending Cutscene
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
| Opening Cutscene (Spanish, PAL only)
|-
| <code>2E</code>
| <code>K</code>
| Opening Cutscene (French, PAL only)
|-
| <code>2F</code>
| <code>L</code>
| Opening Cutscene (German, PAL only)
|-
| <code>30</code>
| <code>M</code>
| Opening Cutscene (Italian, PAL only)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| Intermission Vortex
| Second gem for Deep Trouble (red)
|-
| <code>3B</code>
| <code>X</code>
| Game Over Screen
| Second gem for Flaming Passion (green)
|-
| <code>3C</code>
| <code>Y</code>
| Title Screen
| Second gem for High Time (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Tomb Wader (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Hang'em High (yellow)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>v</code> (1F), ''Rings of Power'', appears in the S2 directory rather than S1.

Level ID

2019-04-29T15:53:10Z

Chekwob: /* Crash 3 */ Add most gem ID assignments

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.



== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| (none)
|-
| <code>03</code>
| <code>3</code>
| Cortex Power
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| Generator Room
|-
| <code>06</code>
| <code>6</code>
| Heavy Machinery
|-
| <code>07</code>
| <code>7</code>
| Toxic Waste
|-
| <code>08</code>
| <code>8</code>
| Pinstripe (Boss 4)
|-
| <code>09</code>
| <code>9</code>
| N. Sanity Beach
|-
| <code>0A</code>
| <code>a</code>
| Papu Papu (Boss 1)
|-
| <code>0B</code>
| <code>b</code>
| (none)
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| (none)
|-
| <code>0E</code>
| <code>e</code>
| Boulders
|-
| <code>0F</code>
| <code>f</code>
| Upstream
|-
| <code>10</code>
| <code>g</code>
| (none)
|-
| <code>11</code>
| <code>h</code>
| Hog Wild
|-
| <code>12</code>
| <code>i</code>
| The Great Gate
|-
| <code>13</code>
| <code>j</code>
| Boulder Dash
|-
| <code>14</code>
| <code>k</code>
| Road to Nowhere
|-
| <code>15</code>
| <code>l</code>
| Rolling Stones
|-
| <code>16</code>
| <code>m</code>
| The High Road
|-
| <code>17</code>
| <code>n</code>
| Ripper Roo (Boss 2)
|-
| <code>18</code>
| <code>o</code>
| Up The Creek
|-
| <code>19</code>
| <code>p</code>
| Map, Main Menu, Title Sequence
|-
| <code>1A</code>
| <code>q</code>
| Native Fortress
|-
| <code>1B</code>
| <code>r</code>
| Nitrus Brio (Boss 5)
|-
| <code>1C</code>
| <code>s</code>
| Temple Ruins
|-
| <code>1D</code>
| <code>t</code>
| Jaws of Darkness
|-
| <code>1E</code>
| <code>u</code>
| Whole Hog
|-
| <code>1F</code>
| <code>v</code>
| Dr. Neo Cortex (Boss 6)
|-
| <code>20</code>
| <code>w</code>
| The Lost City
|-
| <code>21</code>
| <code>x</code>
| Koala Kong (Boss 3)
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' Stormy Ascent
|-
| <code>23</code>
| <code>z</code>
| Sunset Vista
|-
| <code>24</code>
| <code>A</code>
| Bonus Round (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| Bonus Round (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| Bonus Round '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| (none)
|-
| <code>28</code>
| <code>E</code>
| Lights Out
|-
| <code>29</code>
| <code>F</code>
| The Lab
|-
| <code>2A</code>
| <code>G</code>
| Fumbling in the Dark
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| The Great Hall
|-
| <code>2D</code>
| <code>J</code>
| Level Completion Screen
|-
| <code>2E</code>
| <code>K</code>
| Slippery Climb
|-
| <code>2F</code>
| <code>L</code>
| (none)
|-
| <code>30</code>
| <code>M</code>
| (none)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| Bonus Round (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| Bonus Round (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| Castle Machinery
|-
| <code>38</code>
| <code>U</code>
| Intro
|-
| <code>39</code>
| <code>V</code>
| Ending
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
| (none)
|-
| <code>3C</code>
| <code>Y</code>
| (none)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| Test Area
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| Cavern Level
|-
| <code>0B</code>
| <code>b</code>
| Cliff Level
|-
| <code>0D</code>
| <code>d</code>
| Waterfall Level
|-
| <code>10</code>
| <code>g</code>
| 2D Donkey Kong
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).

Each ID for a level is also used for that level's crystal and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level ID which does not have a box gem. These extra gem associations are listed below.
{| class="wikitable"
!Hex
!#
!Level name
! Associated gem
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Hang Eight
|-
| <code>02</code>
| <code>2</code>
|English Warp Room
| Second gem for Air Crash
|-
| <code>03</code>
| <code>3</code>
|Tiny Tiger
| Second gem for Sewer or Later
|-
| <code>04</code>
| <code>4</code>
| (none)
| Second gem for Road to Ruin
|-
| <code>05</code>
| <code>5</code>
| (none)
| Second gem for Piston It Away
|-
| <code>06</code>
| <code>6</code>
|Ripper Roo
| Second gem for Night Fight
|-
| <code>07</code>
| <code>7</code>
|Dr. Neo Cortex
| Second gem for Spaced Out
|-
| <code>08</code>
| <code>8</code>
|Komodo Bros.
| Second gem for Diggin' It
|-
| <code>09</code>
| <code>9</code>
|N. Gin
| Second gem for Cold Hard Crash
|-
| <code>0A</code>
| <code>a</code>
|Sewer or Later
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| (none); Test jungle level (jungle1)
| ''(none)''
|-
| <code>0C</code>
| <code>c</code>
|Night Fight
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
|Hangin' Out
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
|Snow Go
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
|Ruination
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
|Piston it Away
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
|Snow Biz
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
|Rock It
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
|Cold Hard Crash
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| (none)
| ''(none)''
|-
| <code>15</code>
| <code>l</code>
|Diggin' It
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
|Road to Ruin
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
|Un-Bearable
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
|Crash Dash
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
|Hang Eight
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
|Pack Attack
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
|Crash Crush
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
|Intro
| ''(none)''
|-
| <code>1D</code>
| <code>t</code>
|Bear It
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
|Turtle Woods
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
|The Pits
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
|Air Crash
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
|Plant Food
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
|Bear Down
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
|The Eel Deal
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
|Bee-Having
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
|Totally Bear
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
|Spaced Out
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
|Totally Fly
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
|100% Ending
| ''(none)''
|-
| <code>29</code>
| <code>F</code>
|Normal Ending
| ''(none)''
|-
| <code>2A</code>
| <code>G</code>
| (none)
| ''(none)''
|-
| <code>2B</code>
| <code>H</code>
| (none)
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| (none)
| ''(none)''
|-
| <code>2D</code>
| <code>J</code>
|Spanish Warp Room (PAL only)
| ''(none)''
|-
| <code>2E</code>
| <code>K</code>
|French Warp Room (PAL only)
| ''(none)''
|-
| <code>2F</code>
| <code>L</code>
|German Warp Room (PAL only)
| ''(none)''
|-
| <code>30</code>
| <code>M</code>
|Italian Warp Room (PAL only)
| ''(none)''
|-
| <code>31</code>
| <code>N</code>
| (none)
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| (none)
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| (none)
| ''(none)''
|-
| <code>34</code>
| <code>Q</code>
| (none)
| ''(none)''
|-
| <code>35</code>
| <code>R</code>
| (none)
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| (none)
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| (none)
| ''(none)''
|-
| <code>38</code>
| <code>U</code>
| (none)
| ''(none)''
|-
| <code>39</code>
| <code>V</code>
| (none)
| Second gem for Ruination
|-
| <code>3A</code>
| <code>W</code>
| (none)
| Second gem for Snow Go (red)
|-
| <code>3B</code>
| <code>X</code>
|Game Over Screen
| Second gem for The Eel Deal (green)
|-
| <code>3C</code>
| <code>Y</code>
|Title Screen
| Second gem for Bee-Havin' (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Turtle Woods (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Plant Food (yellow)
|}

== Crash 3 ==
{{todo|Add gem ID's for ''Area 51?'', ''Rings of Power'', and the all-gold-relics reward from Coco.}}
Each ID for a level is also used for that level's crystal, relic, and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level which does not have a box gem. These extra gem associations are listed below.

{| class="wikitable"
! Hex
! #
! Level Name
! Associated Gem
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Bone Yard
|-
| <code>02</code>
| <code>2</code>
| Warp Room (English or Japanese)
| Second gem for Tomb Time
|-
| <code>03</code>
| <code>3</code>
| Dingodile (Boss 2)
| Second gem for Dino Might!
|-
| <code>04</code>
| <code>4</code>
| N. Tropy (Boss 3)
| Second gem for Sphynxinator
|-
| <code>05</code>
| <code>5</code>
| N. Gin (Boss 4)
| Second gem for Future Frenzy
|-
| <code>06</code>
| <code>6</code>
| Tiny (Boss 1)
| Second gem for Gone Tomorrow
|-
| <code>07</code>
| <code>7</code>
| Dr. Neo Cortex (Boss 5)
| Second gem for Bug Lite
|-
| <code>08</code>
| <code>8</code>
| (none)
|-
| <code>09</code>
| <code>9</code>
| (none)
|-
| <code>0A</code>
| <code>a</code>
| Orient Express
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| Toad Village
| ''Box gem''
|-
| <code>0C</code>
| <code>c</code>
| Bone Yard
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
| Tell No Tales
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
| Under Pressure
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
| Gee Wiz
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
| Dino Might!
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
| Midnight Run
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
| Tomb Time
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
| Bye Bye Blimps
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| Road Crash
| ''Box gem''
|-
| <code>15</code>
| <code>l</code>
| Hog Ride
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
| Hang'em High
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
| Mad Bombers
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
| Tomb Wader
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
| Makin' Waves
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
| High Time
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
| Future Frenzy
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
| Deep Trouble
| ''Box gem''
|-
| <code>1D</code>
| <code>t</code>
| Double Header
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
| Sphynxinator
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
| Rings of Power
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
| Orange Asphalt
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
| Ski Crazed
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
| Flaming Passion
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
| Future Frenzy
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
| Bug Lite
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
| Area 51?
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
| Eggipus Rex
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
| Hot Coco
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
| Opening Cutscene (English and Japanese)
|-
| <code>29</code>
| <code>F</code>
| Any% Ending Cutscene
|-
| <code>2A</code>
| <code>G</code>
| 100% Ending Cutscene
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
| Opening Cutscene (Spanish, PAL only)
|-
| <code>2E</code>
| <code>K</code>
| Opening Cutscene (French, PAL only)
|-
| <code>2F</code>
| <code>L</code>
| Opening Cutscene (German, PAL only)
|-
| <code>30</code>
| <code>M</code>
| Opening Cutscene (Italian, PAL only)
|-
| <code>31</code>
| <code>N</code>
| Gone Tomorrow
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| Intermission Vortex
| Second gem for Deep Trouble (red)
|-
| <code>3B</code>
| <code>X</code>
| Game Over Screen
| Second gem for Flaming Passion (green)
|-
| <code>3C</code>
| <code>Y</code>
| Title Screen
| Second gem for High Time (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Tomb Wader (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Hang'em High (yellow)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>v</code> (1F), ''Rings of Power'', appears in the S2 directory rather than S1.

Template:Todo

2019-04-29T15:18:09Z

Chekwob: Added the basic TODO box

<noinclude>
<pre>{{todo|<reason for the todo>}}</pre>

Use this template to place a "To do" noticebox. The page will be automatically added to the category [[:Category:Pages with TODO]].

== Example Usage ==
<pre>{{todo|Explain the 4 and 8 flags.}}</pre>

== Example Outcome ==
<div class="noticebox noticebox-todo">
'''To do:''' Explain the 4 and 8 flags.
</div>

[[Category:Noticebox Templates]]
</noinclude>

<includeonly>
<div class="noticebox noticebox-todo">
'''To do:''' {{{1}}}
</div>
[[Category:Pages with TODO]]
</includeonly>

MediaWiki:Common.css

2019-04-29T14:50:01Z

Chekwob: Added noticebox and noticebox-todo class styles

/* CSS placed here will be applied to all skins */

.noticebox {
display: table;
padding-left: 16px;
min-width: 30%;
border-radius: 0px 16px 16px 0px;
font-size: 1.2em;
}

.noticebox-todo {
background-color: BlanchedAlmond;
}

Level ID

2019-04-27T20:13:21Z

Chekwob: /* Crash 2 */ Add gem ID assignments

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.



== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| (none)
|-
| <code>03</code>
| <code>3</code>
| Cortex Power
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| Generator Room
|-
| <code>06</code>
| <code>6</code>
| Heavy Machinery
|-
| <code>07</code>
| <code>7</code>
| Toxic Waste
|-
| <code>08</code>
| <code>8</code>
| Pinstripe (Boss 4)
|-
| <code>09</code>
| <code>9</code>
| N. Sanity Beach
|-
| <code>0A</code>
| <code>a</code>
| Papu Papu (Boss 1)
|-
| <code>0B</code>
| <code>b</code>
| (none)
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| (none)
|-
| <code>0E</code>
| <code>e</code>
| Boulders
|-
| <code>0F</code>
| <code>f</code>
| Upstream
|-
| <code>10</code>
| <code>g</code>
| (none)
|-
| <code>11</code>
| <code>h</code>
| Hog Wild
|-
| <code>12</code>
| <code>i</code>
| The Great Gate
|-
| <code>13</code>
| <code>j</code>
| Boulder Dash
|-
| <code>14</code>
| <code>k</code>
| Road to Nowhere
|-
| <code>15</code>
| <code>l</code>
| Rolling Stones
|-
| <code>16</code>
| <code>m</code>
| The High Road
|-
| <code>17</code>
| <code>n</code>
| Ripper Roo (Boss 2)
|-
| <code>18</code>
| <code>o</code>
| Up The Creek
|-
| <code>19</code>
| <code>p</code>
| Map, Main Menu, Title Sequence
|-
| <code>1A</code>
| <code>q</code>
| Native Fortress
|-
| <code>1B</code>
| <code>r</code>
| Nitrus Brio (Boss 5)
|-
| <code>1C</code>
| <code>s</code>
| Temple Ruins
|-
| <code>1D</code>
| <code>t</code>
| Jaws of Darkness
|-
| <code>1E</code>
| <code>u</code>
| Whole Hog
|-
| <code>1F</code>
| <code>v</code>
| Dr. Neo Cortex (Boss 6)
|-
| <code>20</code>
| <code>w</code>
| The Lost City
|-
| <code>21</code>
| <code>x</code>
| Koala Kong (Boss 3)
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' Stormy Ascent
|-
| <code>23</code>
| <code>z</code>
| Sunset Vista
|-
| <code>24</code>
| <code>A</code>
| Bonus Round (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| Bonus Round (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| Bonus Round '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| (none)
|-
| <code>28</code>
| <code>E</code>
| Lights Out
|-
| <code>29</code>
| <code>F</code>
| The Lab
|-
| <code>2A</code>
| <code>G</code>
| Fumbling in the Dark
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| The Great Hall
|-
| <code>2D</code>
| <code>J</code>
| Level Completion Screen
|-
| <code>2E</code>
| <code>K</code>
| Slippery Climb
|-
| <code>2F</code>
| <code>L</code>
| (none)
|-
| <code>30</code>
| <code>M</code>
| (none)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| Bonus Round (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| Bonus Round (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| Castle Machinery
|-
| <code>38</code>
| <code>U</code>
| Intro
|-
| <code>39</code>
| <code>V</code>
| Ending
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
| (none)
|-
| <code>3C</code>
| <code>Y</code>
| (none)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| Test Area
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| Cavern Level
|-
| <code>0B</code>
| <code>b</code>
| Cliff Level
|-
| <code>0D</code>
| <code>d</code>
| Waterfall Level
|-
| <code>10</code>
| <code>g</code>
| 2D Donkey Kong
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).

Each ID for a level is also used for that level's crystal and box gem. Some levels have an additional (non-box) gem. In this case, the ID for this extra gem is stolen from another level ID which does not have a box gem. These extra gem associations are listed below.
{| class="wikitable"
!Hex
!#
!Level name
! Associated gem
|-
| <code>01</code>
| <code>1</code>
| (none)
| Second gem for Hang Eight
|-
| <code>02</code>
| <code>2</code>
|English Warp Room
| Second gem for Air Crash
|-
| <code>03</code>
| <code>3</code>
|Tiny Tiger
| Second gem for Sewer or Later
|-
| <code>04</code>
| <code>4</code>
| (none)
| Second gem for Road to Ruin
|-
| <code>05</code>
| <code>5</code>
| (none)
| Second gem for Piston It Away
|-
| <code>06</code>
| <code>6</code>
|Ripper Roo
| Second gem for Night Fight
|-
| <code>07</code>
| <code>7</code>
|Dr. Neo Cortex
| Second gem for Spaced Out
|-
| <code>08</code>
| <code>8</code>
|Komodo Bros.
| Second gem for Diggin' It
|-
| <code>09</code>
| <code>9</code>
|N. Gin
| Second gem for Cold Hard Crash
|-
| <code>0A</code>
| <code>a</code>
|Sewer or Later
| ''Box gem''
|-
| <code>0B</code>
| <code>b</code>
| (none); Test jungle level (jungle1)
| ''(none)''
|-
| <code>0C</code>
| <code>c</code>
|Night Fight
| ''Box gem''
|-
| <code>0D</code>
| <code>d</code>
|Hangin' Out
| ''Box gem''
|-
| <code>0E</code>
| <code>e</code>
|Snow Go
| ''Box gem''
|-
| <code>0F</code>
| <code>f</code>
|Ruination
| ''Box gem''
|-
| <code>10</code>
| <code>g</code>
|Piston it Away
| ''Box gem''
|-
| <code>11</code>
| <code>h</code>
|Snow Biz
| ''Box gem''
|-
| <code>12</code>
| <code>i</code>
|Rock It
| ''Box gem''
|-
| <code>13</code>
| <code>j</code>
|Cold Hard Crash
| ''Box gem''
|-
| <code>14</code>
| <code>k</code>
| (none)
| ''(none)''
|-
| <code>15</code>
| <code>l</code>
|Diggin' It
| ''Box gem''
|-
| <code>16</code>
| <code>m</code>
|Road to Ruin
| ''Box gem''
|-
| <code>17</code>
| <code>n</code>
|Un-Bearable
| ''Box gem''
|-
| <code>18</code>
| <code>o</code>
|Crash Dash
| ''Box gem''
|-
| <code>19</code>
| <code>p</code>
|Hang Eight
| ''Box gem''
|-
| <code>1A</code>
| <code>q</code>
|Pack Attack
| ''Box gem''
|-
| <code>1B</code>
| <code>r</code>
|Crash Crush
| ''Box gem''
|-
| <code>1C</code>
| <code>s</code>
|Intro
| ''(none)''
|-
| <code>1D</code>
| <code>t</code>
|Bear It
| ''Box gem''
|-
| <code>1E</code>
| <code>u</code>
|Turtle Woods
| ''Box gem''
|-
| <code>1F</code>
| <code>v</code>
|The Pits
| ''Box gem''
|-
| <code>20</code>
| <code>w</code>
|Air Crash
| ''Box gem''
|-
| <code>21</code>
| <code>x</code>
|Plant Food
| ''Box gem''
|-
| <code>22</code>
| <code>y</code>
|Bear Down
| ''Box gem''
|-
| <code>23</code>
| <code>z</code>
|The Eel Deal
| ''Box gem''
|-
| <code>24</code>
| <code>A</code>
|Bee-Having
| ''Box gem''
|-
| <code>25</code>
| <code>B</code>
|Totally Bear
| ''Box gem''
|-
| <code>26</code>
| <code>C</code>
|Spaced Out
| ''Box gem''
|-
| <code>27</code>
| <code>D</code>
|Totally Fly
| ''Box gem''
|-
| <code>28</code>
| <code>E</code>
|100% Ending
| ''(none)''
|-
| <code>29</code>
| <code>F</code>
|Normal Ending
| ''(none)''
|-
| <code>2A</code>
| <code>G</code>
| (none)
| ''(none)''
|-
| <code>2B</code>
| <code>H</code>
| (none)
| ''(none)''
|-
| <code>2C</code>
| <code>I</code>
| (none)
| ''(none)''
|-
| <code>2D</code>
| <code>J</code>
|Spanish Warp Room (PAL only)
| ''(none)''
|-
| <code>2E</code>
| <code>K</code>
|French Warp Room (PAL only)
| ''(none)''
|-
| <code>2F</code>
| <code>L</code>
|German Warp Room (PAL only)
| ''(none)''
|-
| <code>30</code>
| <code>M</code>
|Italian Warp Room (PAL only)
| ''(none)''
|-
| <code>31</code>
| <code>N</code>
| (none)
| ''(none)''
|-
| <code>32</code>
| <code>O</code>
| (none)
| ''(none)''
|-
| <code>33</code>
| <code>P</code>
| (none)
| ''(none)''
|-
| <code>34</code>
| <code>Q</code>
| (none)
| ''(none)''
|-
| <code>35</code>
| <code>R</code>
| (none)
| ''(none)''
|-
| <code>36</code>
| <code>S</code>
| (none)
| ''(none)''
|-
| <code>37</code>
| <code>T</code>
| (none)
| ''(none)''
|-
| <code>38</code>
| <code>U</code>
| (none)
| ''(none)''
|-
| <code>39</code>
| <code>V</code>
| (none)
| Second gem for Ruination
|-
| <code>3A</code>
| <code>W</code>
| (none)
| Second gem for Snow Go (red)
|-
| <code>3B</code>
| <code>X</code>
|Game Over Screen
| Second gem for The Eel Deal (green)
|-
| <code>3C</code>
| <code>Y</code>
|Title Screen
| Second gem for Bee-Havin' (purple)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
| Second gem for Turtle Woods (blue)
|-
| <code>3E</code>
| <code>_</code>
| (none)
| Second gem for Plant Food (yellow)
|}

== Crash 3 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| Warp Room (English or Japanese)
|-
| <code>03</code>
| <code>3</code>
| Dingodile (Boss 2)
|-
| <code>04</code>
| <code>4</code>
| N. Tropy (Boss 3)
|-
| <code>05</code>
| <code>5</code>
| N. Gin (Boss 4)
|-
| <code>06</code>
| <code>6</code>
| Tiny (Boss 1)
|-
| <code>07</code>
| <code>7</code>
| Dr. Neo Cortex (Boss 5)
|-
| <code>08</code>
| <code>8</code>
| (none)
|-
| <code>09</code>
| <code>9</code>
| (none)
|-
| <code>0A</code>
| <code>a</code>
| Orient Express
|-
| <code>0B</code>
| <code>b</code>
| Toad Village
|-
| <code>0C</code>
| <code>c</code>
| Bone Yard
|-
| <code>0D</code>
| <code>d</code>
| Tell No Tales
|-
| <code>0E</code>
| <code>e</code>
| Under Pressure
|-
| <code>0F</code>
| <code>f</code>
| Gee Wiz
|-
| <code>10</code>
| <code>g</code>
| Dino Might!
|-
| <code>11</code>
| <code>h</code>
| Midnight Run
|-
| <code>12</code>
| <code>i</code>
| Tomb Time
|-
| <code>13</code>
| <code>j</code>
| Bye Bye Blimps
|-
| <code>14</code>
| <code>k</code>
| Road Crash
|-
| <code>15</code>
| <code>l</code>
| Hog Ride
|-
| <code>16</code>
| <code>m</code>
| Hang'em High
|-
| <code>17</code>
| <code>n</code>
| Mad Bombers
|-
| <code>18</code>
| <code>o</code>
| Tomb Wader
|-
| <code>19</code>
| <code>p</code>
| Makin' Waves
|-
| <code>1A</code>
| <code>q</code>
| High Time
|-
| <code>1B</code>
| <code>r</code>
| Future Frenzy
|-
| <code>1C</code>
| <code>s</code>
| Deep Trouble
|-
| <code>1D</code>
| <code>t</code>
| Double Header
|-
| <code>1E</code>
| <code>u</code>
| Sphynxinator
|-
| <code>1F</code>
| <code>v</code>
| Rings of Power
|-
| <code>20</code>
| <code>w</code>
| Orange Asphalt
|-
| <code>21</code>
| <code>x</code>
| Ski Crazed
|-
| <code>22</code>
| <code>y</code>
| Flaming Passion
|-
| <code>23</code>
| <code>z</code>
| Future Frenzy
|-
| <code>24</code>
| <code>A</code>
| Bug Lite
|-
| <code>25</code>
| <code>B</code>
| Area 51?
|-
| <code>26</code>
| <code>C</code>
| Eggipus Rex
|-
| <code>27</code>
| <code>D</code>
| Hot Coco
|-
| <code>28</code>
| <code>E</code>
| Opening Cutscene (English and Japanese)
|-
| <code>29</code>
| <code>F</code>
| Any% Ending Cutscene
|-
| <code>2A</code>
| <code>G</code>
| 100% Ending Cutscene
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
| Opening Cutscene (Spanish, PAL only)
|-
| <code>2E</code>
| <code>K</code>
| Opening Cutscene (French, PAL only)
|-
| <code>2F</code>
| <code>L</code>
| Opening Cutscene (German, PAL only)
|-
| <code>30</code>
| <code>M</code>
| Opening Cutscene (Italian, PAL only)
|-
| <code>31</code>
| <code>N</code>
| Gone Tomorrow
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| Intermission Vortex
|-
| <code>3B</code>
| <code>X</code>
| Game Over Screen
|-
| <code>3C</code>
| <code>Y</code>
| Title Screen
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>v</code> (1F), ''Rings of Power'', appears in the S2 directory rather than S1.

Level ID

2019-04-27T19:39:06Z

Chekwob: /* Crash 2 */ Reword N/A to (none) for consistency with other tables

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.



== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| (none)
|-
| <code>03</code>
| <code>3</code>
| Cortex Power
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| Generator Room
|-
| <code>06</code>
| <code>6</code>
| Heavy Machinery
|-
| <code>07</code>
| <code>7</code>
| Toxic Waste
|-
| <code>08</code>
| <code>8</code>
| Pinstripe (Boss 4)
|-
| <code>09</code>
| <code>9</code>
| N. Sanity Beach
|-
| <code>0A</code>
| <code>a</code>
| Papu Papu (Boss 1)
|-
| <code>0B</code>
| <code>b</code>
| (none)
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| (none)
|-
| <code>0E</code>
| <code>e</code>
| Boulders
|-
| <code>0F</code>
| <code>f</code>
| Upstream
|-
| <code>10</code>
| <code>g</code>
| (none)
|-
| <code>11</code>
| <code>h</code>
| Hog Wild
|-
| <code>12</code>
| <code>i</code>
| The Great Gate
|-
| <code>13</code>
| <code>j</code>
| Boulder Dash
|-
| <code>14</code>
| <code>k</code>
| Road to Nowhere
|-
| <code>15</code>
| <code>l</code>
| Rolling Stones
|-
| <code>16</code>
| <code>m</code>
| The High Road
|-
| <code>17</code>
| <code>n</code>
| Ripper Roo (Boss 2)
|-
| <code>18</code>
| <code>o</code>
| Up The Creek
|-
| <code>19</code>
| <code>p</code>
| Map, Main Menu, Title Sequence
|-
| <code>1A</code>
| <code>q</code>
| Native Fortress
|-
| <code>1B</code>
| <code>r</code>
| Nitrus Brio (Boss 5)
|-
| <code>1C</code>
| <code>s</code>
| Temple Ruins
|-
| <code>1D</code>
| <code>t</code>
| Jaws of Darkness
|-
| <code>1E</code>
| <code>u</code>
| Whole Hog
|-
| <code>1F</code>
| <code>v</code>
| Dr. Neo Cortex (Boss 6)
|-
| <code>20</code>
| <code>w</code>
| The Lost City
|-
| <code>21</code>
| <code>x</code>
| Koala Kong (Boss 3)
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' Stormy Ascent
|-
| <code>23</code>
| <code>z</code>
| Sunset Vista
|-
| <code>24</code>
| <code>A</code>
| Bonus Round (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| Bonus Round (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| Bonus Round '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| (none)
|-
| <code>28</code>
| <code>E</code>
| Lights Out
|-
| <code>29</code>
| <code>F</code>
| The Lab
|-
| <code>2A</code>
| <code>G</code>
| Fumbling in the Dark
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| The Great Hall
|-
| <code>2D</code>
| <code>J</code>
| Level Completion Screen
|-
| <code>2E</code>
| <code>K</code>
| Slippery Climb
|-
| <code>2F</code>
| <code>L</code>
| (none)
|-
| <code>30</code>
| <code>M</code>
| (none)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| Bonus Round (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| Bonus Round (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| Castle Machinery
|-
| <code>38</code>
| <code>U</code>
| Intro
|-
| <code>39</code>
| <code>V</code>
| Ending
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
| (none)
|-
| <code>3C</code>
| <code>Y</code>
| (none)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| Test Area
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| Cavern Level
|-
| <code>0B</code>
| <code>b</code>
| Cliff Level
|-
| <code>0D</code>
| <code>d</code>
| Waterfall Level
|-
| <code>10</code>
| <code>g</code>
| 2D Donkey Kong
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).
{| class="wikitable"
!Hex
!#
!Level name
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
|English Warp Room
|-
| <code>03</code>
| <code>3</code>
|Tiny Tiger
|-
| <code>04</code>
| <code>4</code>
| (none)
|-
| <code>05</code>
| <code>5</code>
| (none)
|-
| <code>06</code>
| <code>6</code>
|Ripper Roo
|-
| <code>07</code>
| <code>7</code>
|Dr. Neo Cortex
|-
| <code>08</code>
| <code>8</code>
|Komodo Bros.
|-
| <code>09</code>
| <code>9</code>
|N. Gin
|-
| <code>0A</code>
| <code>a</code>
|Sewer or Later
|-
| <code>0B</code>
| <code>b</code>
| (none); Test jungle level (jungle1)
|-
| <code>0C</code>
| <code>c</code>
|Night Fight
|-
| <code>0D</code>
| <code>d</code>
|Hangin' Out
|-
| <code>0E</code>
| <code>e</code>
|Snow Go
|-
| <code>0F</code>
| <code>f</code>
|Ruination
|-
| <code>10</code>
| <code>g</code>
|Piston it Away
|-
| <code>11</code>
| <code>h</code>
|Snow Biz
|-
| <code>12</code>
| <code>i</code>
|Rock It
|-
| <code>13</code>
| <code>j</code>
|Cold Hard Crash
|-
| <code>14</code>
| <code>k</code>
| (none)
|-
| <code>15</code>
| <code>l</code>
|Diggin' It
|-
| <code>16</code>
| <code>m</code>
|Road to Ruin
|-
| <code>17</code>
| <code>n</code>
|Un-Bearable
|-
| <code>18</code>
| <code>o</code>
|Crash Dash
|-
| <code>19</code>
| <code>p</code>
|Hang Eight
|-
| <code>1A</code>
| <code>q</code>
|Pack Attack
|-
| <code>1B</code>
| <code>r</code>
|Crash Crush
|-
| <code>1C</code>
| <code>s</code>
|Intro
|-
| <code>1D</code>
| <code>t</code>
|Bear It
|-
| <code>1E</code>
| <code>u</code>
|Turtle Woods
|-
| <code>1F</code>
| <code>v</code>
|The Pits
|-
| <code>20</code>
| <code>w</code>
|Air Crash
|-
| <code>21</code>
| <code>x</code>
|Plant Food
|-
| <code>22</code>
| <code>y</code>
|Bear Down
|-
| <code>23</code>
| <code>z</code>
|The Eel Deal
|-
| <code>24</code>
| <code>A</code>
|Bee-Having
|-
| <code>25</code>
| <code>B</code>
|Totally Bear
|-
| <code>26</code>
| <code>C</code>
|Spaced Out
|-
| <code>27</code>
| <code>D</code>
|Totally Fly
|-
| <code>28</code>
| <code>E</code>
|100% Ending
|-
| <code>29</code>
| <code>F</code>
|Normal Ending
|-
| <code>2A</code>
| <code>G</code>
| (none)
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
|Spanish Warp Room (PAL only)
|-
| <code>2E</code>
| <code>K</code>
|French Warp Room (PAL only)
|-
| <code>2F</code>
| <code>L</code>
|German Warp Room (PAL only)
|-
| <code>30</code>
| <code>M</code>
|Italian Warp Room (PAL only)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
|Game Over Screen
|-
| <code>3C</code>
| <code>Y</code>
|Title Screen
|}

== Crash 3 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| Warp Room (English or Japanese)
|-
| <code>03</code>
| <code>3</code>
| Dingodile (Boss 2)
|-
| <code>04</code>
| <code>4</code>
| N. Tropy (Boss 3)
|-
| <code>05</code>
| <code>5</code>
| N. Gin (Boss 4)
|-
| <code>06</code>
| <code>6</code>
| Tiny (Boss 1)
|-
| <code>07</code>
| <code>7</code>
| Dr. Neo Cortex (Boss 5)
|-
| <code>08</code>
| <code>8</code>
| (none)
|-
| <code>09</code>
| <code>9</code>
| (none)
|-
| <code>0A</code>
| <code>a</code>
| Orient Express
|-
| <code>0B</code>
| <code>b</code>
| Toad Village
|-
| <code>0C</code>
| <code>c</code>
| Bone Yard
|-
| <code>0D</code>
| <code>d</code>
| Tell No Tales
|-
| <code>0E</code>
| <code>e</code>
| Under Pressure
|-
| <code>0F</code>
| <code>f</code>
| Gee Wiz
|-
| <code>10</code>
| <code>g</code>
| Dino Might!
|-
| <code>11</code>
| <code>h</code>
| Midnight Run
|-
| <code>12</code>
| <code>i</code>
| Tomb Time
|-
| <code>13</code>
| <code>j</code>
| Bye Bye Blimps
|-
| <code>14</code>
| <code>k</code>
| Road Crash
|-
| <code>15</code>
| <code>l</code>
| Hog Ride
|-
| <code>16</code>
| <code>m</code>
| Hang'em High
|-
| <code>17</code>
| <code>n</code>
| Mad Bombers
|-
| <code>18</code>
| <code>o</code>
| Tomb Wader
|-
| <code>19</code>
| <code>p</code>
| Makin' Waves
|-
| <code>1A</code>
| <code>q</code>
| High Time
|-
| <code>1B</code>
| <code>r</code>
| Future Frenzy
|-
| <code>1C</code>
| <code>s</code>
| Deep Trouble
|-
| <code>1D</code>
| <code>t</code>
| Double Header
|-
| <code>1E</code>
| <code>u</code>
| Sphynxinator
|-
| <code>1F</code>
| <code>v</code>
| Rings of Power
|-
| <code>20</code>
| <code>w</code>
| Orange Asphalt
|-
| <code>21</code>
| <code>x</code>
| Ski Crazed
|-
| <code>22</code>
| <code>y</code>
| Flaming Passion
|-
| <code>23</code>
| <code>z</code>
| Future Frenzy
|-
| <code>24</code>
| <code>A</code>
| Bug Lite
|-
| <code>25</code>
| <code>B</code>
| Area 51?
|-
| <code>26</code>
| <code>C</code>
| Eggipus Rex
|-
| <code>27</code>
| <code>D</code>
| Hot Coco
|-
| <code>28</code>
| <code>E</code>
| Opening Cutscene (English and Japanese)
|-
| <code>29</code>
| <code>F</code>
| Any% Ending Cutscene
|-
| <code>2A</code>
| <code>G</code>
| 100% Ending Cutscene
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
| Opening Cutscene (Spanish, PAL only)
|-
| <code>2E</code>
| <code>K</code>
| Opening Cutscene (French, PAL only)
|-
| <code>2F</code>
| <code>L</code>
| Opening Cutscene (German, PAL only)
|-
| <code>30</code>
| <code>M</code>
| Opening Cutscene (Italian, PAL only)
|-
| <code>31</code>
| <code>N</code>
| Gone Tomorrow
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| Intermission Vortex
|-
| <code>3B</code>
| <code>X</code>
| Game Over Screen
|-
| <code>3C</code>
| <code>Y</code>
| Title Screen
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>v</code> (1F), ''Rings of Power'', appears in the S2 directory rather than S1.

Main Page

2019-04-27T18:05:39Z

Chekwob: Removed the table of contents

Here you will find a number of in-depth guides detailing the inner-workings of the [[w:c:retro-crash|Crash Bandicoot]] game engine. These guides are not official in any way.
__NOTOC__

==Start Here==
* [[CD-ROM Directory Structure]]
* [[Entry point]]
* [[Game Loop]]
* [[Paging and Subsystem Initialization]]
* [[Subsystem|Subsystems]]

== Reference ==

=== General ===
* [[Memory Map]]
* [[Level ID|List of Level ID's]]
* [[List of game discs|List of Game Discs]]

=== Formats ===
==== Files ====
* [[NSD]]
* [[NSF]]
** [[Chunk]]
** [[Entry]]
* [[SYSTEM.CNF]]
* [[PSX.EXE]] (also SCUS_xxx.xx, SCES_xxx.xx, etc)
* [[WARP.BIN]] (also WARPSCUS.BIN, WARPSCES.BIN, etc)

==== Entries ====
{| class="wikitable" style="text-align: center"
! Dec
! Hex
! style="width: 4em"| Crash 1
! style="width: 4em"| Crash 2
! style="width: 4em"| Crash 3
!
|-
! colspan="2"| 1
| colspan="3"| SVTX
| style="text-align: left"| (no page)
|-
! colspan="2"| 2
| colspan="3"| TGEO
| style="text-align: left"| (no page)
|-
! colspan="2"| 3
| colspan="3"| WGEO
| style="text-align: left"| [[World]]
|-
! colspan="2"| 4
| colspan="3"| SLST
| style="text-align: left"| [[Sort List]]
|-
! colspan="2"| 5
| colspan="3"| TPAG
| style="text-align: left"| (no page)
|-
| colspan="6"|
|-
! colspan="2"| 7
| colspan="3"| ZDAT
| style="text-align: left"| [[Zone]]
|-
| colspan="6"|
|-
! 11
! Bh
| colspan="3"| GOOL
| style="text-align: left"| [[GOOL Executable]]
|-
! 12
! Ch
| colspan="3"| ADIO
| style="text-align: left"| (no page)
|-
! 13
! Dh
| colspan="3"| MIDI
| style="text-align: left"| (no page)
|-
! 14
! Eh
| colspan="3"| INST
| style="text-align: left"| (no page)
|-
! rowspan="2"| 15
! rowspan="2"| Fh
| IMAG
| colspan="2"|
| style="text-align: left"| (no page)
|-
|
| colspan="2"| VCOL
| style="text-align: left"| (no page)
|-
| colspan="6"|
|-
! rowspan="2"| 17
! rowspan="2"| 11h
| MDAT
| colspan="2"|
| style="text-align: left"| (no page)
|-
| colspan="2"|
| RAWD
| style="text-align: left"| (no page)
|-
! 18
! 12h
| IPAL
| colspan="2"|
| style="text-align: left"| (no page)
|-
! 19
! 13h
| colspan="3"| PBAK
| style="text-align: left"| (no page)
|-
! rowspan="2"| 20
! rowspan="2"| 14h
| CVTX
| colspan="2"|
| style="text-align: left"| (no page)
|-
|
| colspan="2"| SDIO
| style="text-align: left"| (no page)
|-
! 21
! 15h
|
| colspan="2"| VIDO
| style="text-align: left"| (no page)
|-
|}

==== Structures ====
* [[Object]]

==== Other ====
* [[ISO 9660]]
* [[CD-XA]] (Mode 2 for CD tracks, used by the PlayStation)

List of game discs

2019-04-27T18:05:25Z

Chekwob: Add borders to the disc ID tables

== Release discs ==

=== Crash 1 ===
{|class="wikitable"
! Disc ID
! Region
|-
| [[SCUS-94900]]
| NTSC-U/C
|-
| [[SCES-00344]]
| PAL
|-
| [[SCPS-10031]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91057.

=== Crash 2 ===
{|class="wikitable"
! Disc ID
! Region
|-
| [[SCUS-94154]]
| NTSC-U/C
|-
| [[SCES-00967]]
| PAL
|-
| [[SCPS-10047]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91092.

=== Crash 3 ===
{|class="wikitable"
! Disc ID
! Region
|-
| [[SCUS-94244]]
| NTSC-U/C
|-
| [[SCES-01420]]
| PAL
|-
| [[SCPS-10073]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91164 and SCPS-91318.

== Prerelease discs ==
(stub)

== Demo discs ==

{|class="wikitable"
! Disc ID
! Region
! Name
|-
| [[PBPX-95007]]
| PAL
| Demo One EUROPE
|-
| [[PBPX-95008]]
| PAL
| Demo One EUROPE
|-
| [[SCED-00273]]
| PAL
| Autumn/Christmas Releases
|-
| [[SCED-00364]]
| PAL
| Crash Bandicoot / Supersonic Racers / Die Hard Trilogy / Broken Sword / F1
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00457]]
| PAL
| Demo One german
|-
| [[SCED-00678]]
| PAL
| Euro Demo 13 GER
|-
| [[SCED-00777]]
| PAL
| Euro Demo 14 FRE
|-
| [[SCED-00823]]
| PAL
| Euro Demo 27
|-
| [[SCED-00936]]
| PAL
| Registered User Demo 02
|-
| [[SCED-00938]]
| PAL
| Essential Playstation IV
|-
| [[SCED-00986]]
| PAL
| Winter Releases - '97 demo 01
|-
| [[SCED-01049]]
| PAL
| Playstation Sampler / Nightmare Creatures / Kurushi / Rapid Racer / ...
|-
| [[SCED-01118]]
| PAL
| Euro Demo 25 fra
|-
| [[SCED-01120]]
| PAL
| Euro Demo 27 fra
|-
| [[SCED-01127]]
| PAL
| Euro Demo 10/98 ger
|-
| [[SCED-01128]]
| PAL
| Euro Demo 11/98 ger
|-
| [[SCED-01129]]
| PAL
| Euro Demo 12/98 ger
|-
| [[SCED-01139]]
| PAL
| Essential Playstation VIII
|-
| [[SCED-01141]]
| PAL
| Essential Playstation X
|-
| [[SCED-01148]]
| PAL
| Euro Demo 38
|-
| [[SCED-01150]]
| PAL
| Euro Demo 40
|-
| [[SCED-01229]]
| PAL
| PlayStation Kids
|-
| [[SCED-01230]]
| PAL
| Registered Users Demo 03
|-
| [[SCED-01385]]
| PAL
| Registered Users Demo
|-
| [[SCED-01441]]
| PAL
| Winter Releases '98
|-
| [[SCED-01570]]
| PAL
| Australian Summer Special
|-
| [[SCED-01636]]
| PAL
| Registered Users Demo
|-
| [[SCED-01713]]
| PAL
| M-6 PlayStation Demo fre
|-
| [[SCED-01739]]
| PAL
| Katalog Spezial Demo ger
|-
| [[SCED-01828]]
| PAL
| Euro Demo 54
|-
| [[SCED-01837]]
| PAL
| Euro Demo 06/99 GER
|-
| [[SCED-01860]]
| PAL
| Euro Demo 40 FRA
|-
| [[SCED-01861]]
| PAL
| Euro Demo 41 FRA
|-
| [[SCED-01988]]
| PAL
| Registered Users Demo 06
|-
| [[SCED-02122]]
| PAL
| OPSM Platinum Special Demo (All)
|-
| [[SCED-02327]]
| PAL
| The Best Games Ever
|-
| [[SCED-02570]]
| PAL
| M6 PlayStation - Best Of Kids Demo
|-
| [[SCED-02655]]
| PAL
| Euro Demo (France) 51
|-
| [[SCED-02851]]
| PAL
| OPSM Best Ever Ever Games Demo
|-
| [[SCED-03103]]
| PAL
| PlayStation Speziale Italia
|-
| [[SCED-03452]]
| PAL
| Euro Demo 75
|-
| [[SCED-03454]]
| PAL
| OPSM Demo 77
|-
| [[SCED-03472]]
| PAL
| Euro Demo Germany 09/01 Deutsch
|-
| [[SCED-03473]]
| PAL
| Euro Demo Germany 10/01 Deutsch
|-
| [[SCED-03790]]
| PAL
| Official PlayStation Magazine 87 EUR
|-
| [[SCED-03791]]
| PAL
| Official PlayStation Magazine 88 EUR
|-
| [[SCED-03905]]
| PAL
| Euro Demo (Germany) 03/04-2003
|-
| [[SCED-04076]]
| PAL
| Euro Demo (Future) 97
|-
| [[SCED-04077]]
| PAL
| Euro Demo (Future) 98
|-
| [[SLED-01633]]
| PAL
| PlayStation Zone CD Vol. 1
|-
| [[SLED-01724]]
| PAL
| PlayStation Zone CD Vol. 2
|-
| [[SLED-01773]]
| PAL
| PlayStation Zone CD Vol. 3
|-
| [[SLED-01783]]
| PAL
| PlayStation Zone CD Vol. 4
|-
| [[SLED-01898]]
| PAL
| PlayStation Zone CD Vol. 5
|-
| [[SLED-02042]]
| PAL
| PlayStation Zone CD Vol. 7
|-
| [[SLED-02078]]
| PAL
| PlayStation Zone CD Vol. 8
|-
| [[SLED-02139]]
| PAL
| PlayStation Zone CD Vol. 9
|}

Main Page

2019-04-27T17:50:01Z

Chekwob: Remove wikia garbage

Here you will find a number of in-depth guides detailing the inner-workings of the [[w:c:retro-crash|Crash Bandicoot]] game engine. These guides are not official in any way.

==Start Here==
* [[CD-ROM Directory Structure]]
* [[Entry point]]
* [[Game Loop]]
* [[Paging and Subsystem Initialization]]
* [[Subsystem|Subsystems]]

== Reference ==

=== General ===
* [[Memory Map]]
* [[Level ID|List of Level ID's]]
* [[List of game discs|List of Game Discs]]

=== Formats ===
==== Files ====
* [[NSD]]
* [[NSF]]
** [[Chunk]]
** [[Entry]]
* [[SYSTEM.CNF]]
* [[PSX.EXE]] (also SCUS_xxx.xx, SCES_xxx.xx, etc)
* [[WARP.BIN]] (also WARPSCUS.BIN, WARPSCES.BIN, etc)

==== Entries ====
{| class="wikitable" style="text-align: center"
! Dec
! Hex
! style="width: 4em"| Crash 1
! style="width: 4em"| Crash 2
! style="width: 4em"| Crash 3
!
|-
! colspan="2"| 1
| colspan="3"| SVTX
| style="text-align: left"| (no page)
|-
! colspan="2"| 2
| colspan="3"| TGEO
| style="text-align: left"| (no page)
|-
! colspan="2"| 3
| colspan="3"| WGEO
| style="text-align: left"| [[World]]
|-
! colspan="2"| 4
| colspan="3"| SLST
| style="text-align: left"| [[Sort List]]
|-
! colspan="2"| 5
| colspan="3"| TPAG
| style="text-align: left"| (no page)
|-
| colspan="6"|
|-
! colspan="2"| 7
| colspan="3"| ZDAT
| style="text-align: left"| [[Zone]]
|-
| colspan="6"|
|-
! 11
! Bh
| colspan="3"| GOOL
| style="text-align: left"| [[GOOL Executable]]
|-
! 12
! Ch
| colspan="3"| ADIO
| style="text-align: left"| (no page)
|-
! 13
! Dh
| colspan="3"| MIDI
| style="text-align: left"| (no page)
|-
! 14
! Eh
| colspan="3"| INST
| style="text-align: left"| (no page)
|-
! rowspan="2"| 15
! rowspan="2"| Fh
| IMAG
| colspan="2"|
| style="text-align: left"| (no page)
|-
|
| colspan="2"| VCOL
| style="text-align: left"| (no page)
|-
| colspan="6"|
|-
! rowspan="2"| 17
! rowspan="2"| 11h
| MDAT
| colspan="2"|
| style="text-align: left"| (no page)
|-
| colspan="2"|
| RAWD
| style="text-align: left"| (no page)
|-
! 18
! 12h
| IPAL
| colspan="2"|
| style="text-align: left"| (no page)
|-
! 19
! 13h
| colspan="3"| PBAK
| style="text-align: left"| (no page)
|-
! rowspan="2"| 20
! rowspan="2"| 14h
| CVTX
| colspan="2"|
| style="text-align: left"| (no page)
|-
|
| colspan="2"| SDIO
| style="text-align: left"| (no page)
|-
! 21
! 15h
|
| colspan="2"| VIDO
| style="text-align: left"| (no page)
|-
|}

==== Structures ====
* [[Object]]

==== Other ====
* [[ISO 9660]]
* [[CD-XA]] (Mode 2 for CD tracks, used by the PlayStation)

Main Page

2019-04-27T17:46:38Z

Chekwob: Chekwob moved page Crash Bandicoot Hacking Wikia to Main Page: Move back to legitimate main page from wikia garbage page

<mainpage-leftcolumn-start />
{{maitop}}
Here you will find a number of in-depth guides detailing the inner-workings of the [[w:c:retro-crash|Crash Bandicoot]] game engine. These guides are not official in any way.

==Start Here==
* [[CD-ROM Directory Structure]]
* [[Entry point]]
* [[Game Loop]]
* [[Paging and Subsystem Initialization]]
* [[Subsystem|Subsystems]]

== Reference ==

=== General ===
* [[Memory Map]]
* [[Level ID|List of Level ID's]]
* [[List of game discs|List of Game Discs]]

=== Formats ===
==== Files ====
* [[NSD]]
* [[NSF]]
** [[Chunk]]
** [[Entry]]
* [[SYSTEM.CNF]]
* [[PSX.EXE]] (also SCUS_xxx.xx, SCES_xxx.xx, etc)
* [[WARP.BIN]] (also WARPSCUS.BIN, WARPSCES.BIN, etc)

==== Entries ====
{| class="wikitable" style="text-align: center"
! Dec
! Hex
! style="width: 4em"| Crash 1
! style="width: 4em"| Crash 2
! style="width: 4em"| Crash 3
!
|-
! colspan="2"| 1
| colspan="3"| SVTX
| style="text-align: left"| (no page)
|-
! colspan="2"| 2
| colspan="3"| TGEO
| style="text-align: left"| (no page)
|-
! colspan="2"| 3
| colspan="3"| WGEO
| style="text-align: left"| [[World]]
|-
! colspan="2"| 4
| colspan="3"| SLST
| style="text-align: left"| [[Sort List]]
|-
! colspan="2"| 5
| colspan="3"| TPAG
| style="text-align: left"| (no page)
|-
| colspan="6"|
|-
! colspan="2"| 7
| colspan="3"| ZDAT
| style="text-align: left"| [[Zone]]
|-
| colspan="6"|
|-
! 11
! Bh
| colspan="3"| GOOL
| style="text-align: left"| [[GOOL Executable]]
|-
! 12
! Ch
| colspan="3"| ADIO
| style="text-align: left"| (no page)
|-
! 13
! Dh
| colspan="3"| MIDI
| style="text-align: left"| (no page)
|-
! 14
! Eh
| colspan="3"| INST
| style="text-align: left"| (no page)
|-
! rowspan="2"| 15
! rowspan="2"| Fh
| IMAG
| colspan="2"|
| style="text-align: left"| (no page)
|-
|
| colspan="2"| VCOL
| style="text-align: left"| (no page)
|-
| colspan="6"|
|-
! rowspan="2"| 17
! rowspan="2"| 11h
| MDAT
| colspan="2"|
| style="text-align: left"| (no page)
|-
| colspan="2"|
| RAWD
| style="text-align: left"| (no page)
|-
! 18
! 12h
| IPAL
| colspan="2"|
| style="text-align: left"| (no page)
|-
! 19
! 13h
| colspan="3"| PBAK
| style="text-align: left"| (no page)
|-
! rowspan="2"| 20
! rowspan="2"| 14h
| CVTX
| colspan="2"|
| style="text-align: left"| (no page)
|-
|
| colspan="2"| SDIO
| style="text-align: left"| (no page)
|-
! 21
! 15h
|
| colspan="2"| VIDO
| style="text-align: left"| (no page)
|-
|}

==== Structures ====
* [[Object]]

==== Other ====
* [[ISO 9660]]
* [[CD-XA]] (Mode 2 for CD tracks, used by the PlayStation)

==Latest activity==

<activityfeed/>

<mainpage-endcolumn />

<mainpage-rightcolumn-start />

Photos and videos are a great way to add visuals to your wiki. Find videos about your topic by exploring Wikia's [[w:c:video|Video Library]].

[[File:Placeholder|298px]]
<mainpage-endcolumn />
[[Category:Browse]]

Crash Bandicoot Hacking Wikia

2019-04-27T17:46:38Z

Chekwob: Chekwob moved page Crash Bandicoot Hacking Wikia to Main Page: Move back to legitimate main page from wikia garbage page

#REDIRECT [[Main Page]]

Zone

2019-04-27T17:44:41Z

Chekwob: 12 revisions imported: Initial import from Wikia

A Crash level is composed of invisible ''zones''. Each zone is a cubic region of 3 dimensional space, with dimensions (width, height, depth) and unique location/position, within its containing level. The space occupied by a zone approximately encompasses [the evidently interactive portions of] up to 8 worlds. All together as a whole, a level's zones encompass all of the apparently interactive space occupied by its worlds and any additional surrounding 'atmosphere'; this complete enclosure defines the approximate boundaries for the entire level.

== Description ==
In an instance of a Crash game, when initially entering a level, the player character (Crash/Willie) is spawned at a specific location within the level's ''first zone''-(i.e. its ''initial entry point''). At this point, the worlds encompassed by the zone, and possibly other nearby worlds, are visible to the player, and the player character is typically in a location where it appears to be supported by some aspect of the worlds-usually terrain. The player is now free to complete one or more level objectives for furthering its overall game progress.

In a Crash 1 [non-boss] level, the player's primary objective is to progress towards and ultimately reach the goal-i.e. the warp platform located at the end. Crash 2 and 3 extend this objective by requiring that the crystal be collected at some point along the path to the goal. Together, the zones provide the play area through which the player is to roam towards its goal. The player progresses from zone to zone, encountering various obstacles along the way, until it either reaches the goal, or dies in its pursuit.

TBD: introduction for header, dimensions/collision octree, camera paths, and entities

==Format==

===Item 1: Header===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|World Count
|4 bytes
|w
|-
|0x4
|Reserved for World Models
|8 x 0x40 bytes
|*
|-
|0x204
|Index of First Camera Path Item
|4 bytes
|h
|-
|0x208
|Camera Path Count
|4 bytes
|c
|-
|0x20C
|Entity Count
|4 bytes
|e
|-
|0x210
|Neighbor Zone Count
|4 bytes
|n
|-
|0x214
|Neighbor Zone EIDs
|8 x 4 bytes
|*
|-
|0x234
|Texture Page Entry Count
|4 bytes
|p
|-
|0x238
|"Obligatory" Chunk CID Count
|4 bytes
|t
|-
|0x23C
|Texture Page Entry EIDs
|8 x 4 bytes
|*
|-
|0x25C
|Chunk CIDs
|32 x 4 bytes
|*
|-
|0x2DC
|Zone Spawn Flags
|4 bytes
|*
|-
|0x2E0
|VRAM Fill Height for clearing draw buffer
|4 bytes
|*
|-
|0x2E4
|unknown
|4 bytes
|*
|-
|0x2E8
|Draw distance (affects fog) - note that objects that are not "drawn" thanks to this will still be processed
|4 bytes
|*
|-
|0x2EC
|unknown (affects the way objects are drawn)
|4 bytes
|*
|-
|0x2F0
|unknown
|4 bytes
|*
|-
|0x2F4
|unknown
|4 bytes
|*
|-
|0x2F8
|unknown
|4 bytes
|*
|-
|0x2FC
|Zone Flags
|4 bytes
|*
|-
|0x300
|Max Death Height? Max Water Height?
|4 bytes
|*
|-
|0x304
|unknown
|4 bytes
|*
|-
|0x308
|unknown
|4 bytes
|*
|-
|0x30C
|unknown; see sub_260AC
|4 bytes
|*
|-
|0x310
|VRAM Clear Color R
|1 byte
|*
|-
|0x311
|VRAM Clear Color G
|1 byte
|*
|-
|0x312
|VRAM Clear Color B
|1 byte
|*
|-
|0x313
|unused
|1 byte
|*
|-
|0x314
|Music entry reference
|4 bytes
|*
|-
|0x318
|Background Color 1 (R/G/B/?)
|4 bytes
|*
|-
|0x31C
|Background Color 2 (R/G/B/?)
|4 bytes
|*
|-
|0x320
|Background Color 3 (R/G/B/?)
|4 bytes
|*
|-
|0x324
|Fog Color (R/G/B/?)
|4 bytes
|*
|-
|0x328
|Object Light Source Matrix L33
|2 bytes
|*
|-
|0x32A
|Object Background Color R
|2 bytes
|*
|-
|0x32C
|Object Background Color G
|2 bytes
|*
|-
|0x32E
|Object Background Color B
|2 bytes
|*
|-
|0x330
|Object Light Color Matrix LR1
|2 bytes
|*
|-
|0x332
|Object Light Color Matrix LR2
|2 bytes
|*
|-
|0x334
|Object Light Color Matrix LR3
|2 bytes
|*
|-
|0x336
|Object Light Color Matrix LG1
|2 bytes
|*
|-
|0x338
|Object Light Color Matrix LG2
|2 bytes
|*
|-
|0x33A
|Object Light Color Matrix LG3
|2 bytes
|*
|-
|0x33C
|Object Light Color Matrix LB1
|2 bytes
|*
|-
|0x33E
|Object Light Color Matrix LB2
|2 bytes
|*
|-
|0x340
|Object Light Color Matrix LB3
|2 bytes
|*
|-
|0x342
|Object Background Color Intensity R
|2 bytes
|*
|-
|0x344
|Object Background Color Intensity G
|2 bytes
|*
|-
|0x346
|Object Background Color Intensity B
|2 bytes
|*
|-
|0x348
|Player Light Source Matrix L11
|2 bytes
|*
|-
|0x34A
|Player Light Source Matrix L12
|2 bytes
|*
|-
|0x34C
|Player Light Source Matrix L13
|2 bytes
|*
|-
|0x34E
|Player Light Source Matrix L21
|2 bytes
|*
|-
|0x350
|Player Light Source Matrix L22
|2 bytes
|*
|-
|0x352
|Player Light Source Matrix L23
|2 bytes
|*
|-
|0x354
|Player Light Source Matrix L31
|2 bytes
|*
|-
|0x356
|Player Light Source Matrix L32
|2 bytes
|*
|-
|0x358
|Player Light Source Matrix L33
|2 bytes
|*
|-
|0x35A
|Player Background Color R
|2 bytes
|*
|-
|0x35C
|Player Background Color G
|2 bytes
|*
|-
|0x35E
|Player Background Color B
|2 bytes
|*
|-
|0x360
|Player Light Color Matrix LR1
|2 bytes
|*
|-
|0x362
|Player Light Color Matrix LR2
|2 bytes
|*
|-
|0x364
|Player Light Color Matrix LR3
|2 bytes
|*
|-
|0x366
|Player Light Color Matrix LG1
|2 bytes
|*
|-
|0x368
|Player Light Color Matrix LG2
|2 bytes
|*
|-
|0x36A
|Player Light Color Matrix LG3
|2 bytes
|*
|-
|0x36C
|Player Light Color Matrix LB1
|2 bytes
|*
|-
|0x36E
|Player Light Color Matrix LB2
|2 bytes
|*
|-
|0x370
|Player Light Color Matrix LB3
|2 bytes
|*
|-
|0x372
|Player Background Color Intensity R
|2 bytes
|*
|-
|0x374
|Player Background Color Intensity G
|2 bytes
|*
|-
|0x376
|Player Background Color Intensity B
|2 bytes
|*
|}

===Item 2: Dimensions/Collision Octree===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Zone Location X
|4 bytes
|*
|-
|0x4
|Zone Location Y
|4 bytes
|*
|-
|0x8
|Zone Location Z
|4 bytes
|*
|-
|0xC
|Zone Width
|4 bytes
|*
|-
|0x10
|Zone Height
|4 bytes
|*
|-
|0x14
|Zone Depth
|4 bytes
|*
|-
|0x18
|unknown
|4 bytes
|*
|-
| colspan="4" |Collision Octree
|-
|0x1C
|Root Node Index
|2 bytes
|*
|-
|0x1E
|Maximum Depth X
|2 bytes
|*
|-
|0x20
|Maximum Depth Y
|2 bytes
|*
|-
|0x22
|Maximum Depth Z
|2 bytes
|*
|-
|0x24
|Octree Nodes
|* x 2 bytes
|*
|}

===Item 3+n: Camera Path===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|[Polygon] Sort List EID
|4 bytes
|*
|-
|0x4
|Reserved for pointer to parent zone (entry)
|4 bytes
|garbage?
|-
|0x8
|Neighboring Path Count
|4 bytes
|*
|-
|0xC
|Neighboring Paths
|4 x 4 x 1 byte
|*
|-
| colspan="4" |Neighbor Path Structure ''d''
|-
|0xC + (''d ''x 4) +0x0
|Relation [to ''this ''path]
|1 byte
|*
|-
|0xC + (''d ''x 4) +0x1
|Parent Zone Index [in neighbor zone list]
|1 byte
|*
|-
|0xC + (''d ''x 4) +0x2
|Path Item Index
|1 byte
|*
|-
|0xC + (''d ''x 4) +0x3
|Relation to Goal/Misc Flag
|1 byte
|*
|-
| colspan="4" |end
|-
|0x1C
|Rel. Index of Entry Point [furthest from goal]
|1 byte
|*
|-
|0x1D
|Rel. Index of Exit Point [closest to goal]
|1 byte
|*
|-
|0x1E
|Path Length/Point Count
|2 bytes
|L
|-
|0x20
|Camera Mode
|2 bytes
|*
|-
|0x22
|Average Distance b/t Consecutive Path Points
|2 bytes
|*
|-
|0x24
|Camera Z Zoom/Y Pan Factor
|2 bytes
|*
|-
|0x26
|unknown
|2 bytes
|*
|-
|0x28
|unknown
|2 bytes
|*
|-
|0x2A
|unknown
|2 bytes
|*
|-
|0x2C
|Path Direction X
|2 bytes
|*
|-
|0x2E
|Path Direction Y
|2 bytes
|*
|-
|0x30
|Path Direction Z
|2 bytes
|*
|-
|0x32
|Camera Path Points
|L x 12 bytes
|*
|-
| colspan="4" |Camera Path Point Structure ''p ''(*point/trans location relative to parent zone location)
|-
|0x32 + (''p ''x 12) + 0x0
|Point X/Camera Trans X
|2 bytes
|*
|-
|0x32 + (''p'' x 12) + 0x2
|Point Y/Camera Trans Y
|2 bytes
|*
|-
|0x32 + (''p ''x 12) + 0x4
|Point Z/Camera Trans Z
|2 bytes
|*
|-
|0x32 + (''p ''x 12) + 0x6
|Camera Rotation X
|2 bytes
|*
|-
|0x32 + (''p ''x 12) + 0x8
|Camera Rotation Y
|2 bytes
|*
|-
|0x32 + (''p ''x 12) + 0xA
|Camera Rotation Z
|2 bytes
|*
|}

===Item 3+c+n: Entity===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Reserved for pointer to parent zone (entry)
|4 bytes
|garbage?
|-
|0x4
|Spawn Configuration Flags
|2 bytes
|*
|-
|0x6
|Object Process Type
|2 bytes
|*
|-
|0x8
|ID
|2 bytes
|*
|-
|0xA
|Path Point Count
|2 bytes
|L
|-
|0xC
|Mode Flags A (or initial Y rot)
|2 bytes
|*
|-
|0xE
|Mode Flags B (or initial X rot)
|2 bytes
|*
|-
|0x10
|Mode Flags C (or initial Z rot)
|2 bytes
|*
|-
|0x12
|Object Type
|1 byte
|*
|-
|0x13
|Object Subtype
|1 byte
|*
|-
|0x14
|Object Path Points
|L x 6 bytes
|*
|-
| colspan="4" |Object Path Point Structure ''p''
|-
|0x14 + (''p ''x 6) + 0x0
|Point X
|2 bytes
|*
|-
|0x14 + (''p ''x 6) + 0x2
|Point Y
|2 bytes
|*
|-
|0x14 + (''p ''x 6) + 0x4
|Point Z
|2 bytes
|*
|-
| colspan="4" |end
|-
|-
|0x14 + (L x 6)
|unknown?
|2 bytes if L = 1, otherwise 4
|0x0
|}

== Structure ==
TBD: zonecollisions, entity
<syntaxhighlight lang="cpp">
struct zoneheader
{
unsigned long worldcount;
wgeomodel world[8];
unsigned long headercount;
unsigned long campathcount;
unsigned long entitycount;
unsigned long neighborcount;
union
{
entry *neighbor[8];
unsigned long neighboreid[8];
};
unsigned long tpagecount;
unsigned long tchunkcount;
unsigned long tpage[8];
unsigned long tchunk[32];
unsigned long loadflags;
unsigned long vramfillh;
unsigned long unknownA;
unsigned long visibilitydepth;
unsigned long unknownB;
unsigned long unknownC;
unsigned long unknownD;
unsigned long unknownE;
unsigned long flags;
unsigned long deathy;
unsigned long unknownF;
unsigned long unknownG;
unsigned long unknownH;
unsigned char vramfillr;
unsigned char vramfillg;
unsigned char vramfillb;
unsigned char unused_a;
unsigned char farcolorr;
unsigned char farcolorg;
unsigned char farcolorb;
unsigned char unused_b;
struct slightmatrix objectlightmatrix;
struct scolor objectcolor;
struct scolormatrix objectcolormatrix;
struct scolor objectlightintensity;
struct slightmatrix playerlightmatrix;
struct scolor playercolor;
struct scolormatrix playercolormatrix;
struct scolor playerlightintensity;
};

struct zonepathdescriptor
{
unsigned char relation;
unsigned char neighborzoneindex;
unsigned char campathindex;
unsigned char goal;
};

struct zonecampathpoint
{
signed short x;
signed short y;
signed short z;
signed short rotx;
signed short roty;
signed short rotz;
};

struct zonecampath
{
unsigned long slsteid;
union
{
entry *parentzone;
unsigned long parentzoneeid;
}
unsigned long neighborpathcount;
struct zonepathdescriptor neighborpathdescriptor[4];
unsigned char entranceindex;
unsigned char exitindex;
unsigned short length;
unsigned short cammode;
signed short avgptdist;
signed short camzoom;
unsigned short unknownA;
unsigned short unknownB;
unsigned short unknownC;
struct svector direction;
struct zonecampathpoint point[];
};
</syntaxhighlight>

== Zone Dimensions/Collision Octree ==
=== Collision Octree ===
Each node in the zone's collision octree, except for the root node, is the child of a parent node. Each parent node has either 8, 4, or 2 children nodes.

Each node corresponds to a portion of 3-dimensional space occupied by the zone. The root node corresponds to the entire region of space occupied by the zone (specified at offsets 0x0 to 0x14). Each child node corresponds to a separate subdivision of the space occupied by its parent. The location and dimensions of a subdivision respectively vary based on the corresponding node's index among its siblings and its depth within the tree.

In relation to its corresponding node's parent's associated region of space, a subdivision can be any region resulting from an even partitioning by any combination of 1 to 3 coordinate axis-aligned hyperplanes:
* Upper left front, upper left back, lower left front, lower left back, upper right front, upper right back, lower right front, or lower right back octant
* Upper left, Lower left, Upper right, Lower right, Front left, Back left, Front right, Back right, Upper front, Upper back, Lower front, or Lower back quadrant
* Left, right, top, bottom, front, or back half
Thus, if a node's parent's associated region of space were split in half along a line parallel to either the x, y, or z axis, then optionally split in half along a line parallel to either one of the remaining axes, and then optionally split in half along a line parallel to the remaining axis, the node's associated region of space could be any of either the resulting halves, quadrants, or octants. In these terms, 3 factors determine the location and dimensions of a subdivision: the number of split lines (1 to 3), the respective axes/axis parallel to those/that split line(s) (x and/or y and/or z), and the number/index of the resulting half, quadrant, or octant that encompasses its space.

For any parent node with depth less than the minimum of the respective maximum x, y, and z depths (specified at offsets 0x1E,0x20,0x22), 3 split lines-each respectively parallel to the x, y, and z axes-determine the 8 octants that, respectively, encompass its children's corresponding subdivisions of space. For the children of parent nodes with a depth greater than or equal to the minimum, the split line(s) parallel to the axis/axes for which is/are specified that minimum are eliminated when determining the corresponding subdivisions. For the children of parent nodes with a depth greater than or equal to the second minimum, i.e. the minimum of the remaining 2 maximums (if any), the respective split lines parallel to the axes for which are specified the minimum ''and'' second minimum are eliminated when determining the corresponding subdivisions. The maximum of the 3 maximum depths determines the height of the tree.

For example, suppose maximum depth x were the minimum of the maximum depths-3, for example. Suppose also that maximum depth z were the second minimum-7, for example. For any parent node with depth less than 3, each of its children's corresponding subdivisions is a separate octant of its (the parent's) associated region of space. For any parent node with depth greater than or equal to 3 but less than 7, the ''x'' split line is eliminated in determining the subdivisions of its associated region-thus, it is only split in half y-wise and z-wise; equivalently, it is only split into 4 quadrants-an upper front, lower front, upper back, and lower back quadrant. Such a parent node could then have only 4 children, each respectively corresponding to a separate one of the 4 subdivisions/quadrants. For any parent node with depth greater than or equal to 7, the ''x'' and ''z'' split lines are eliminated in determining the subdivisions of its associated region-thus, it is only split in half y-wise; equivalently, it is only split into 2 halves-a left half and a right half. Such a parent node could then have only 2 children, each respectively corresponding to a separate one of the 2 subdivisions/halves.

*Parent nodes with depth less than the minimum have 8 children-but only if the minimum is nonzero.
**If a unique minimum [max] depth of 0 is specified for only one of the 3 axes, parent nodes with depth less than the second minimum have 4 children.
**If a minimum depth of 0 is specified for 2 of the 3 axes, all parent nodes have 2 children.
**If a minimum depth of 0 is specified for all axes, the tree is empty.
*Parent nodes with depth greater than or equal to the minimum and less than the second minimum(if it exists) have 4 children-but only if the minimum is unique.
**If the same minimum depth is specified for 2 of the 3 axes, parent nodes with depth greater than or equal to the minimum have 2 children.
**If the same nonzero minimum/maximum depth is specified for all axes-that is, there does not exist a second minimum-then all parent nodes have 8 children.
*Parent nodes with depth greater than or equal to the second minimum have 2 children-but only if the [first] minimum or second minimum is unique.
*Height of the tree is given by the maximum [of the max] depth(s).

=== Octree Node Format ===
Each node in the octree is specified as an unsigned short (2 bytes). The relative offset of the root node within the item is specified at offset 0x1C.

==== Internal/parent nodes ====
Internal/parent nodes are indicated by a cleared LSB (least significant bit); consequently, their [nonzero] value refers to the relative offset of [the first of] their children in the ''item''. Child nodes are stored contiguously as groups of 8, 4, or 2. The cardinality and arrangement of a parent's group of child nodes depends on its depth in relation to the axis associated maximum depths:
{| style="font-size:7pt;"
!Parent Depth Condition
!Children Group [format/arrangement]
!<code>A</code>
!<code>B</code>
!<code>C</code>
!<code>D</code>
!<code>E</code>
!<code>F</code>
!<code>G</code>
!<code>H</code>
|-
| <code>('''d < min''') && max</code>
| <code>AA AA BB BB CC CC DD DD EE EE FF FF GG GG HH HH</code>
| ULF
| ULB
| DLF
| DLB
| URF
| URB
| DRF
| DRB
|-
| colspan="10" |<code>cond = ('''d >= min && d < min2 '''&& min != min2)</code>
|-
|<code>'''cond &&''' '''min == maxx'''</code>
|<code>AA AA BB BB CC CC DD DD</code>
|UL
|UR
|DL
|DR
|n/a
|n/a
|n/a
|n/a
|-
|<code>'''cond &&''' '''min == maxy'''</code>
|<code>AA AA BB BB CC CC DD DD</code>
|LF
|LB
|RF
|RB
|n/a
|n/a
|n/a
|n/a
|-
|<code>'''cond &&''' '''min == maxz'''</code>
|<code>AA AA BB BB CC CC DD DD</code>
|UF
|UB
|DF
|DB
|n/a
|n/a
|n/a
|n/a
|-
| colspan="10" |<code>cond = ('''d >= min2'''<nowiki> && (min != min2 </nowiki><nowiki>||</nowiki> min2 <nowiki>!=</nowiki> max)) <nowiki>[||</nowiki> (d >= min && (min == min2 <nowiki>||</nowiki> min2 == max)) ] </code>
|-
|<code>'''cond && min2 == maxx'''</code>
|<code>AA AA BB BB</code>
|L
|R
|n/a
|n/a
|n/a
|n/a
|n/a
|n/a
|-
|<code>'''cond && min2 == maxy'''</code>
|<code>AA AA BB BB</code>
|top
|bot
|n/a
|n/a
|n/a
|n/a
|n/a
|n/a
|-
|<code>'''cond && min2 == maxz'''</code>
|<code>AA AA BB BB</code>
|F
|B
|n/a
|n/a
|n/a
|n/a
|n/a
|n/a
|}
* The Parent Depth Condition column lists conditions under which a parent node's contiguous group of children have the associated formats. Only the bolded conditions are relevant if max depths are unique. The following symbols are used for brevity:
** <code>d</code> = parent node depth
** <code>max*</code> = max depth *
** <code>M</code> = {<code>max*</code>} (for <code>*</code>=<code>x</code>,<code>y</code>,<code>z</code>)
** <code>min</code> = <code>min(M)</code>
** <code>min2</code> = <code>min(M - {min})</code>
** <code>max = max(M)</code>
* The Children Group column lists the arrangement or byte format of the parent's group of child nodes; depending on conditions, there are either 8 children [A-H], 4 children [A-D], or 2 children [A-B] in the group.
* Each of the A-H columns identifies that child's corresponding subdivision with an abbreviation:
** L = left, R = right, U = upper, D = lower, F = front, B = back

==== Non-existent nodes ====
Non-existent nodes are indicated with a value of <code>0</code>. A non-existent node refers to empty space; there is nothing particularly interesting about its corresponding subdivision, since the player will never interact/collide with it.

==== Leaf nodes ====
Leaf nodes are indicated by a set LSB; the remaining 15 bits describe collision attributes for the node's corresponding subdivision:

<code>UUUUUUSSSSSSTTT1</code>
* <code>T</code> = Node type
* <code>S</code> = Node subtype
* <code>U</code> = Unknown/unused?
Node type and subtype refer to type and subtype of the node's corresponding collidable subdivision of 3 space.

===== Node Type =====
Node type determines the primary type of corresponding collidable space:
{|
!Type
!Description
|-
|0
|Solid and Interactive
|-
|1
|Solid Floor/Ground
|-
|2
|Level Boundary Wall
|-
|3
|Pit Area
|-
|4
|Trigger Misc Death on Collision
|}

===== Node Subtype =====
Solid and Interactive, Pit Area, and Trigger Misc Death on Collision type nodes (types 0, 3, and 4) may optionally specify a node subtype. This subtype determines a specific event sent to the player upon collision with the node:
{|
!Subtype
!Description
!Event
|-
|0
|?
|?
|-
|1
|?
|?
|-
|2
|Spin, Fall Over, and Die (death sequence)
|<code>0x700</code>
|-
|3
|?
|<code>0xC00</code>
|-
|4
|Drown
|<code>0x2100</code>
|-
|5
|Burn to Ash
|<code>0x1F00</code>
|-
|6
|Explode
|<code>0x1E00</code>
|-
|7
|?
|<code>0xD00</code>
|-
|8
|?
|<code>0x1200</code>
|-
|9
|?
|<code>0x1200</code>
|-
|10
|?
|<code>0x1200</code>
|-
|11
|?
|<code>0x1200</code>
|-
|12
|Fall in a Hole and Die
|<code>0x900</code>
|-
|13
|?
|<code>0x2300</code>
|}
It is yet to be determined whether there are additional subtypes with other purposes.

== Camera Paths ==
In each game, the camera follows behind the player as it makes progress towards the goal. The camera, too, along with the player, makes progress towards the goal, albeit somewhat less advanced but at the same rate; thus, the player's progress within the level and the camera's progress within the level are directly related. In each game, the camera appears to travel a fixed path as it follows behind the player, zooming and panning accordingly.

A zone typically includes one or more connected ''paths'' along which the camera is to travel as the player character makes progress within that zone. As a whole, all paths [of all zones] in the level connect to form a ''central path'' from the initial player location to the goal, with possibly several divergences at any arbitrary point(s). Each divergence may or may not converge back into to the central path to trace out an alternate route.

=== Path Points ===
Each path is composed of a number of closely positioned points that typically trace out an approximate line or smooth curve. Each point corresponds to a position of the camera, and is also associated with a camera orientation. The line or curve traced by a path connects its points in sequence, where points in the path are stored sequentially. Path points are commonly referred to as ''progress points''.
* When the camera is '''at''' a point in a path, it is positioned at the location of that point and oriented according to the point's associated orientation.
* After the camera '''moves''' from the point that it is currently ''at'' to another point in the path, it will be ''at'' that other point.
* To move ''along'' a path, or move ''further into'' its trail, the camera moves from one point on the path to the next, and so on, until it reaches [is at] some desired destination point.

==== Path Progression ====
As the player ''makes'' ''progress'' within a zone, the camera consequently ''makes'' ''progress'' along the paths in that zone, thus keeping up with the player. As the camera progresses further along a path, it moves further into the path's trail. At any point on the path, by moving to the next point, the camera will have progressed one point further. The camera can progress from one point on the path to the next, and so on, until it reaches a desired destination point. The amount of progress made by the camera in a complete progression is the number of points that it has progressed further.

If the camera begins at the first point in a path and progresses to the ''n''th point, it will have made an amount of progress equal to ''1'' point less than ''n''. For example, if the camera begins at the first point in a path and progresses to the first point=''1''st/th point (''n''=''1''), then it will have made an amount of progress equal to ''1-1=0'' (no progress at all). The length of a path is just the number of points that it contains. If the camera begins at the first point in a path and progresses to the last point, it will have made an amount of progress equal to 1 less than the length of the path. The index of a [zero-indexed] path point is equivalent to the amount of progress that the camera will have made [after moving from the beginning/first point] at that point within the path. Thus, '''each [progress] point is indexed by its corresponding progress value'''.

==== Path Retrogression ====
Nothing prevents the player from ''retrogressing'' within a zone [unless it is at the initial entry point]; the player may return all the way back to its initial entry point in the first zone if it wishes. As the player retrogresses within a zone, its progress will ''rewind'', as it is counterbalanced by a subtraction in amount. The camera consequently must retrogress along with the player for its continued viewing. As the camera retrogresses along a path, it moves back towards the beginning of (i.e the first point in) the path's trail. At any point on the path, by moving to the previous point, the camera will have retrogressed one point back towards the beginning. The camera can retrogress from a point on the path to its previous point, and so on, until it reaches any desired destination point that is closer to the beginning of the path's trail. The amount of progress lost by the camera in a complete retrogression is the number of points that it has retrogressed.

==== Retrogressing too close - problem ====
At any point on the path, by moving to the previous point, the camera will have retrogressed one point back towards the beginning. However, at the first point, the camera is already at the beginning, and there is no previous point to move to within that path. At the first point on that path, the camera's ''current progress'' will be 0, as it has not progressed to any point further. If the camera were to retrogress any closer back to the initial entry point [in the first zone] from [its current position at] the beginning of (i.e. the first point within) the path, its current progress would decumulate to become (1 less than 0 =) -1. However, this refers to an invalid point index; there does not exist a point with this index (i.e. one point before the first point) at which the camera could be positioned.

==== Progressing too far - problem ====
At any point on the path, by moving to the next point, the camera will have progressed one point further. However, at the last point, there is no next point to move to within that path. At the last point on that path, the camera's current progress will be 1 less than the length of the path-i.e. the index of the last point on the path. If the camera were to progress any further past [its current position at] the end of (i.e. the last point within) the path, its current progress would accumulate to become (1 less than the length of the path + 1 =) the length of the path. Path points are zero-indexed, however, so this would refer to an invalid point index; there does not exist a point with this index (i.e. one point past the last point) at which the camera could be positioned. If the path were extended past its current last point, this ''would'' be a valid index-that of a point that continued the path.

=== Neighbor Paths - solution ===
Even unextended, the path still actually ''does'' continue past its last point. Recall that several paths in a zone can be ''connected'': a single path may reference one or more connected ''neighboring paths''. A path's neighboring paths may be:
* any path in its parent zone, other than itself
* any path in any of its parent's neighboring zones
Each of a path's neighboring paths contain either points that continue the path past its last point, or points that retrogress before its first point. The path's own points are a retrogression of the neighbor path [points] that continue past its last point, and are a continuation of the neighbor path [points] that retrogress before its first point.

==== Progressing too far - solution ====
When the camera reaches the [invalid] progress that is an invalid index of a point that would be ''one point past the last point'' in the path, the ''current path'' is changed to a neighbor path [with points] that continue(s) the path past its last point; the camera is said to have ''entered'' this path, particularly at its ''entrance'' (i.e. beginning/first point). As it has only just reached the beginning of/first point in this connected path, the camera's current progress along that path is also set to 0 (index of first point). The camera can then continue to progress within that path as necessary along with the player, just as it had done in the previous path.

==== Retrogressing too close - solution ====
When the camera reaches the [invalid] progress that is an invalid index of a point that would be ''one point before the first point'' in the path, the current path is changed to a neighbor path [with points] that retrogress(es) from the path before its first point; the camera is said to have ''re-entered'' this path, particularly, at its ''exit'' (i.e. end/last point). As it has re-entered the connected path at its exit point, the camera's current progress along that path is also set to 1 less than its length (index of last point). The camera can then continue to retrogress within that path as necessary along with the player, just as it had done in the previous path.

==== Specification ====
A path specifies up to 4 neighboring paths by including the following information for each path:
# The zone that contains the neighboring path
# The index of the neighboring path within that zone
# Whether the neighboring path, in relation to this path, is a ''continuation'' or a ''retrogression''
#* A continuation indicates that the neighboring path is closer to the goal than this path
#* A retrogression indicates that the neighboring path is further from the goal than this path
# Whether the neighboring path, from the perspective of the player as it faces in the direction of the goal, is:
#* In front of the path
#* Behind the path
#* Above/Below the path

==== Divergence and Convergence ====
More than one of a path's neighbors can be either a continuation or a retrogression of the path. Each is either an alternate continuation or retrogression of the path and equivalently either a divergence or convergence from/into the path. For example, at the beginning of the split in route towards the end of N. Sanity Beach, there is a path with 3 neighbors: one a retrogression (the path that leads into it), and the other 2 continuations the left and right branches, respectively, of the path. Right before the goal, the 2 branches meet up again, converging to a singular central path; the point of convergence is of a path with 3 neighbors: one a continuation, which is the final path of all paths in all zones of the level, whose last point is located right behind the goal, and the other 2 retrogressions the left and right branches, respectively, that lead into the path.

=== Additional Parameters ===
Each camera path includes the following additional information:

* [Polygon] Sort list
* Parent zone
* Camera mode
* Camera zoom/pan factor
* Length of the path
* Alternate entrance and exit point relative indices
* Average distance between each path point
* Approximate direction of the path (a unit vector)

Average distance between each path point and approximate direction of the path are used to convert the camera's location within the level to a progress along the path. The camera typically has an idea of how much it should move from its current location to keep up with the player, but not in terms of how much it should progress along the path. Usually the camera would ''like'' to move to a location that lies outside of the path, but can not since its movement is restricted following along that path. Thus, the scalar projection of the camera's desired, ''unprojected'' location onto a linear approximation of the path (i.e. path direction) is computed to determine its approximate projected location or distance along the path. This distance is then divided by the average distance between each path point to determine its actual progress along the path.

Purposes of the other fields are explained elsewhere (See: camera update routine TBD).

World

2019-04-27T17:44:40Z

Chekwob: 8 revisions imported: Initial import from Wikia

A World is a 3 dimensional gouraud-shaded textured/semi-textured or non-textured polygon mesh that represents a visible portion of a level; all together, the world(s) [entries] in an NSF file represent the entire model for the corresponding level. Worlds are Type 3 entries. Each zone specifies at most 8 world models that shall be rendered [and will appear to the player] when the player character is within its confines. For each frame of execution, the corresponding polygon primitives are re-generated from the model data for the 8 worlds in the current zone, transformed according to global matrices (i.e. camera trans, rot, and scale) including a perspective transform from 3 dimensions to 2, and finally sent to the GPU for rendering. As a result, the player observes the [up to] 8 world models from the perspective of the camera at its current point/progress along its current path within the current zone.

== Introduction ==
It is usually unlikely that a world model lies entirely on-screen; consequently, not all polygons for that world will need to be rendered by the GPU. Polygons must be rendered in a back-to-front order-that is, the [https://en.wikipedia.org/wiki/Painter%27s_algorithm painter's algorithm] can be applied directly to some 'depth sorted' list of to-be-rendered polygons. Polygons cannot be rendered in their order from the Type 3 entry; they are not depth-sorted and therefore would fail at the painter's algorithm. Furthermore the polygons that lie off-screen would still undergo transformation by the GTE and rendering by the GPU only to not appear at all-which is a waste of graphical computation time. A list known as the current polygon list then determines the back-to-front ordering of polygons, listed by Polygon ID. (during a level update, decoding of Sort Lists reorders/rebuilds the current polygon list according to camera progress)

During world model primitive creation and transformation, for each polygon ID in the current polygon list from the end to the beginning, a representative 3-point polygon primitive is generated using the vertex data for the polygon with that ID, in one of the 8 current zone world models, and transformed accordingly; for each primitive created, its tag field is pointed to the representative primitive for the previous polygon [ID] in the list (when it is created). This creates a linked list of primitives starting with that created for the last polygon and ending with that created for the first. Since the polygon list sorts IDs by depth of their corresponding polygons, the primitive linked list sorts their corresponding primitives [by depth] from back to front. During the rendering stage, the GPU then steps through this list, rendering each polygon primitive in the appropriately specified order from back to front.

Primitives generated for worlds are <code>POLY_G3</code> and/or <code>POLY_GT3</code> structures of the PSX Basic Graphics Run-time library. Several fields from the associated polygon's vertex data are extracted, manipulated, and rearranged before they finally occupy the various fields of the polygon's <code>POLY_G3</code> or <code>POLY_GT3</code> primitive.

== Format ==

=== Crash 1 ===

==== Item 1: Header ====
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|X Location
|4 bytes
|*
|-
|0x4
|Y Location
|4 bytes
|*
|-
|0x8
|Z Location
|4 bytes
|*
|-
|0xC
|Polygon count
|4 bytes
|*
|-
|0x10
|Vertice count
|4 bytes
|*
|-
|0x14
|Texture info structures
|4 bytes
|*
|-
|0x18
|Texture Page Count
|4 bytes
|t
|-
|0x1C
|Translate Flag
v=0 Indicates a "Backdrop"
|4 bytes
|*
|-
|0x20
|Texture Page EIDs
|8 x 4 bytes
|*
|-
|0x40
|Texture Info Array
|* x 4 bytes
|*
|}
Data in the Texture Info Array is consisted of either 4 and/or 8 byte structures with the following formats:

<code>Format A: 0******* RRRRRRRR GGGGGGGG BBBBBBBB</code>

<code>Format B: 1SS0HHHH RRRRRRRR GGGGGGGG BBBBBBBB DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY</code>

* <code>S</code> = Semi-Transparency Mode
* <code>M</code> = Color Mode
* <code>L</code> = Texture Page 128/256 pixel region X index
* <code>X</code> = Texture X offset
* <code>Y</code> = Texture Y offset
* <code>D</code> = Texture Region Index
* <code>Z</code> = Primary CLUT ID
* <code>H</code> = Secondary CLUT ID
* R = Red Value?
* G = Green Value?
* B = Blue Value?

# A structure of format A describes optional color information ('''unconfirmed''') for a polygon that will be converted to a non-textured primitive.
# A structure of format B describes texture information for a polygon that will be converted to a textured/semi-textured primitive (explained in detail below).

Each polygon (see below) specifies an offset into the texture info array of the structure that describes a specific region of pixel data [in some texture page] that maps to it (or to describe no texture data at all). The texture page EIDs refer to 8 different texture pages that can be used as sources for texture data. A polygon will refer to one of these 8 EIDs as the source texture page from which to grab the pixel data.

==== Item 2: Polygons ====
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Polygons
|* x 8 bytes
|*
|}
This item contains a number of 8 byte structures, each of which describes an individual ''polygon'' (a 3 point triangle) in the world, by the 3 separate vertices that it consists of and with information about texture that maps to it.

Each structure has the form:

<code>CCCCCCCC CCCCTTTT TTTTTTTT EEEPPPPP AAAAAAAA AAAABBBB BBBBBBBB VVVWWWWI</code>

* A = Index of Vertex A in Item 3: Vertices
* B = Index of Vertex B in Item 3: Vertices
* C = Index of Vertex C in Item 3: Vertices
* E = Index of one of 8 texture page EIDs in Item 1: Header
* T = Texture Info index, into Texture Info Array of Item 1: Header
* P, V, W = determine an additional offset to the index into the Texture Info Array (for animated textures)
* I = ignored?

==== Item 3: Vertices ====
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Vertices
|* x 8 bytes
|*
|}
This item contains a number of 8 byte structures, each of which describes a single vertex of a polygon (which may or may not be shared by more than one polygon):

<code>ZZZZZZZZ RRRRRRRR GGGGGGGG BBBBBBBB XXXXXXXX XXXXXSSS YYYYYYYY YYYYYNNI</code>

* <code>X</code> = Vertex X Position
* <code>Y</code> = Vertex Y Position
* <code>Z</code> = Vertex Z Position
* <code>S</code> = Vertex Sub-section (also determines z position)
* <code>N</code> = Vertex Section (also determines z position)
* <code>R</code> = Vertex Red Value (for gouraud shading)
* <code>G</code> = Vertex Green Value (for gouraud shading)
* <code>B</code> = Vertex Blue Value (for gouraud shading)
* <code>I</code> = Vertex Shader/Effect Flag

== Primitive Creation ==
A general outline of the primitive creation loop for world models:
# Grab next polygon referred to by the current polygon list from 1 of 8 worlds in the current zone
# Set GTE translation vector to that of the world's (if the world is different than that grabbed from in the last iteration)
# Perspective transform the 3D polygon vertex coords with GTE; (resulting X, Y will be used as 2D on-screen coordinates for the primitive's vertices)
# Grab vertex colors (from each vertex of the polygon) for gouraud shading
# Determine the type (textured, semi-textured, non-textured) and specifics of primitive to create based on polygon's associated texture information
# Create the gouraud-shaded primitive with the transformed coordinates, vertex colors, and texture information
# Grab the resulting Z coordinates from the perspective transformation and calculate their average
# Place a pointer to the primitive at its respective location in the ordering table (OT); if it replaces an already existing primitive [pointer] at that location in the OT, link this primitive to the replaced primitive
This happens for each frame; primitives from previous frame are overwritten.

=== Extracting Texture Information ===

For a single polygon, texture information is distributed among the bits of 3 separate fields:

1. Texture chunk index/palette

This field is resolved by processing/lookup of the texture page EID specified for the polygon. A polygon specifies a texture page EID by its index within the [array of 8] Texture Page EIDs in the world's header item (Item 1). (E bits) <pre>00000000 0000RRRR RRRRRRPP Y??1XX??</pre>2. Texture information

A polygon specifies ''texture information'' by its index within the Texture Info Array of the world's header item (Item 1). (T bits)

<pre>KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY</pre>3. Texture region

A polygon's texture information specifies its ''texture''<nowiki/>'s ''region'' by its index within the [game's] global constant ''regions array''.

<pre>XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY
vertex A vertex B vertex C vertex D</pre>

From these various sources, texture information is extracted, manipulated, and rearranged before it is finally recorded in the texture-related fields of the polygon's POLY_GT3 primitive. These fields include the <code>tpage</code>, <code>u0</code>, <code>v0</code>, <code>u0</code>, <code>v1</code>, <code>u2</code>, <code>v2</code>, and <code>clut</code> fields.

==== PSX GPU Framebuffer ====
The Playstation GPU has 1MB of VRAM. Interpreted as an array of 16 bit pixels, the entire 1MB region of VRAM is a surface of 1024x512 resolution. In the Crash games, the upper left 512x256 quadrant contains the on-screen display of the first frame in every 2-frame "cycle", while the upper-left 512x256 quadrant contains the on-screen display of the second frame in every 2-frame "cycle". The lower 1024x256 half is consisted of several ''texture pages''; together, all texture pages are consisted of all texture data loaded into VRAM. A single textured polygon primitive specifies a 2-dimensional image of pixels, or texture, that is mapped to its surface when rendered. A polygon primitive specifies its texture as the 2-dimensional area, within a specific texture page, that contains the texture image/pattern.

For texture pages, VRAM is also alternatively interpreted as an array of either 2048x512 8 bit pixels or 4096x512 4 bit pixels. The pixel data in a texture page can include either 16 bit pixels, 8 bit pixels, or 4 bit pixels; some portions of a texture page may specify 4 bit pixels while the others may specify 8 or 16 bit pixels. A polygon primitive specifies the ''color mode'' for its texture as either mode 0 = 4 bits, mode 1 = 8 bits, or mode 2 = 16 bits; this means that the region of pixels that it specifies is consisted of either 4 bit, 8 bit, or 16 bit pixels.

In 16, 8, and 4 bit color modes, respectively, a texture page is a surface of 64x256, 128x256, and 256x256 pixels. The pixel data contained by a texture page does not differ with color mode-the same texture page interpreted as 4 bit pixels is interpreted as 8 or 16 bit pixels. In any color mode, only the regions of pixels of that color mode will be interpreted properly. For example, if the contents of a texture page are 'viewed' in 8 bit color mode, the 8 bit pixel regions will display properly while the 4 bit pixel regions will typically appear twice as wide as they should, with an incorrect palette, and interlaced with strangely colored lines. There are a total of 16 [horizontally contiguous] texture pages in the lower half of VRAM-that is, a single row with 16 columns of texture pages.

16 bit pixels have the following format:
SBBBBBGGGGGRRRRR
* R = red value

* G = green value

* B = blue value

* S = semi-transparency flag
16 bit pixels are raw pixels. The R, G, and B fields in a 16 bit pixel refer directly to the respective red, green, and blue brightnesses of the color.

8 bit and 4 bit pixels are instead specified as an index into a particular table of 256 or 16 colors, known as the ''CLUT'' or ''color lookup table''; an 8 or 4 bit pixel's actual color value is thus located at its specified index in the table. CLUTs are specified in the texture pages themselves-that is, if the texture pages are viewed in 16 bit color mode, several lines of either 256 pixels (stacked vertically) or 16 pixels (can stack horizontally and vertically) with a seemingly random distribution of color may appear [typically at the top] along with the rest of the texture images. The data for such a line of pixels is actually just [the 256 or 16 16-bit colors of] a CLUT ''in'' the texture page. A polygon primitive will then specify the CLUT to use for the pixels in its [texture's] [either 4 or 8 bit pixel] region of the texture page.

NSF files store the pixel data for texture pages in ''texture chunks'', with resolutions of 512x128 in 8 bit/1024x128 in 4 bit. The space occupied by a texture chunk takes up either the entire top or bottom half of 4 horizontally consecutive texture pages in VRAM. (512x128 / 128x256 = 4 x 1/2) 4x2 texture chunks will thus fill the texture pages in their entirety. (16x1 / 4x1/2 = 4x2). The game will page up to 8 texture chunks from an NSF file and copy their data in sequence to fill the entire bottom half/all texture pages in VRAM.

It must also be noted that what the game refers to as ''texture pages'' are actually the 4x2 ''texture chunks'' in the bottom half of VRAM, and not what the GPU views as the 16 horizontally contiguous 64/128/256x256 texture pages that hold their content. In the format section, ''texture page EID'' refers to the ID for a texture page information 'entry', texture page in this context referring to one of the 4x2 texture chunks in the bottom of VRAM. From here on, ''texture page'' will refer to one of the 16 horizontally contiguous 64/128/256x256 GPU texture pages.

==== Texture Page ====
The <code>tpage</code> field of a <code>POLY_GT3</code> primitive specifies the ''texture page'' which contains (among other textures) the source texture for the polygon. It also specifies the color mode, and semi-transparency mode, of pixels in that texture.
===== Source =====
====== Texture Information Field ======
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY
* L = 128/256 pixel region X index

The top/bottom halves of 4 [horizontally contiguous] texture pages in VRAM occupy the polygon's source texture chunk. A polygon's texture information field specifies which 1 of these 4 texture pages contains its source texture-that is, which 128x128 pixel (8 bit)/256x128 pixel (4 bit) region of the source texture chunk contains the source texture.
* M = Color Mode (0 = 4 bit, 1 = 8 bit, 2 = 16 bi)
* S = Semi-Transparency Mode

A polygon's texture information field also specifies the color mode and semi-transparency mode of pixels in the source texture.

====== Texture Chunk Index/Palette ======
00000000 0000RRRR RRRRRRPP Y??1XX??
* X = Texture Chunk X Index

A polygon's texture chunk index/palette field specifies the X index of its source texture chunk in VRAM.

Note: The preceding 1 before XX is also copied to its corresponding bit in the texpage field. (Not confirmed that this is always 1 but it should be.)

===== Destination =====
The <code>tpage</code> field of a <code>POLY_GT3</code> primitive has the following format:
0000000M MSSYXXXX
* X = Texture Page Index (**X Base)
* Y = Indicates the half of VRAM in which texture pages reside (0 = upper, 1 = lower) (**Y Base)
* S = Semi-Transparency Mode
* M = Color Mode
Texture Pages reside in the lower half of VRAM in the Crash games, so Y=1. Each texture chunk horizontally spans 4 texture pages of VRAM. Given the X index of a chunk, and the index among its 4 containing texture pages, the total texture page index is computed by:
(chunkx*4)+index or (chunkx << 2) | index
Thus, the complete extraction of bitfields:
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY
00000000 0000RRRR RRRRRRPP Y??1XX??
|
V
0000000M MSS1XXLL
tpage: 0000000M MSSYXXXX

tpage.X = (X << 2) | L
tpage.Y = 1
tpage.S = S
tpage.M = M

==== Texture coordinates ====

The <code>u0</code>, <code>v0</code>, <code>u1</code>, <code>v1</code>, <code>u2</code>, and <code>v2</code> fields of a <code>POLY_GT3</code> primitive specify the ''texture coordinates'' of the polygon's source texture (relative to the texture page that contains it [the source texture]).

Note that a texture page will contain 1/4 of a texture chunk in its/the upper half [of the lower half of VRAM], and 1/4 of the texture chunk below the chunk in the upper half-in its/the lower half [of the lower half of VRAM]. Thus, some additional information from the Texture Chunk Index/Palette field-particularly, the Y index of the desired source chunk and thus whether the source texture lies within the upper half (with 1/4th of the upper chunk) or the lower half (with 1/4th of the lower chunk) of the texture page-is needed for factoring into texture [Y] coordinates.
===== Source =====
====== Texture Information ======
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY
* X = Texture X Offset (8 bit mode: mult of 4; 4 bit mode: mult of 8)
* Y = Texture Y Offset (mult of 4)

A polygon's texture information field specifies the X,Y coordinate of the upper left point of a particular rectangular region of VRAM relative to [i.e. within] the source texture page, in terms of 8x4 pixel units for 4 bit mode source textures and 4x4 pixel units for 8 bit mode source textures. A triangular half of this rectangular region determines the actual source texture mapped to the polygon.

====== Texture Chunk Index/Palette ======
00000000 0000RRRR RRRRRRPP Y??1XX??
* Y = Texture Chunk Y Index

A polygon's texture chunk index/palette field specifies the Y index of its source texture chunk in VRAM. There are only 2 rows of texture chunks, so this value is either 0 = top row, or 1 = bottom row. Equivalently this indicates whether the top or bottom halves of the 4 [horizontally contiguous] texture pages in VRAM occupy the polygon's source texture chunk.

====== Texture region ======
XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYY
point A point B point C point D

A polygon's texture region determines the triangular region relative to Texture X and Y Offsets [within the containing texture page] of the actual source texture mapped to the polygon. As mentioned previously, a polygon's ''texture information'' specifies its texture's ''region'' by its index within the [game's] global constant ''regions array''. The regions array contains 600 x 4 point 2D quads; each point is 2 bytes in length, with the first and second bytes corresponding to its X and Y coordinates, respectively. Quads in the regions array are indexed by several different attributes:
* <code>'''width''' = (index % 5)</code>
* <code>'''height''' = ((index / 5) % 5)</code>
* <code>'''winding''' = (index / 25) % 6</code>
* <code>'''flip''' = (index / 150)</code>
{| class="article-table"
! rowspan="2" |Value
! colspan="4" |Field
|-
!Flip
!Winding
!Width
!Height
|-
!0
|
C
<nowiki> |\
| \
A |--\ B</nowiki>
|ABC
|4
|4
|-
!1
|
C
/|
/ |
A /--| B
|ACB
|8
|8
|-
!2
|
C B
\--|
\ |
\| A
|BCA
|16
|16
|-
!3
|
B C
<nowiki> |--/
| /
A |/</nowiki>
|BAC
|32
|32
|-
!4
|n/a
|CAB
|64
|64
|-
!5
|n/a
|CBA
|n/a
|n/a
|}
actual width = 2 ^ (2 + (index % 5));
actual height = 2 ^ (2 + ((index / 5) % 5));
(Note that width and height do not depend on color mode)

Only the first 3 points of a quad determine the 3 points of the triangular region relative to Texture X and Y Offsets [within the containing texture page] of the the source texture. (The last point is used for quad primitives, created elsewhere for object sprites, fragments, and etc.) Each of the 3 points defines the relative U,V coordinates of its respective vertex in the polygon primitive.

Quads have been pre-computed such that they have the attributes described by their indices. For example, the quad at index 48 has the following attributes:
actual width = 2 ^ (2 + (48 % 5)) = 32
actual height = 2 ^ (2 + ((48 / 5) % 5)) = 32
winding = (48 / 25) % 6 = 1
flip = (48 / 150) = 0
Thus, its first 3 points are the respective A, C, and B vertices (winding 1 = ACB) of a 2D right triangle with width 32, height 32, and orientation as shown for flip = 0. The first 3 points of the quad at that index are then (0, 0), (0, 32), (32, 0). For a polygon that specifies an index of 48 in its texture information for its texture region, these 3 points would define the relative U,V texture coordinates for the respective vertices in its primitive.

===== Destination =====

For each vertex '''v''' in {0,1,2}, the <code>u'''v'''</code> and <code>v'''v'''</code> fields of a <code>POLY_GT3</code> primitive are both a byte in length and should simply specify the U,V (i.e. X,Y) texture coordinates (in pixels) for that vertex, relative to the source texture page.

In calculating the texture coordinates, the Texture X and Y offsets (and Color Mode*) are first extracted from Texture Information:
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY
And then the Texture Chunk Y Index from Texture Chunk Index/Palette :
00000000 0000RRRR RRRRRRPP y001xx00
And finally the points from the Texture Region:
XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY XXXXXXXX YYYYYYYY
point A point B point C point D
(Point D is unused by world polygons, since they are only 3 point triangles)

Since each point of the triangular texture region is relative to either the top or bottom [quarter of the] chunk within the source texture page, and additionally the Texture X and Y Offsets within [that quarter of the chunk within] the source texture page, the total texture coordinates are then calculated separately for each point. Since a texture chunk is 128 pixels in height, and since the Texture X and Y Offsets are given in terms of 8x4 pixels for Color Mode = 0 (4 bit mode) and 4x4 pixels for Color Mode = 1 (8 bit mode), then the following computes the location within the source texture page that the texture region points are given relative to:
tx = ((X * 8) >> M)
ty = ((128 * y) + (Y * 4))
Each texture region point is added to (tx, ty) to get its location within the source texture page, and equivalently the U, V texture coordinates for its corresponding vertex in the polygon primitive. Since the max size of a texture page is 256x256, i.e. for when interpreted in 4 bit mode, the range of UV coordinates is restricted to (0,0)-(255,255). Further, the texture images/patterns in a texture page are aligned only to multiples of their widths and heights. A logical or, rather than an addition, of the region point(s) and (tx, ty) will thus result in the same value, but only if tx and ty respectively are multiples of the width and height of the texture region.

XXXXXXXX (rxv)
<nowiki>|</nowiki> XXXXX000 >> MM (txv)
<nowiki>----------
</nowiki> xxxxxxxx (uv)

YYYYYYYY (ryv)
<nowiki>|</nowiki> yYYYYY00 (tyv)
<nowiki>----------
</nowiki> yyyyyyyy (vv)

==== CLUT coordinates ====

The <code>clut</code> field of a <code>POLY_GT3</code> primitive specifies the coordinates of the CLUT [for the source texture pixels], within the source texture page. As previously explained, the primitive's CLUT specifies the 256 (8-bit mode) or 16 (4-bit mode) color palette used by pixels of its source texture, in 8 bit mode or 4 bit mode. CLUTs are arranged in narrow and long form horizontally in texture pages, 256 x 1 (8-bit mode) or 16 x 1 (4-bit mode).

The CLUTs are typically included at the top of texture chunks, such that several 512 pixel (8-bit mode)/1024 pixel (4-bit mode) horizontal lines may stack at the top ''n'' lines (where ''n'' is typically < 16) of 4 horizontally consecutive texture pages, and several 512 pixel (8-bit mode)/1024 pixel (4-bit mode) horizontal lines may stack at the top ''n'' lines in the bottom half of the same 4 texture pages. Also, some of these lines might actually instead be groups of 16 [or less] 32 pixel (8-bit mode)/64 pixel (4-bit mode) horizontally consecutive lines. Each of these lines is a CLUT, and viewed in 16-bit mode, is a horizontal line of either 256 pixels (in a line) or a horizontal line of 16 pixels (in a group of 16). Each consecutive pixel in a CLUT line has the color at its corresponding index in that CLUT ['s palette]. In 16-bit mode, texture chunks are 256x128 pixels.

The primitive's <code>clut</code> field specifies, and thus the GPU processes, the CLUT coordinates as an absolute location in terms of 16 x 1 pixel lines-that is, a CLUT location of (x, y) is actually the ''absolute'' location (16x, y) in VRAM. As an absolute location, unlike texture coordinates, it is ''not'' specified in relation to the source texture page.

===== Source =====
====== Texture Information ======
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLXX XXXZZZZZ ZZ0YYYYY
* Z = primary CLUT ID (VRAM Y location)

A polygon's Texture Information field specifies the primary ID of the CLUT to use for its 8-bit or 4-bit mode texture. Since 256 color CLUTs are stacked from the top of the source texture chunk, each CLUT is at its own line in VRAM and thus has a unique Y. Therefore, each of the ''chunk's'' CLUTs is identified by its Y location in VRAM.
* H = secondary CLUT ID (for 16 color/4-bit mode)

A polygon's Texture Information Field also specifies the secondary ID of the CLUT to use for its 4-bit mode texture. Since any 256 color CLUT can also be a group of 16 horizontally consecutive 16 color CLUTs, the primary CLUT ID specifies the group, and the secondary CLUT ID specifies the index of the 16 color CLUT among the 16 within that group.
Thus, a CLUT with given primary ID and/or secondary ID has the following location, relative to the source texture chunk, in VRAM:
X = H*16
Y = Z

====== Texture Chunk Index/Palette ======
00000000 0000RRRR RRRRRRPP Y??1XX??
* P = Texture Chunk CLUTs X location (mult by 256)
* R = Texture Chunk CLUTs Y location
A polygon's Texture Chunk Index/Palette field specifies the X (multiplied by 256) and Y location of the source texture chunk's CLUTs in VRAM. Since the CLUTs are located at the top of a Texture Chunk, they are positioned relative to its [upper-left] location. Thus, the X location, ultimately multiplied by 256, should actually just be the X index of the texture chunk in VRAM. The Y location should then be either 512 if the source chunk is in the upper half of the lower half of VRAM, or 768 if it is in the lower half of the lower half of VRAM (although the field is open to specify any Y, values other than these would not make sense.)

===== Destination =====

The <code>clut</code> field of a <code>POLY_GT3</code> primitive has the following format:
0YYYYYYY YYXXXXXX
* X = CLUT X location / 16 (in VRAM) [XXXXXX is multiplied by 16 to get total X location]
* Y = CLUT Y location (in VRAM)
In calculating <code>clut</code> for the primitive, the primary and secondary CLUT IDs are first extracted from Texture Information:
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLGG GGGZZZZZ ZZ0XXXXX
And finally the Texture Chunk CLUT X and Y locations from Texture Chunk Index/Palette (P, R):
00000000 0000RRRR RRRRRRPP Y??1XX00
Recall that a CLUT with given primary ID and/or secondary ID has the following location, relative to the source texture chunk, in VRAM:
X = H*16
Y = Z
This location is specified relative to the source texture Chunk's [CLUT] location; the Chunk [CLUTs] X Location specified by the Texture Chunk Index field (P) must first be multiplied by 256 for its actual value. The total CLUT location is then:
X = (P*256) + (H*16)
Y = R + Z
However, CLUT X location is specified in the <code>clut</code> field as its actual value divided by 16, so the total CLUT location (as specified by the <code>clut</code> field) is:
CLUT x = X/16 = (P*16) + H
CLUT y = Y = R + Z
When the game computes CLUT Y, R is logically or'ed with Z rather than added; if both operations were to always yield the same results, this implies that only the upper 2 bits of R have the option to be set. R's MSB adds nothing when clear and 512 when set, so it specifies either the top or bottom half of VRAM. Since the Texture Pages and therefore the CLUTs are located in the bottom half of VRAM, then R's MSB should always be set. Bit 9 of R adds nothing when clear and 256 when set, so it specifies whether the CLUT is located [relative to the top of its chunk] in either the top or bottom half of the bottom half (texture page portion) of VRAM. Note that, under these implications, Bit 14 in the final result for <code>clut </code>is always clear, which then further implies that CLUTs can only be located in the upper halves of texture chunks.

Thus, the complete extraction of bitfields:
KSS0HHHH 00000000 00000000 00000000 DDDDDDDD DDMMLLGG GGGZZZZZ ZZ0XXXXX
00000000 0000RRRR RRRRRRPP Y??1XX00
|
V
000ZZZZZ ZZPPHHHH
| RRRRRRRR RR000000 or if R = 1Y00000000: 1Y0ZZZZZ ZZPPHHHH
<nowiki>-------------------</nowiki> -----------------
<nowiki> </nowiki> YYYYYYYY YYXXXXXX YYYYYYYY YYXXXXXX<nowiki></nowiki>

Textureinformation Crash 2/3

2019-04-27T17:44:39Z

Chekwob: 12 revisions imported: Initial import from Wikia

== Introduction ==
In Crash 2/3, ''texture information'' contains information about a 3D model's UV coordinates, (animated) textures and colorpalettes. The ''texture information'' can also be used by ''<nowiki/>'extended information''' . Extended information can loop through multiple 12-byte structures to make animated textures, or provide settings for textures with different LOD's (Levels of Detail).

== Texture information ==
Texture information information is stored in 12-byte structures in the 4th item of scenery and model entries. The format for the 12-byte structure consists of 3 consequent 32-bit integers and is as follows:

'''YYYYYYYY YYYYXXXX BBBBBBBB AAAAAAAA'''

'''TTTTTTTT FMM0SSSS DDDDDDDD CCCCCCCC'''

'''HHHHHHHH GGGGGGGG FFFFFFFF EEEEEEEE'''

The contents represent the following:

'''AAAAAAAA'''

Model entry: for triangle type “AA” and “BB”, UV point 3 x, for triangle type “CC”, UV point 1 x

Scenery entry: UV point 1 x

'''BBBBBBBB'''

Model entry: for triangle type “AA” and “BB”, UV point 3 y, for triangle type “CC”, UV point 1 y

Scenery entry: UV point 1 y

XXXX

CLUT-line origin x coordinate (CLUT: Color LookUp Table, contain the colors for a specific texture)

'''YYYYYYYYYYYY'''

CLUT-line origin y coordinate

The origin [x,y] for the CLUT-line is placed in a 16-bit interpretation of the texturechunk.

4-bit textures can have 2^4 = 16 different colors. Therefore the corresponding CLUT-line should always be 16 pixels long (in 16-bit!).

8-bit textures can have 2^8 = 256 different colors. Therefore the corresponding CLUT-line should always be 256 pixels long (in 16-bit!).

'''CCCCCCCC'''

Scenery/model entry: UV point 2 x

'''DDDDDDDD'''

Scenery/model entry: UV point 2 y

'''F '''

Flag determined to define a 8 or 4-bit texture. 0 = 4-bit, 1 = 8-bit.

'''MM'''

The colormode instructs how the texture should interpret the CLUT-colors (formatted as 'SBBBBBGGGGGRRRRR').
{| class="article-table"
!Colormode
!RGBA if 'S' = 1
!RGBA if 'S' = 0
|-
|0 (translucent face)
|A = 50%
|if [R,G,B] = [0,0,0] A = 0% else A = 100%
|-
|1 (additive face)
|A = 50%
|if [R,G,B] = [0,0,0] A = 0% else A = 100%
|-
|2 (subtractive face)
|A = 0%
|if [R,G,B] = [0,0,0] A = 0% else A = 100%
|-
|3 (standard/opaque face)
|A = 0%
|if [R,G,B] = [0,0,0] A = 0% else A = 100%
|}
'''0'''

Unused?

'''SSSS'''

Texturechunk segment index (0, 1, 2 or 3)

Each texturechunk in the original Crash games consists out of 4
segments.

The 16-bit size of a texturechunk is 256 x 128

The 8-bit size of a texturechunk is 512 x 128

The 4-bit size of a texturechunk is 1024 x 128

Therefore, the segments in 16-, 8- and 4-bit mode are respectively:

- 64 x 128,

- 128 x 128

- 256 x 128

The segment index refers to the origin of the segment. The UV points work relative from this origin. Note that the values of the UV points are not effected by 8- or 4-bit mode. The x,y values range from
0 to 255 and are fixed.

'''TTTTTTTT'''

Model entry: refers to an offset from 0x0C in the header, for which textureslot to use (0-7 (i.e. 0x0 – 0x40 ) )

Scenery entry: refers to an offset from 0x2C in the header, for which textureslot to use (0-7 (i.e. 0x0 – 0x40 ) )

'''EEEEEEEE'''

Model entry: for triangle type “AA” and “BB”, UV point 1 x, for triangle type “CC”, UV point 3 x

Scenery/model entry: UV point 3 x

'''FFFFFFFF'''

Model entry: for triangle type “AA” and “BB”, UV point 1 y, for triangle type “CC”, UV point 3 y

Scenery/model entry: UV point 3 y

'''GGGGGGGG '''

Scenery entry: UV point 4 y (applies to quads only)

'''HHHHHHHH '''

Scenery entry: UV point 4 x (applies to quads only)

== Extended information ==
Extended information is in the 7th item in scenery entries and/or the 5th item in model entries. It is stored as 32-bit integers and can have 2 different formats according to flag 'F':

'''F???????? ???????? ?????OOO OOOOOOOO'''

'''OOOOOOOOOOO'''

Starting offset (in 12-byte structures) in the item for ''texture information''. The first structure is indexed by 1, not 0. 0 is reserved for non-textured!

=== Texture information with LOD ===
If flag 'F' is set, the extended information will serve as ''texture information'' with 8 customizable LOD-settings according to camera distance, ranging from close (AA) to further away (II).

'''1AABBCCDDE EFFGGHHI I0000OOO OOOOOOOO'''

'''AA, BB, CC, DD, EE, FF, GG, HH, II'''

LOD-settings. Since each texture has a maximum of 4 LOD's (respectively from hi- to lo-res), each one of these 8 settings can be set from 00 (hi-res) to II (lo-res) in binary.

'''0000'''

Unused?

=== Animated texture information ===
If flag 'F' is not set, the extended information will serve as ''animated'' ''texture information. ''The LOD-distances are standardized. This extended information will define a ''128-frame loop'' ranging from 0 to 127, starting at the ''starting offset''.

'''00000000 0000MMMM MMMMLOOO OOOOOOOO'''

'''MMMMMMMM'''

Loopmask. Each frame in the 128-sized loop will be masked by this value. For example, a value of 0x3 would result in a subloop of 4 frames that is repeated 32 times within the 128 frame-sized loop:
{| class="article-table"
!Frame index (bin)
!Loopmask (bin)
!Step/played texture information (bin)
|-
|0000000
|0000011
|Starting offset + 00
|-
|0000001
|0000011
|Starting offset + 01
|-
|0000010
|0000011
|Starting offset + 10
|-
|0000011
|0000011
|Starting offset + 11
|-
|0000100
|0000011
|Starting offset + 00
|-
|0000101
|0000011
|Starting offset + 01
|-
|0000110
|0000011
|Starting offset + 10
|-
|0000111
|0000011
|Starting offset + 11
|-
|.........
|.........
|.........
|-
|.........
|.........
|.........
|-
|1111110
|0000011
|Starting offset + 10
|-
|1111111
|0000011
|Starting offset + 11
|}
There is a great variety of loops to be made with this mechanism.

'''L'''

Leapflag: when set, this flag makes the offset refer to another 32-bit structure inside the 7th item in scenery and/or the 5th item in models. The eventual texture uses the offset of the structure that does not refer to another one, like a childnode relating to a leafnode.

'''000000000000'''

Unused?
[[Category:Crash 2/3]]

Subsystem

2019-04-27T17:44:39Z

Chekwob: 6 revisions imported: Initial import from Wikia

A subsystem is a self-contained system within a larger system. In each of the Crash games, there exist a number of different subsystems. Each subsystem handles a different aspect of the game's function. Many of these subsystems are associated with the type of entry that they primarily operate upon. In fact, an entry's type is just the ID of the subsystem that operates upon its data; thus, both terms entry type and subsystem ID are inclusively interchangeable with subsystem type.

== Subsystem Table ==
Each of the Crash games has a subsystem table. Each entry in the subsystem table contains a 4 character acronym or identifier string, and a number of callback functions specific to the subsystem with that identifier.

=== Location ===
The subsystem table is located at the following addresses in each of the Crash games:
* Crash 1 - <code>0x514DC</code>

=== Structure ===
The subsystem table has the following structure in each of the Crash games, with the exception that Crash 2 (and 3?) omit the last callback, <code>(*deinit)()</code>:

<syntaxhighlight lang="cpp">
struct subsystem
{
char name[4];
unsigned long pad;
void (*init)();
void (*postinit)();
void (*onload)(entry*);
void (*onfree)(entry*);
void (*deinit)();
} subsystems[NS_COUNT_SUBSYSTEMS];
</syntaxhighlight>

==== Subsystem name ====
Each subsystem specifies a 4 character acronym as its name. See below for a list of the subsystem names in each game.

==== Callbacks ====
Each entry in the subsystem table may or may not specify the following callbacks:
* <code>init</code> - Called during subsystem initialization to initialize this subsystem
* <code>postinit</code> - Called during subsystem initialization after...
* <code>onload</code> - Called after an entry of this subsystem type is paged into memory
* <code>onfree</code> - Called after an entry of this subsystem type is loaded out of memory
* <code>deinit</code> - Called during subsystem deinitialization (Crash 1 only)
The <code>init</code> and <code>postinit</code> callbacks of each subsystem are called during Paging and Subsystem Initialization; each of these callbacks refers to a routine that initializes its associated subsystem.
...
All together, a subsystem's callbacks simulate 5 polymorphic functions that would otherwise override a subsystem base class's virtual functions of the same name.

== Subsystem names ==

=== Crash 1 ===
There are a total of 21 subsystems in Crash 1.

Note that entries of type 0 do not exist. For this reason, the first subsystem has the name NONE.

Bolded entries in the table indicate that (while the subsystem exists) there do not exist entries of that subsystem type in any NSF file.
{| class="article-table" border="1" cellspacing="0" rules="NONE" cols="3"
! align="LEFT" height="47" width="69" |ID
! align="LEFT" width="67" |Name
! align="LEFT" width="215" |Proposed Unabbreviated Name/Entry Content Description
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="0" |'''0'''
| align="LEFT" |'''NONE'''
| align="LEFT" |'''None'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="1" |1
| align="LEFT" |SVTX
| align="LEFT" |Object Model Vertices/Animation
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="2" |2
| align="LEFT" |TGEO
| align="LEFT" |Object Model Polygons
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="3" |3
| align="LEFT" |WGEO
| align="LEFT" |World Geometry
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="4" |4
| align="LEFT" |SLST
| align="LEFT" |Display List
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="5" |5
| align="LEFT" |TPAG
| align="LEFT" |Texture Page
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="6" |6
| align="LEFT" |LDAT
| align="LEFT" |Level Data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="7" |7
| align="LEFT" |ZDAT
| align="LEFT" |Zone Data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="8" |'''8'''
| align="LEFT" |'''CPAT'''
| align="LEFT" |'''Color Palette'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="9" |'''9'''
| align="LEFT" |'''BINF'''
| align="LEFT" |'''Binary File'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="10" |'''10'''
| align="LEFT" |'''OPAT'''
| align="LEFT" |'''Object/Process Allocation Table'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="11" |11
| align="LEFT" |GOOL
| align="LEFT" |GOOL Executable
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="12" |12
| align="LEFT" |ADIO
| align="LEFT" |Audio
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="13" |13
| align="LEFT" |MIDI
| align="LEFT" |Music
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="14" |14
| align="LEFT" |INST
| align="LEFT" |Instruments
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="15" |15
| align="LEFT" |IMAG
| align="LEFT" |Image Data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="16" |'''16'''
| align="LEFT" |'''LINK'''
| align="LEFT" |'''Link to another entry?'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="17" |17
| align="LEFT" |MDAT
| align="LEFT" |Map Data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="18" |18
| align="LEFT" |IPAL
| align="LEFT" |Palettes for fading transitions
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="19" |19
| align="LEFT" |PBAK
| align="LEFT" |Demo playback
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="20" |20
| align="LEFT" |CVTX
| align="LEFT" |Cutscene Model Vertices/Animation
|}

=== Crash 2 ===
There are a total of 22 subsystems in Crash 2.

Note that entries of type 0 do not exist. For this reason, the first subsystem has the name NONE.

Bolded entries in the table indicate that (while the subsystem exists) there do not exist entries of that subsystem type in any NSF file.
{| class="article-table" border="1" cellspacing="0" rules="NONE" cols="3"
! align="LEFT" height="47" width="69" |ID
! align="LEFT" width="67" |Name
! align="LEFT" width="215" |Proposed Unabbreviated Name/Entry Content Description
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="0" |'''0'''
| align="LEFT" |'''NONE'''
| align="LEFT" |'''None'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="1" |1
| align="LEFT" |SVTX
| align="LEFT" |Object Model Vertices/Animation
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="2" |2
| align="LEFT" |TGEO
| align="LEFT" |Object Model Polygons and Textures
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="3" |3
| align="LEFT" |WGEO
| align="LEFT" |World Geometry
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="4" |4
| align="LEFT" |SLST
| align="LEFT" |Display List
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="5" |5
| align="LEFT" |TPAG
| align="LEFT" |Texture Page
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="6" |'''6'''
| align="LEFT" |'''LDAT'''
| align="LEFT" |'''Level Data'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="7" |7
| align="LEFT" |ZDAT
| align="LEFT" |Zone Data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="8" |'''8'''
| align="LEFT" |'''CPAT'''
| align="LEFT" |'''Color Palette'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="9" |'''9'''
| align="LEFT" |'''BINF'''
| align="LEFT" |'''Binary File'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="10" |'''10'''
| align="LEFT" |'''OPAT'''
| align="LEFT" |'''Object/Process Allocation Table'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="11" |11
| align="LEFT" |GOOL
| align="LEFT" |GOOL Executable
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="12" |12
| align="LEFT" |ADIO
| align="LEFT" |Audio
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="13" |13
| align="LEFT" |MIDI
| align="LEFT" |Music
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="14" |14
| align="LEFT" |INST
| align="LEFT" |Instruments
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="15" |15
| align="LEFT" |VCOL
| align="LEFT" |Special collision rules/map
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="16" |'''16'''
| align="LEFT" |'''LINK'''
| align="LEFT" |'''Link to another entry?'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="17" |'''17'''
| align="LEFT" |'''MDAT'''
| align="LEFT" |'''Map Data'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="18" |'''18'''
| align="LEFT" |'''IPAL'''
| align="LEFT" |'''Palettes for fading transitions'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="19" |19
| align="LEFT" |PBAK
| align="LEFT" |Demo playback
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="20" |20
| align="LEFT" |SDIO
| align="LEFT" |Speech audio
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="20" |21
| align="LEFT" |VIDO
| align="LEFT" |Sprite
|}
Note: LDAT entries for each level are mentioned in the NSD, meaning they were in the NSF at some point.
=== Crash 3 ===
There are a total of 22 subsystems in Crash 3.

Note that entries of type 0 do not exist. For this reason, the first subsystem has the name NONE.

Bolded entries in the table indicate that (while the subsystem exists) there do not exist entries of that subsystem type in any NSF file.
{| class="article-table" border="1" cellspacing="0" rules="NONE" cols="3"
! align="LEFT" height="47" width="69" |ID
! align="LEFT" width="67" |Name
! align="LEFT" width="215" |Proposed Unabbreviated Name/Entry Content Description
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="0" |'''0'''
| align="LEFT" |'''NONE'''
| align="LEFT" |'''None'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="1" |1
| align="LEFT" |SVTX
| align="LEFT" |Object Model Vertices/Animation
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="2" |2
| align="LEFT" |TGEO
| align="LEFT" |Object Model Polygons and Textures
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="3" |3
| align="LEFT" |WGEO
| align="LEFT" |World Geometry
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="4" |4
| align="LEFT" |SLST
| align="LEFT" |Display List
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="5" |5
| align="LEFT" |TPAG
| align="LEFT" |Texture Page
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="6" |'''6'''
| align="LEFT" |'''LDAT'''
| align="LEFT" |'''Level Data'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="7" |7
| align="LEFT" |ZDAT
| align="LEFT" |Zone Data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="8" |'''8'''
| align="LEFT" |'''CPAT'''
| align="LEFT" |'''Color Palette'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="9" |'''9'''
| align="LEFT" |'''BINF'''
| align="LEFT" |'''Binary File'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="10" |'''10'''
| align="LEFT" |'''OPAT'''
| align="LEFT" |'''Object/Process Allocation Table'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="11" |11
| align="LEFT" |GOOL
| align="LEFT" |GOOL Executable
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="12" |12
| align="LEFT" |ADIO
| align="LEFT" |Audio
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="13" |13
| align="LEFT" |MIDI
| align="LEFT" |Music
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="14" |14
| align="LEFT" |INST
| align="LEFT" |Instruments
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="15" |15
| align="LEFT" |VCOL
| align="LEFT" |Special collision rules/map
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="16" |'''16'''
| align="LEFT" |'''LINK'''
| align="LEFT" |'''Link to another entry?'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="17" |17
| align="LEFT" |RAWD
| align="LEFT" |Special data/raw data
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="18" |'''18'''
| align="LEFT" |'''IPAL'''
| align="LEFT" |'''Palettes for fading transitions'''
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="19" |19
| align="LEFT" |PBAK
| align="LEFT" |Demo playback
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="20" |20
| align="LEFT" |SDIO
| align="LEFT" |Speech audio
|-
| align="RIGHT" height="17" sdnum="1033;" sdval="20" |21
| align="LEFT" |VIDO
| align="LEFT" |Sprite
|}
Note: LDAT entries for each level are mentioned in the NSD, meaning they were in the NSF at some point.

TODO:Crash Bandicoot Hacking Wikia

2019-04-27T17:44:39Z

Chekwob: 4 revisions imported: Initial import from Wikia

==Remaining topics to discuss==
*[[Entry point|Entry Point]]
*[[Game Loop]]
*NS/Paging System
#EID encoding/decoding; determining type from EID string
#Filesystem Mapping?
#Entry Querying
#Page Operations
: a. Initialization/Deinitialization

:: i. [[Paging and Subsystem Initialization]]

:: ii. Paging and Subsystem Deinitialization

: b. Page Management

:: i. Page Allocation

: ii. Page Deallocation (free)

: iii. Page Creation

: iv. Page Deletion (truncatePages)

: c. Page Update

:: i. Update Page (single)

::: - incl Page Chunk Decompression/Initialization

::: - Chunk Decompress Routine

:: ii. Update Pages (global)

: - incl Update New Pages (called from level update when load new zone)

: iii. Update Page [chunk] Entries

: d. Page Search and Request/Open

: i. Search

: A. Find Hash Pair

: B. Find Page (that contains entry w/EID)

: ii. Request/Open

: A. Page Chunk

:: - Pages a single new page with req. CID, EID

: B. Page Entry

:: - Variant intended to page a single new page with req. entry w/EID; since paging the new page requires Updating Page Entries, which replaces the data fields of hash pairs for its entries with pointers to them, this returns a pointer to the resolved entry in its hash pair

: C. Open Entry

:: - Variant intended to increment read requests for an already paged page with req. entry w/EID;will page chunk if it does not exist; can optionally schedule paging the chunk with req. entry as part of a 'group' of contiguous chunks, during next page update

:: i) **Open Entry Given Container Chunk - also a variant, is just the bottom half of the open entry routine

: D. Close Entry

:: - Decrements read requests for an already paged page with req. entry w/EID;

: E. Unpage Chunk

:: - Clears the chunk's entry in the page map

: F. Close Entries and Unpage Chunk

:: - Closes chunk's n last opened entries, and unpages if all have been closed

: e. Page Queries

::: A. Get Number of Free or Available Pages

:: B. Get Number of Free or Available Pages With Specified List Entries

: f. Texture Pages

:: A. Unpage Texture Page

: g. Zone-Specific

:: A. Close Zone Entries and Unpage Zone Chunks

:: B. Unpage a Texture Page among Zone Entries [i.e. that is already paged]

:: Misc/incomplete

: a. Seek Disc to file

: b. Find Audio Page?

*Hardware Initialization

#Hardware Init Routine
#Hardware Deinit Routine

*Hardware Libraries

#Controller

:: a. Controller Initialization

:: b. Controller Read

: 2. GPU

:: a. GPU Initialization

:: b. GPU Deinitialization

:: c. GPU Shaders

:: d. GPU Driver

::: A. Clear Screen

::: B. Fill Screen w/Black Tile

::: C. Draw Sync

:::: - incl root counter callback

::: D. OT (prim list)

:::: i. Initialize OT

:::: ii. Get OT Pointer

::: E. Swap Buffers and Render Stage

::: F. Render Primitive

::: G. Game Rate Calculations

: 3. GFX

:: a. [Page] Texture Chunk to VRAM

:: b. Global Matrices

::: A. Set Projection and Screen Offset

::: B. Generate View Matrix, Rot, Angles, World Models, etc.

::: C. Generate Matrices for Map**

:: c. Global Light Matrices

::: A. Light Matrix Generation

:: d. Matrix Transformation Routine

:: e. Primitive Creation

::: A. Objects

:::: i. Object SVTX Primitive Creation

:::: - incl. 3 clipping-related routines

:::: - incl. 2 svtx vertex shading (light) routines

:::: - incl. assembly routine portion

:::: ii. Object CVTX Primitive Creation

:::: iii. Object Sprite Primitive Creation

:::: - incl. rotation assembly portion

:::: - incl. assembly routine portion

: iv. Object Font Primitive Creation
::::

::: B. [[World|Worlds]] (incomplete, format only partially explained)

:::: i. World Model Creation

:::: - incl also sub_8001A460?

:::: ii. World Primitive Creation

:::: - 7 Variations, incl 1 unused

:::: - incl. optimized world model copying

:::: - incl. assembly routine portion for each variation

:: f. Memory Card Images

::: A. 3 undocumented routines

:: g. Audio Matrix Generation (assembly portion)



-GOOL/Objects

: 1. [[OPAT|OPAT Initialization/Deinitialization]]

: 2. sub_8001AC60?

: 3. Object Hierarchy

:: a. Object Left-parent/Right-sibling desc.

:: b. Object Adoption

::: i. Add Child Object

::: ii. Remove Child Object

:: c) Object Traversal

::: i) General Traversal

:::: 1) Pre-order traversal with callback

:::: 2) Post-order traversal with callback

:::: 3) List handle pre-order traversal with callback

:::: 4) List handle post-order traversal with callback

::: ii) Object Find Traversal

:::: 1) Object Find traversal with callback

:::: - Callback routines: HasID, HasStateFlags

:::: 2) Object Find/Query traversal (no callback)

:::: - Find nearest object (incl. send asynchronously handled event-another routine)

: 4) Object Initialization, Creation, and Termination

:: a) Object Initialization

:: b) Object Creation

::: i) Process Object 'Creation'

::: ii) Entity Object Spawning

:: c) Object Termination

::: i) 3 Object Termination variants

::: ii) Mass Object Termination

: 5) Object Update

:: a) Object Trans Block Interpretation

:: b) Object Code Block Interpretation

:: c) Object Colors Update

:: d) Object Physics Update

:: - Object Paths

:: e) Object Primitive Creation

:: - Text Creation Routines

:: f) Object Bound Box Update

:: g) Object Bound Collision Registration

: 6) GOOL

:: a) Changing Object State

:: b) Sending Object Events

::: - incl. Object Collision Events

::: - incl. Broadcasting Events

:::: - Incl. nearest object query

:: c) [[GOOL Interpreter|Interpret Object]]

:: - incl. GOOL Reference Translation

:: - incl. Reading Control Pad

:: - See also geometric computations and calculations for objects



-Geometric Computations/Calculations

: 1) For Objects

:: a) Object Rotation

:: - 2 Variations

: 2) Seek

: 3) Distance

:: a) Euclidean distance

:: - in 3 space

:: - in XYZ plane

:: b) Manhattan distance

:: c) Absolute 1D distance

: 4) Angles

:: a) Angular distance

:: b) Angle in XZ plane (btwn 2 vectors)

:: c) Angle in YZ plane (btwn 2 vectors)

: 5) Vector Operations

:: a) Matrix Transformation

:: 2 variations... (1 for visual, 1 for audio)

:: b) 2D Projection

: 6) Collision Test

:: a) Test 2 3D spaces for a collision

:: b) Test point for containment by 3D space

:: c) Test 3D space given by 2 points for collision with another 3D space

: 7) General Math Functions

:: a) Sine

:: b) Cosine

:: c) Square Root

:: d) Atan2 (ratan2)

-GOOL Globals Initialization...

-Level

: 1) Initialization

:: - LDAT Initialization

:: - GOOL Globals Reset

:: - Load Universal Entries

:: - Create HUD + Level Restart (*sub_8002E98C)

::: (Level Restart Creates Crash Object)

: 2) Level Update

:: - Zone

::: A) Camera Path

:::: i) Progress

:::: - Update Sort List

::: - [[Camera Update]]

:: - incl update level misc

: 3) Level Current Zone Spawn Objects [outlier]

: 4) Level Save State

: 5) Level Restart

: 6) Level-Specific

:: a) Level Specific World Vertex Shader Parameter Initialization

:: b) Level Specific Audio Vector Parameter Initialization

-Camera

: 1) [[Camera Update]]

:: a) Camera Follow

::: A) Camera Get Projected Progress Non-forward

::: B) Camera Get Projected Progress Forward

::: C) Camera Adjust Progress (w/speed)

:: b) Other Camera Modes

::: A) Camera Calculate Progress

::: B) Other: todo

:: c) Death Camera

:: TODO

-[[Sort List]]

: 1) Format

: 2) Encoding/Decoding



-Solid Surface Collision

: 1) Node Querying

:: -(one routine calls query routine for each zone)

: 2) Translation

:: -incl smooth, pull, and stop at solid

:: a) Stopping at Floor

::: - incl. Finding Highest Object Below

::: - incl. Finding Average Y

:: b) Stopping at Walls

::: A) Wall Plot

:::: i) Initialization/Deinitialization (BINF)

:::: ii) Plotting a Wall

:::: - 2 Variations

:::: iii) Node Subdivision Wall Plotting

:::: iv) Object Sides Wall Plotting

:::: v) Zone Boundaries Wall Plotting

:::: vi) Testing the Wall Plot

::::: - Replotting Walls

:: c) Stopping at Ceiling

:: - incl. Finding Ceiling

:: d) Stopping at Bottom Zone Bounds

:: e) Node Death Events

:: - incl. Handle Nodes...

: 3) GOOL Operations

:: a) Vector Rebound

:: b) Closest Solid Thing Above/Below or in Front/Behind

:: c) Highest Solid Thing Above

:: d) TODO remaining

-Audio/MIDI

TODO

-Memory Card

TODO

-Misc

: 1) Demo Mode

:: a) PBAK initialization

:: b) Demo mode routine

:: c) 4 Random Number routines

Sort List Crash 2/3

2019-04-27T17:44:39Z

Chekwob: 6 revisions imported: Initial import from Wikia

== Introduction ==
The sort lists in Crash 2/3 are for the most part similar to the ones found in Crash 1. Therefore it is recommended to read [https://crash-hacking.wikia.com/wiki/Sort_List the extensive article about Sort Lists in Crash 1] first before reading this article.
== Format ==
=== Item 1/Item N: Main Source/Target List ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|List Size (polygon ID count)
|2 bytes
|c
|-
|0x2
|List Type
|2 bytes
|0
|-
|0x4
|Polygon IDs
|c x 2 bytes
|*
|}
==== Polygon ID ====
Each Polygon ID has the following format:

<code>*WWWSSPPPPPPPPPP</code>
* W = index of world model
* S = state of the polygon
* P = index of polygon in world model
Since scenery entries in Crash 2/3 have lists for both triangles and quads, the polygon state is used to differentiate between an index for a triangle (SS = 0) and a quad (SS = 1-3).

The polygon state also specifies whether to fully draw the quad or only half of it. A quad can be conceived as a combination of two triangles (ABC and CDA respectively) into a single polygon (ABCD). When only triangle ABC needs to be drawn, SS=1. Should only triangle CDA be drawn, SS=2. Finally, if the entire quad needs to be drawn, SS=3.
=== Item 2 to N-1: Difference List ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|List Size '''minus 2 '''(in hwords)
|2 bytes
|c + 2
|-
|0x2
|List Type
|2 bytes
|1
|-
|0x4
|Rel. Index of end of removing nodes '''minus 2'''Rel. Index of start of adding nodes '''minus 2'''
|2 bytes
|a + 2
|-
|0x6
|Rel. Index of end of adding nodes '''minus 2'''Rel. Index of start of swapping nodes '''minus 2'''
|2 bytes
|r + 2
|-
| colspan="4" |Nodes/List
|-
|0x8
|Removing Nodes
|(a - 2) x 2 bytes
|*
|-
|0x8 + ((a - 2) x 2)
|Adding Nodes
|(r-a-2) x 2 bytes
|*
|-
|0x8 + ((r - 2) x 2)
|Swapping Nodes
|(c-r-a-2) x 2 bytes
|*
|}
=== Adding/Removing Nodes ===
Adding and Removing nodes have the same format:

<code>CCCCNNNN NNNNNNNN (WWWSSPPP PPPPPPPP x (C+1))</code>
* <code>C</code> = add/skip count (this node contains C+1 polygon IDs, number of polygon IDs to add/skip)
* <code>N</code> = add/skip index (the polygon IDs from this node will be added to the new list in a progression, or skipped and not added in a retrogression)
* WSP = polygon ID(s) to add when inserting; other than in Crash 1 these polygon IDs in are the same as in the Source/Target lists since the copyflag functionality is abandoned in Crash 2/3.
=== Swapping Nodes ===

<code>Format A: 1BBBBAAA AAAAAAAA [01CCCCCC CCCDDDDD] </code>

<code>Format B: 0000AAAA AAAAAAAA 0000BBBB BBBBBBBB [01CCCCCC CCCDDDDD]</code>
* <code>A</code> = index of Polygon ID A
* <code>B</code> = index of Polygon ID B relative to A + 1
* <code>C</code> = index of Polygon ID C relative to A
* <code>D</code> = index of Polygon ID D relative to C + 17
Besides these swapping node formats familiair from Crash 1, there is another type of 'swapping node' in Crash 2/3 that accounts for the swapping of polygon states. They always come after the formats A - D, at the end of the difference list. The swapping is really a XOR-operation on the SS-value of the polygon ID that it refers to.

<code>Format E: 001XXPPP PPPPPPPP</code>
* X = XOR mask; the new polygon ID <code>WWW**PPP PPPPPPPP</code> = <code>WWW00PPP PPPPPPPP + ((SS^XX) << 11)</code>
* P = Targeted polygon index
[[Category:Crash 2/3]]

OPAT

2019-04-27T17:44:38Z

Chekwob: 1 revision imported: Initial import from Wikia

OPAT is the 10th subsystem in Crash 1. It concerns the allocation and initialization (and releasing) of all game objects. For this reason, a proposed name for its expansion is '''''O'''bject/'''P'''rocess '''A'''llocation '''T'''able''.

== Initialization routine ==
The OPAT initialization routine is located at the following addresses in each of the Crash games:
* 0x1AAD8

=== Object Allocation ===
This routine begins by allocating a block of memory for 96 objects with the malloc function (96 objects * 604 bytes/object = 57984 bytes). A pointer to the newly allocated memory is stored in <code>objects</code> of the GOOL subsystem namespace. <code>objects</code> now refers to a dynamically allocated array of 96 objects.

The routine then allocates a separate section of memory for the 97th object-the player object. An extra 256 bytes in addition to the standard 608 byte structure size (608+256 = 860) is allocated for the player object. This is to account for the higher number of activation records created and local 'registers' used by its lengthier, more complex code. A pointer to the newly allocated memory is stored in <code>player</code> of the GOOL subsystem namespace.

If either the memory for the objects or for the player object could not be allocated, the routine returns error code 0xFFFFFFF1.

=== Free List/Free Object Pool Initialization ===
At this point, all the necessary memory for objects has been allocated. The routine now initializes the <code>freelist</code> [list handle] object, marking it as a list handle by setting its <code>header</code> field to <code>2</code>. Note that a list handle object is not an actual object and only refers to a 'category' of objects, composed of its children.

Next the routine initializes and constructs a linked list of the 96 objects, marking each as a free object and assigning the first object as <code>children</code> of the <code>freelist</code> handle. This establishes a pool of free objects, initially consisting of all 96 objects. In detail, this is done by iterating through the first 95 objects, and for each object:
*setting its <code>header</code> field to <code>0</code>. This marks the object a free object.
*storing a pointer to the object that follows it [in the array] in its <code>sibling</code> field. (<code>objects[n].sibling = &objects[n+1];</code>) This establishes the link between objects. The 96th object does not have a following object so its sibling field is set to <code>0</code>.
*setting its <code>parent</code> field to point to the <code>freelist</code> handle. Each object in the free list is a child of the <code>freelist</code> handle, and the left-child right-sibling representation requires that an object always points to its parent object.
*setting its <code>children</code> field to <code>0</code>. Presence of a <code>children</code> and <code>sibling</code> field allow objects to have a left-child right-sibling k-ary tree of descendants, however this is irrelevant for free objects. Free objects do not have children and thus initialize their <code>children</code> field to <code>0</code>.
The <code>freelist</code> handle now refers to the category of free objects, and each of its children are an object in the pool.

=== Used Object List Initialization ===
Now the routine initializes 8 the used object list handles: <code>usedlists</code> (array). When the game eventually creates or spawns an object, a free object is adopted from the pool to one of the 8 used object list handles; the game then marks that object as an existing object (i.e. 'in use') and continues to perform its remaining instantiation. Initially, however, no object is in use-all 96 objects are free objects. Consequently, none of the used object list handles should have children. Initializing the 8 handles is then accomplished by iterating through them, and for each handle:
*setting its <code>header</code> field to <code>2</code>. This marks the handle [object] a list handle.
*setting its <code>children</code> field to <code>0</code>. The handle does not yet have children.
Eventually, the <code>usedlists</code> are used not only to 'contain' spawned or created objects, but also to categorize them into 8 distinct categories.

=== Player Object Initialization ===
Finally the routine initializes the player object. This is done by
*setting its <code>header</code> field to <code>0</code>. This marks the object a free object (**or rather, not in use)
*setting its <code>parent</code> field to <code>0</code>. The player object is treated separately from normal objects. Spawning the player does not require or involve adopting a free object from the pool; the player never belongs to and is never an object among the pool of free objects. Its data will always exist in the 860 byte region allocated for it, **in use or not. Thus it is not necessary for the player object to belong to any particular category and therefore have a parent at initialization.
*setting its <code>sibling</code> field to <code>0</code>. The player does not belong to a category and therefore does not have any sibling that could belong to a same category.
*setting its <code>children</code> field to <code>0</code>. The player object, though separate from the pool, is a free object and does not have children.

=== Return Success Code ===
At this point, the routine returns a success code (0xFFFFFF01).

=== Summary ===
<ol>
<li> For the <code>freelist</code> handle:
* set <code>type</code> field to <code>2</code> (the object is a list handle)
* set <code>children</code> field to point to <code>objects[0]</code>
<li> For the 96 allocated <code>objects</code>:
* set <code>type</code> field to <code>0</code> (the object is free/unused)
* set <code>sibling</code> field to point to the following object if not the last object:
<code>objects[n].process.sibling = &objects[n+1];</code>, else set <code>sibling</code> field to <code>0</code>
* set <code>parent</code> field to point to the <code>freelist</code> handle
* set <code>children</code> field to <code>0</code>
<li> For the 8 <code>usedlists</code> handles:
* set <code>type</code> field to <code>2</code> (the object is a list handle)
* set <code>children</code> field to <code>0</code> (no objects belong to it at init)
<li> For the <code>player</code> object:
* set <code>type</code> field to <code>0</code> (the object is free/unused)
* set <code>parent</code> field to <code>0</code> (not part of a category)
* set <code>sibling</code> field to <code>0</code> (no sibling in its non-existent category)
* set <code>children</code> field to <code>0</code>
</ol>

== Deinitialization routine ==
This routine simply releases the object memory allocated by the initialization routine:
* <code>free(objects);</code>
* <code>free(player);</code>

NSD

2019-04-27T17:44:38Z

Chekwob: 11 revisions imported: Initial import from Wikia

NSD (most likely to stand for '''N'''aughty Dog '''S'''oftware '''D'''ata or '''N'''aughty Dog '''S'''ystem '''D'''ata) is a custom file format created by Naughty Dog for use in the Crash games. The [[CD-ROM Directory Structure|root directory]] of a Crash game CD will have several sub-directories, with names S0, S1, S2, and S3; within these sub-directories are pairs of files with the name S00000**.NSD/.NSF. Each pair corresponds to a specific "level" in the game, and these files contain the game data for that level. An NSD file is essentially an index for its paired NSF file, but it also contains additional information such as a level descriptor/header and a loading screen descriptor.

== Format ==
=== Crash 1 Prototype ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Entry Hash Table Offsets
|4 bytes x 256
|*
|-
|0x400
|Chunk Count
|4 bytes
|c
|-
|0x404
|Entry Count
|4 bytes
|s
|-
|0x408
|Entry Hash Table
|4 bytes x 2 x s
|*
|}
Remaining data (object type --> executable EID type, level ID, initial zone EID and magic number) is stored inside an LDAT entry in the respective NSF file.
=== Crash 1 ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Entry Hash Table Offsets
|4 bytes x 256
|*
|-
|0x400
|Chunk Count
|4 bytes
|c
|-
|0x404
|Entry Hash Table Size
|4 bytes
|s
|-
|0x408
|Entry containing object type -> executable EID type(**)
|4 bytes
|*
|-
|0x40C
|Unknown
|4 bytes
|*
|-
|0x410
|Unknown
|4 bytes
|*
|-
|0x414
|Unknown
|4 bytes
|*
|-
|0x418
|Offset of Uncompressed Chunks
|4 bytes
|*
|-
|0x41C
|Compressed Chunk Count
|4 bytes
|*
|-
|0x420
|Compressed Chunk Offsets
|4 bytes x 64
|*
|-
|0x520
|Entry Hash Table
|4 bytes x 2 x s
|*
|-
|0x520 + (8 x s) + 0x0
|Level Header Magic Number
|4 bytes
|0x1
|-
|0x520 + (8 x s) + 0x4
|Level ID
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x8
|Initial Zone EID
|4 bytes
|*
|-
|0x520 + (8 x s) + 0xC
|Initial Camera Path (Camera Item Index)
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x10
|Unknown
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x14
|Object Type -> Executable EID map
|4 bytes x 64
|*
|-
|0x520 + (8 x s) + 0x118
|Misc images (loading screens, etc.)
|62720 bytes each image
|}
<nowiki>(**) - Possibly completely useless.</nowiki>

===Crash 2===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Entry Hash Table Offsets
|4 bytes x 256
|*
|-
|0x400
|Chunk Count
|4 bytes
|c
|-
|0x404
|Entry Count
|4 bytes
|s
|-
|0x408
|Entry containing object type -> executable EID type(**) (DAT?L where ? is the level's ID shortened to 1 character)
|4 bytes
|*
|-
|0x40C
|Unknown
|4 bytes
|*
|-
|0x410
|Unknown
|4 bytes
|*
|-
|0x414
|Unknown
|4 bytes
|*
|-
|0x418
|Unknown
|4 bytes
|*
|-
|0x41C
|Unknown
|4 bytes
|*
|-
|0x420
|Unknown
|4 bytes x 64
|*
|-
|0x520
|Entry Hash Table
|4 bytes x 2 x s
|*
|-
|0x520 + (8 x s)
|Number of spawn points present in the NSD
|4 bytes
|p
|-
|0x520 + (8 x s) + 0x4
|Unknown
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x8
|Level ID
|4 bytes
|*
|-
|0x520 + (8 x s) + 0xC
|Object count
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x14
|Object Type -> Executable EID map
|4 bytes x 64
|*
|-
|0x520 + (8 x s) + 0x1DC
|Spawn points (semi-optional, only starting spawn points are needed)
|24 bytes x p
|*
|-
|0x520 + (8 x s) + 0x1DC + (24 x p)
|Misc images (loading screens, etc.)
|62720 bytes each
|*
|}
<nowiki>(**) - Possibly completely useless.</nowiki>

===Crash 3===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Entry Hash Table Offsets
|4 bytes x 256
|*
|-
|0x400
|Chunk Count
|4 bytes
|c
|-
|0x404
|Entry Count
|4 bytes
|s
|-
|0x408
|Entry containing object type -> executable EID type(**) (DAT?L where ? is the level's ID shortened to 1 character)
|4 bytes
|*
|-
|0x40C
|Unknown
|4 bytes
|*
|-
|0x410
|Unknown
|4 bytes
|*
|-
|0x414
|Unknown
|4 bytes
|*
|-
|0x418
|Unknown
|4 bytes
|*
|-
|0x41C
|Unknown
|4 bytes
|*
|-
|0x420
|Unknown
|4 bytes x 64
|*
|-
|0x520
|Entry Hash Table
|4 bytes x 2 x s
|*
|-
|0x520 + (8 x s) + 0x0
|Spawn points present in the NSD count
|4 bytes
|p
|-
|0x520 + (8 x s) + 0x4
|Unknown
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x8
|Level ID
|4 bytes
|*
|-
|0x520 + (8 x s) + 0xC
|Object count
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x14
|Object Type -> Executable EID map
|4 bytes x 128
|*
|-
|0x520 + (8 x s) + 0x2DC
|Spawn points (optional, only starting spawn points are needed)
|24 bytes x p
|*
|-
|0x520 + (8 x s) + 0x2DC + (24 x p)
|Misc images (loading screens, etc.)
|62720 bytes each
|*
|}
<nowiki>(**) - Possibly completely useless.</nowiki>

== Structure ==

=== Crash 1 ===
<syntaxhighlight lang="cpp">
struct NSD
{
union
{
unsigned long entryhashoffsets[256];
unsigned long *entryhashbuckets[256];
}
unsigned long chunkcount;
unsigned long entryhashcount;
unsigned long unk_408;
unsigned long unk_40C;
unsigned long unk_410;
unsigned long unk_414;
unsigned long uncompressedoffset;
unsigned long compressedcount;
unsigned long compressedoffsets[64];
hashpair entryhash[entryhashcount];
struct levelheader
{
const unsigned long magic = ?
unsigned long levelID;
unsigned long firstzone;
unsigned long firstcampath;
unsigned long unknown;
unsigned long execeidmap[64];
};
};
</syntaxhighlight>

== Purpose ==
TBD

NSF

2019-04-27T17:44:38Z

Chekwob: 3 revisions imported: Initial import from Wikia

NSF is a custom file format created by Naughty Dog for use in the Crash games. The root directory of a Crash game CD will have several sub-directories, with names S0, S1, S2, and S3; within these sub-directories are pairs of files with the name S00000**.NSD/.NSF. Each pair corresponds to a specific "level" in the game, and these files contain the game data for that level. An NSF file contains all of the resources used by the level currently being played.

It only serves as a container for [[chunk]]s.
[[Category:Structure]]

Sort List

2019-04-27T17:44:38Z

Chekwob: 5 revisions imported: Initial import from Wikia

Sort Lists are delta encoded depth-sorted polygon lists. They are Type 4 entries. For each point in some camera path, a Type 4 entry encodes the depth order, when viewed from the position and orientation of the camera at that point, of all visible polygons in the [up to] 8 visible worlds of the path's parent zone. Each distinct camera path from a zone in the level refers to its own Type 4 entry. Thus, at every possible position and orientation of the camera, the painter's algorithm can be employed in rendering visible geometric content (worlds), given the corresponding decoded sort list.

== Introduction ==
Each zone specifies up to 8 individual worlds. Together, these worlds compose the geometric content visible to the player at all possible positions/orientations of the camera along the zone's paths. The representative worlds for that zone shall naturally be observed as the camera travels along its paths, through the 3-dimensional space occupied by the zone.

The camera at any instant is positioned (i.e. translated) at a particular point on its ''current path'' with index given by its ''current progress'' along that path. Each point in the path is also associated with an ''orientation angle ''to which the camera is additionally rotated when it reaches that progress. Since each of a zone's camera path's points are indexed by [each possible] progress [that can be attained within that path], each subsequent point describes a further location and orientation for the camera to reach as the player makes a single, +1 = positive change in progress. Thus, for each change in progress, there is a change to a new predefined/fixed orientation and location for the camera, at which all polygons that compose the zone's representative geometry will have exhibited a change in relative location [from the camera]. At the camera's new location and orientation, some of these polygons will have naturally changed ordering to appear ''in front'' of some other polygons that, at the camera's previous location, they appeared to be ''behind''. At this new location and orientation, there may also be some polygons that were previously ''off screen'' that should now be visible ''on screen''-and some polygons that were previously visible ''on screen'' that should now be ''off screen''.

The first and last items in a Sort List (Type 4) entry are important: they are the only purely raw, non-delta encoded polygon lists in the entry. Polygons are listed by ''Polygon ID. ''The first item in a Type 4 entry lists each visible polygon (belonging to the world models of the zone that contains the corresponding path) in sorted order from front to back when viewed from the camera position and orientation of the ''first'' camera path point (in the corresponding path). Conversely, the last item in a Type 4 entry lists each visible polygon in sorted order from front to back when viewed from the camera position and orientation of the ''last ''camera path point (in the corresponding path)''.''

The items between the first and last items then ''encode ''the ''progressive changes'' in polygon ordering from the first to the last lists-hence the term ''delta encoding''. These items also encode'' ''the ''retrogressive changes'' in polygon ordering from the ''last to first'' lists. The encoding also specifies any new onscreen polygons not previously visible and any old polygons no longer visible from one polygon list to the next.

== Format ==

=== Item 1/Item N: Main Source/Target List ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|List Size (polygon ID count)
|2 bytes
|c
|-
|0x2
|List Type
|2 bytes
|0
|-
|0x4
|Polygon IDs
|c x 2 bytes
|*
|}

==== Polygon ID ====
Each Polygon ID has the following format:

<code>*WWWPPPPPPPPPPPP</code>
* W = index of world model
* P = index of polygon in world model
Thus, a polygon id refers to the ''P''th polygon of the ''W''th world model in the zone with a path that references this entry.

=== Item 2 to N-1: Difference List ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|List Size '''minus 2 '''(in hwords)
|2 bytes
|c + 2
|-
|0x2
|List Type
|2 bytes
|1
|-
|0x4
|Rel. Index of end of removing nodes '''minus 2'''Rel. Index of start of adding nodes '''minus 2'''
|2 bytes
|a + 2
|-
|0x6
|Rel. Index of end of adding nodes '''minus 2'''Rel. Index of start of swapping nodes '''minus 2'''
|2 bytes
|r + 2
|-
| colspan="4" |Nodes/List
|-
|0x8
|Removing Nodes
|(a - 2) x 2 bytes
|*
|-
|0x8 + ((a - 2) x 2)
|Adding Nodes
|(r-a-2) x 2 bytes
|*
|-
|0x8 + ((r - 2) x 2)
|Swapping Nodes
|(c-r-a-2) x 2 bytes
|*
|}
A difference list encodes ''changes'' in polygon ordering. Each change is encoded as a ''node''. Each node specifies an individual operation performed in modifying the ''current polygon list ''to reach the form of the decoded [difference] list''.''
* Polygon reordering is encoded in these items for processing as swap operations between polygons [polygon ids] in the current polygon list.
* Changes from onscreen to offscreen are encoded in these items for processing as the operation of removing polygons from the current polygon list.
* Changes from offscreen to onscreen are encoded in these items for processing as the operation of adding polygons to the current polygon list.
Each node can be 1 of 3 types: a swapping node, an adding node, or a removing node. All nodes of one type are stored contiguously, in a region separate from that of nodes of other types; thus, a difference list has a swapping node region, an adding node region, and a removing node region.

=== Adding/Removing Nodes ===
Adding and Removing nodes have the same format:

<code>SSSSNNNN NNNNNNNN (PPPPPPPP PPPPPPPP x (S+1))</code>
* <code>S</code> = add/skip count (number of polygon IDs to add/skip)
* <code>N</code> = add/skip index (relative to source point)
* <code>P</code> = polygon ID(s) to add when inserting
** These have the following format: <code>CWWWPPPPPPPPPPPP</code>
*** W = index of world model
*** P = index of polygon in world model
*** C = copy flag (determines whether the ID is included or excluded from the addition/removal)

A value of <code>0xFFFF</code> is sometimes used as an indicator of the last adding/removing node in a region, however this is not always the case. If a node with this value is encountered during processing of a region, it is simply skipped.

Adding nodes are sorted in ascending order by the indices into the current polygon list that they refer to.
* During a gain in progress (progression), an adding node is processed by ''adding'' its specified polygon ID, or sequence of polygon IDs, at the specified index within the current polygon list.
* During a loss in progress (retrogression), an adding node is processed as if it were a removing node-that is, by ''removing'' the specified ''number'' of polygon IDs (skip count), from the specified index (skip index) within the current polygon list.
Likewise, removing nodes are sorted in ascending order by the indices into the current polygon list that they refer to.
* During a gain in progress (progression), a removing node is processed by ''removing'' the specified ''number'' of polygon IDs (skip count), from the specified index (skip index) within the current polygon list.
* During a loss in progress (retrogression), a removing node is processed as if it were an adding node-that is, by ''adding'' its specified polygon ID, or sequence of polygon IDs, at the specified index within the current polygon list.

=== Swapping Nodes ===
<code>Format A: 1BBBBAAA AAAAAAAA [01CCCCCC CCCDDDDD] </code>

<code>Format B: 00**AAAA AAAAAAAA 00**BBBB BBBBBBBB [01CCCCCC CCCDDDDD]</code>

* <code>A</code> = index of Polygon ID A
* <code>B</code> = index of Polygon ID B relative to A + 1
* <code>C</code> = index of Polygon ID C relative to A
* <code>D</code> = index of Polygon ID D relative to C + 17

A swapping node is processed as a swap between the 2 respective polygon IDs A and B at the specified [possibly relative] indices. It may optionally be followed with up to one swapping node of the format <code>01CCCCCC CCCDDDDD</code>-this particular swapping node is processed as a swap between the 2 respective polygon IDs C and D at the specified indices (the first of which is relative to that specified in the preceding node).

(By using an optional follow-up node, the somewhat limited range of relative destination indices available for specification using only the standard format is extended, along with the range of relative source indices, provided that the source index is within a given range of that of the preceding node's.)

Whether during a progression or retrogression, a swapping node is processed as a swap between the 2 respective polygon IDs at the same 2 specified indices.

== Decoding ==
When a progress of 0 is attained in a path (i.e. the path is ''entered ''at the front), the corresponding source/target list (first item in the corresponding Type 4 entry) is copied in its entirety to overwrite the [game's] ''current polygon list''. Similarly, when a progress of ''n'' is reached, where ''n'' is the maximum progress that can be attained in the path, the corresponding source/target list (last item in the corresponding Type 4 entry) is copied in its entirety to overwrite the current polygon list. Both lists are raw polygon lists, so no decoding [and thus a direct copy] is involved.

Assuming that progress is made and that the camera does not retrogress and exit the path, the next possible progress that can be attained after the path is entered at its entrance point/after progress 0 is progress 1. However, the corresponding list item in the Type 4 entry (progress 1 = item 2 = second item) is not in the format of a raw source/target list: it is in the format of an ''encoded'' difference list. Then, ''that'' difference list determines how the current polygon list (which, after progress 0, contains the content of the first list=entrance point's corresponding source/target list) shall be ''modified'' to yield the polygon list that it (the difference list) encodes. When progress 2 is attained, the corresponding difference list then works on the modified list in further modification; this continues in the same trend for further progresses, such that when progress ''n''-1 is attained, the current polygon list has undergone enough modification that it is almost identical to the source/target list corresponding to progress ''n''=last list.

Assuming that progress is lost, i.e. the camera retrogresses, and that the camera does not progress and exit the path (at its exit point), the next possible progress that can be attained after the path is entered at its exit point/after progress ''n'' is progress ''n''-1. However, the corresponding list item in the Type 4 entry (progress ''n''-1'' ''= item ''n ''- 1 = second-to-last item) is not in the format of a raw source/target list: it is in the format of an ''encoded'' difference list. Then, ''that'' difference list determines how the current polygon list (which, after progress ''n'', contains the content of the last list=exit point's corresponding source/target list) shall be ''modified'' to yield the polygon list that it (the difference list) encodes. When progress ''n''-2 is attained, the corresponding difference list then works on the modified list in further modification; this continues in the same trend for nearer progresses, such that when progress 1 is attained, the current polygon list has undergone enough modification that it is almost identical to the source/target list corresponding to progress 0=first list.

The modification process consists of 2 stages: the first stage is a ''swapping stage'', and the second stage is a ''rebuilding stage''.
* During a progression, the swapping stage comes '''after''' the rebuilding stage
* During a retrogression, the swapping stage comes '''before''' the rebuilding stage

=== Swapping stage ===
The swapping stage begins by calculating the range of the swapping node region in the difference list; the beginning of the range-which is also the index of the first node in the region-is computed with (4+(r*2)), and the index of the last node in the list-which is also the index of the last node in the region-is computed with (4+(c-1)*2).

During a progression, the swapping stage works forward through the region, processing each node, starting with the first swapping node and ending with the last. During a retrogression, the swapping stage works backward through the region as it processes each node, starting with the last swapping node and ending with the first. The format section lists the possible swapping node formats and includes a description of how the nodes with those formats are processed. Ultimately, as a result of the swapping stage, the current polygon list will have undergone some rearrangement according to the swapping node specifications.

=== Rebuilding stage ===
The rebuilding stage begins by calculating the ranges of the adding and removing node regions, respectively, in the difference list.

The current polygon list is double-buffered: the game allocates 2 separate regions of memory for holding 2 separate polygon buffers; at any given time, one of these lists-the ''active polygon list''-is the current polygon list, and the other list is the ''inactive polygon list''.

At the start of the rebuilding stage, the ''current adding node'' and the ''current removing node'' are defined, respectively, as the first adding and removing nodes in the difference list. The ''current source point'' is then set to the beginning of [the list of polygon IDs in] the active/current polygon list, and the ''current insertion point'' is set to the beginning of [the list of polygon IDs in] the inactive display list.

Until the current source point reaches the end of the current polygon list, the following steps are repeated:
# If neither the current adding node nor the current removing node reference the node at the current source point, all polygon IDs from the source point to the polygon ID at the ''nearest'' index (smallest)-either that referred to by the current adding node or the current removing node-are copied to the inactive polygon list at the current insertion point.
# The current insertion point is then moved to the end of the polygon IDs that were copied ''to'' the inactive polygon list, and the current source point is moved to the end of the corresponding polygon IDs that were copied ''from'' [in] the active polygon list.
#* If the current adding node refers to the polygon ID at the nearest index (at the current source point), then ''that'' node is processed, effectively ''appending'' additional polygon IDs to the inactive polygon list at the current insertion point; the current insertion point is then moved to the end of the appended polygon IDs, and the current adding node is updated to the next adding node in the difference list.
#* If the current removing node refers to the polygon ID at the nearest index (at the current source point), then ''that'' node is processed, effectively ''skipping'' a number of polygon IDs by moving the source point ahead; the current removing node is then updated to the next removing node in the difference list.
#* If the current removing node and the current adding node both refer to [a polygon ID at] the same index, then both are processed as described above and updated to the next nodes in their respective regions.

=== Additional Notes ===
Note that, during a retrogression, adding nodes are processed as removing nodes and removing nodes are processed as adding nodes. Thus, ''the adding node region becomes the removing node region ''and'' vice-versa''. The difference lists are said to encode the changes from the first source/target polygon list to the last source/target polygon list progressively and retrogressively. Assuming the camera starts at the path's first/entrance/initial [progress] point, when progressing along the path to a new progress, some polygons at the initial progress that were not visible/off screen will become visible/on screen at the new progress and vice versa. After reaching the new progress, if the camera then retrogresses back to the initial progress, the ''same'' polygons that were added/that previously became visible should be removed, thus returning to their initial state of visibility (not visible), and the ''same'' polygons that were removed/that previously became off screen (not visible) should be added, thus returning to their initial visible, on screen state.

The same correlation can be made between a change in obstruction between polygons and a swap of their polygon IDs during a progression or retrogression. Given any 2 polygons such that one appears behind and then in front of the other (or vice versa), respectively, before and after a progression, they are the same 2 polygons such that one appears in front of and then behind the other (or vice versa) before and after a countering retrogression. Thus, whether during a progression or retrogression, a swapping node is processed as a swap between the 2 respective polygon IDs at the same 2 specified indices-that is, the same swap operation between the same 2 polygons is performed in either case. Note that, while a change in sort order via swap is equivalent to its counteractive operation, and thus the same swap operation is decoded for both progression and retrogression, a change in visibility via add is not equivalent to the counteractive remove and vice-versa, hence the differing decoding process from progression to retrogression and vice-versa for adding/removing nodes.

The usage of forward slash in ''source/target list'' indicates that, neither the first nor the last list in a Type 4 entry are strictly a source or target list. When entering a path at its entrance point (progress 0), if the camera continues to progress along the path, the source list = the first list (copied as the active polygon list) should ultimately reach the form of the target list = the last list, lists being the lists in the corresponding Type 4 entry. When entering a path at its exit point (progress ''n''), if the camera continues to retrogress back to the beginning of the path, the source list = the last list (copied as the active polygon list) should ultimately reach the form of the target list = the first list.

=== Conclusion ===
The decoding process will have accomplished creating a modified version of the active polygon list in the inactive polygon list, using the encoded difference list. The inactive polygon list is finally swapped with the active/current polygon list, thus redefining the current polygon list as the modified list.

During world model primitive creation and transformation, for each polygon ID in the current polygon list ''from the end to the beginning'', a representative 3-point polygon primitive is created (using the vertex data for the polygon with that ID, in one of the 8 current zone world models) and transformed accordingly; for each primitive created, its <code>tag</code> field is pointed to the representative primitive for the previous polygon [ID] in the list (when it is created). This creates a linked list of primitives starting with that created for the last polygon and ending with that created for the first. Since the polygon list sorts IDs by depth of their corresponding polygons, the primitive linked list sorts their corresponding primitives [by depth] from ''back to front''. During the rendering stage, the GPU then steps through this list, rendering each polygon primitive in the appropriately specified order from back to front.

== External Links ==
* https://news.ycombinator.com/item?id=9277569 - brief write-up on the sort lists

Paging and Subsystem Initialization

2019-04-27T17:44:38Z

Chekwob: 8 revisions imported: Initial import from Wikia

In the Crash games, Paging and Subsystem Initialization is the process of readying the system to transfer (page) game content from a specified NSF file on disc into main memory. Using the NSF file's paired NSD file or index, the process occupies a structure with all the information needed to effectively page its content.

== Routine Location ==
The Paging and Subsystem Initialization routine is located at the following addresses in each of the Crash games:
* Crash 1 - 0x15B58

== Paging System Structure ==
The Paging and Subsystem Initialization routine requires as its second argument a pointer to the resultant 'paging system structure'. As a result of the routine's execution, this structure is occupied with all the information needed to effectively page content from an NSF file. (The NSF file used is that of the level with ID specified in the first argument to the routine.)

=== Crash 1 ===
In Crash 1, a pointer to the 'global paging system structure'-located at <code>0x5C528-</code>is passed as the second argument in each call to the Paging and Subsystem Initialization routine.

==== Format ====
TBD

==== Structure ====
<syntaxhighlight lang="cpp">
struct pagingsystem
{
bool inited; // 0x5C528
unsigned long levelid; // 0x5C52C
void **entryhashindices; // 0x5C530
struct hashpair *entryhash; // 0x5C534
unsigned long ???; // 0x5C538
void *levelheader; // 0x5C53C
struct NSD *NSD; // 0x5C540
unsigned long ???; // 0x5C544
unsigned long NSFlocation; // 0x5C548
unsigned long flag; // 0x5C54C
unsigned long physicalpagecount; // 0x5C550
struct page physicalpages[22]; // 0x5C554
unsigned long virtualpagecount; // 0x5C91C
struct page virtualpages[38]; // 0x5C920
unsigned long pagecount; // 0x5CFA8
struct page *currentlypaging; // 0x5CFAC
void *itemlist; // 0x5CFB0
struct page *mostrecent8; // 0x5CFB4
unsigned long CIDpaging; // 0x5CFB8
struct page **pagemap; // 0x5CFBC
};
</syntaxhighlight>

== Operation ==
The <code>inited</code> flag is first checked to determine whether the paging system has previously been initialized (by this routine). If so, a success code is returned, for the paging system has already been successfully initialized. If not, the routine proceeds to initialize the paging system.

=== Locate and Load NSD file ===
At this point, a string for the specified level id's corresponding NSD filename is constructed by concatenating "S00000", the level id, and ".NSD".

A filesystem map exists, which maps NSD files, indexed by level id, to their corresponding sector position and file size on disc; this map has been created by the hardware initialization routine. The level id is used as an index into this table and the malloc routine is used to allocate space of the corresponding file size. The system then begins reading from disc at the corresponding sector position to the newly allocated space. A pointer to this data is saved in the <code>NSD</code> field of the paging system structure.

=== Record Entry Hash Pointers ===
With the NSD contents in main memory, pointers to its <code>entryhashoffsets</code> and <code>entryhash</code> arrays, respectively, are recorded in <code>entryhashbuckets</code> and <code>entryhash</code> of the paging system structure.

=== Record Level Header Pointer ===
At this point, a pointer to the NSD's <code>levelheader</code> must also be calculated since the preceding block of data in the file structure (i.e. the entry hash table) is of variable size. This pointer is calculated by adding the size of the entry hash table (<code>entryhashcount</code>) to its location (<code>entryhash</code>), and stored in <code>levelheader</code> of the paging system structure. [calculated without pointer arithmetic this is entryhash+(8*entryhashcount)]. The NSD's <code>levelheader</code> is a structure that specifies its corresponding level ID, the EID of the level's first zone(T7) entry and the index of the first camera path in that zone, an unknown value, and <code>execeidmap</code>-an array that maps object types to GOOL executable entries.

=== Initialize Entry Hash Table ===
The <code>entryhash</code> array, or entry hash table, is a list of key-value pairs. The <code>entryhashoffsets</code> array is a list of relative offsets into the <code>entryhash</code> array. Each offset locates the beginning (first pair) of a bucket in the open-addressing based entry hash table. At this point the routine calculates the corresponding absolute pointers by iterating through the 256 offset values and replacing them with <code>&entryhash[entryhashoffset[c]]</code> (where c is an iterator). <code>entryhashbuckets</code> of the paging system structure now refers to the updated array of pointers.

[[File:Hash2-0.png|left|thumb|635x635px]]

The universe of keys in the entry hash table is composed of all possible EIDs [of entries] from the NSF file. Initially, each slot in the table pairs an EID (key) with the CID (value) of the chunk that contains the entry with that EID. Thus, the table initially associates each entry with its parent chunk.

Eventually, a request will be made to page an entry's content into main memory. Throughout the game, this is done by specifying the EID of an entry with desired content as the argument in a call to the entry paging routine. The entry paging routine ultimately pages the chunk that contains the entry, rather than the entry alone. It accomplishes this by: <li>Calculating the EID's hash with the hash function: <code data-rte-washtml="1">(EID << 15) & 0xFF</code></li><li>Using the hash as an index into the <code>entryhashbuckets</code> pointer array to locate the associated bucket</li><li>Starting the search for the pair with key <code>EID</code> at the pointed index</li><li>Obtaining the accompanying <code>CID</code> value for the pair upon finding a match</li><li>Using the NSD to determine the sector position and/or size of the chunk with that CID</li><li>Reading from disc at the corresponding sector position to a free page </li>
With the chunk contents in main memory, the entry paging routine then locates the requested entry [within the chunk data] and returns a pointer.

=== Record NSF Location ===
At this point the level id is used as an index into the filesystem map at <code>0x5E03C</code> to determine the sector location of the current NSF file, and this is recorded in <code>NSFlocation</code> of the paging system structure.

=== Initialize Page Map ===
At this point, space is allocated for <code>chunkcount</code> pointers to page structures with malloc, and a pointer to the newly allocated space is stored in <code>pagemap</code> of the paging system structure. Each of these pointers is then initialized with the value <code>0xFFFFFFEE</code>, a constant identified as the ''null page pointer''. The page map, indexed by index of chunks in the NSF file (chunk index = <code>(CID >> 1)</code>), will eventually be used to map chunks to their associated page structures (once created.)

=== Initialize Subsystems ===
Next, the game's subsystems are initialized by iterating through the subsystem table and calling the <code>init</code> callback of each subsystem.

=== Allocate Pages ===
A physical page of memory is 64kb (0x10000 bytes) in size. At this point, the routine attempts to allocate space for at most 22 physical pages (22 x 0x10000 bytes) of memory-if there is not enough space then it continues to try for 21 pages, 20, and so on. The total number of physical pages allocated is then stored in <code>physicalpagecount</code>.

=== Initialize Pages ===

==== Physical Pages ====
The routine then initializes <code>physicalpagecount</code> of the reserved/statically allocated physical page structures (i.e. <code>physicalpages</code>) in the paging system structure. For each of the <code>physicalpagecount</code> structures, the <code>data</code> field is pointed to its own successively contiguous 64kb physical page of memory from the block allocated.

Each physical page structure now refers to its own 64kb physical page of memory, and each referenced physical page will eventually be used to contain a 64kb chunk for paging in from the NSF file.

In addition to determining the location of the physical page for the <code>data</code> field, initialization for each physical page structure also involves appropriately initializing the <code>state</code>, <code>rw</code>, <code>index</code>, and <code>requests</code> fields:

* <code>state</code> is set to 1; this is the initial state for the page structure and indicates that its page is a clean, blank slate page.
* <code>rw</code> is set to 1; this indicates some sort of page replacement mode
* <code>index</code> is set to the index of the physical page allocated to the page structure
* <code>requests</code> is set to 0; this indicates the number of unprocessed requests to read from the structure's page

==== Virtual Pages (?) ====
The routine then sets <code>virtualpagecount</code> to 38, and initializes all 38 reserved virtual page structures (<code>virtualpages</code>) in the paging system structure. These are initialized differently from physical page structures:

* <code>data</code> is set to 0; this indicates that the page structure does not reference a physical page of memory and consequently describes a virtual page
* <code>rw</code> is set to 0; this indicates some sort of page replacement mode and is different for virtual pages
* <code>index</code> is set to 0; this field is unused and therefore zeroed because the index of a physical page is irrelevant when no physical page has been allocated for this (virtual) page

=== Print Debug Message ===
When all pages have been allocated and initialized, the game writes to standard output a confirmation message with the number of physical pages allocated, i.e. <code>printf("Inited and Allocated %d pages\n", NSD.physicalpagecount);</code>

=== Initialize Texture and Wavebank Page Structures ===
At this point the game initializes 16 texture page structures and 8 wavebank page structures. These differ from normal physical page structures in that the memory they reference is located in video or sound hardware.

This section is TBD.

Object

2019-04-27T17:44:38Z

Chekwob: 5 revisions imported: Initial import from Wikia

In technical terms, an Object is an instance of a GOOL executable. From the player's point of view, it is an in-game entity with specific appearance, behavior, location, state, and a variety of other characteristics. For each frame, or approximately every 1/60th of a second of gameplay, an object's executable bytecode is interpreted by the GOOL interpreter. This bytecode instructs the interpreter to perform a specific sequence of operations that will ultimately render the object according to its changing characteristics. As a result, the player observes a lively, animated, and interactive enemy, box, collectible item, or whatever other kind of in-game object it may be.

== General ==
When the game wishes to create an object, it first specifies a source GOOL executable, and an object is created as an instance of that executable-much like how a process is created in relation to its source executable in an operating system. Probably the most important part of a GOOL executable is its compiled GOOL bytecode; the compiled GOOL bytecode of an executable that any given object is an instance of-or more simply the bytecode for that object-will be 'interpreted' by the GOOL bytecode interpreter routine. The GOOL bytecode interpreter routine will then operate according to the instructions it sees in the bytecode for that object.

== Format ==

=== Crash 1 ===
All objects in Crash 1, with the exception of the player object, are 604 (0x25C) bytes in size. The player object, 860 (0x35C) bytes in size, includes an additional 0x100 bytes of object memory to account for the higher number of activation records and local 'registers' created by its lengthier, more complex code.

==== Free and Existing Objects ====
Free Objects have a header value of 0. They are placed into a 'free object pool' until the game requests to create or spawn them into existence.

Existing Objects have a header value of 1. They are the actual objects 'in use' by the game and are created or spawned into existence from a free object.

Both variations have the following format:
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Header
|4 bytes
|!=2
|-
|0x4
|Process Type
|4 bytes
|*
|-
|0x8
|Bounding Box x1
|4 bytes
|*
|-
|0xC
|Bounding Box y1
|4 bytes
|*
|-
|0x10
|Bounding Box z1
|4 bytes
|*
|-
|0x14
|Bounding Box x2
|4 bytes
|*
|-
|0x18
|Bounding Box y2
|4 bytes
|*
|-
|0x1C
|Bounding Box z2
|4 bytes
|*
|-
|0x20
|Source GOOL Executable
|4 bytes
|*
|-
|0x24
|External GOOL Executable
|4 bytes
|*
|-
|0x28
|Parent Zone
|4 bytes
|*
|-
|0x2C
|State
|4 bytes
|*
|-
|0x30
|Light Source Matrix L11
|2 bytes
|*
|-
|0x32
|Light Source Matrix L12
|2 bytes
|*
|-
|0x34
|Light Source Matrix L13
|2 bytes
|*
|-
|0x36
|Light Source Matrix L21
|2 bytes
|*
|-
|0x38
|Light Source Matrix L22
|2 bytes
|*
|-
|0x3A
|Light Source Matrix L23
|2 bytes
|*
|-
|0x3C
|Light Source Matrix L31
|2 bytes
|*
|-
|0x3E
|Light Source Matrix L32
|2 bytes
|*
|-
|0x40
|Light Source Matrix L33
|2 bytes
|*
|-
|0x42
|Background Color R
|2 bytes
|*
|-
|0x44
|Background Color G
|2 bytes
|*
|-
|0x46
|Background Color B
|2 bytes
|*
|-
|0x48
|Light Color Matrix LR1
|2 bytes
|*
|-
|0x4A
|Light Color Matrix LR2
|2 bytes
|*
|-
|0x4C
|Light Color Matrix LR3
|2 bytes
|*
|-
|0x4E
|Light Color Matrix LG1
|2 bytes
|*
|-
|0x50
|Light Color Matrix LG2
|2 bytes
|*
|-
|0x52
|Light Color Matrix LG3
|2 bytes
|*
|-
|0x54
|Light Color Matrix LB1
|2 bytes
|*
|-
|0x56
|Light Color Matrix LB2
|2 bytes
|*
|-
|0x58
|Light Color Matrix LB3
|2 bytes
|*
|-
|0x5A
|Background Color Intensity R
|2 bytes
|*
|-
|0x5C
|Background Color Intensity G
|2 bytes
|*
|-
|0x5E
|Background Color Intensity B
|2 bytes
|*
|-
|0x60
|Self Link
|4 bytes
|this
|-
|0x64
|Parent
|4 bytes
|*
|-
|0x68
|Sibling
|4 bytes
|*
|-
|0x6C
|Children (head child)
|4 bytes
|*
|-
|0x70
|Creator
|4 bytes
|*
|-
|0x74
|Player
|4 bytes
|*
|-
|0x78
|Collider
|4 bytes
|*
|-
|0x7C
|Interrupter
|4 bytes
|*
|-
|0x80
|Trans x
|4 bytes
|*
|-
|0x84
|Trans y
|4 bytes
|*
|-
|0x88
|Trans z
|4 bytes
|*
|-
|0x8C
|Rotation y
|4 bytes
|*
|-
|0x90
|Rotation x
|4 bytes
|*
|-
|0x94
|Rotation z
|4 bytes
|*
|-
|0x98
|Scale x
|4 bytes
|*
|-
|0x9C
|Scale y
|4 bytes
|*
|-
|0xA0
|Scale z
|4 bytes
|*
|-
|0xA4
|Velocity x
|4 bytes
|*
|-
|0xA8
|Velocity y
|4 bytes
|*
|-
|0xAC
|Velocity z
|4 bytes
|*
|-
|0xB0
|Target Rotation y
|4 bytes
|*
|-
|0xB4
|Target Rotation x
|4 bytes
|*
|-
|0xB8
|Target Rotation z
|4 bytes
|*
|-
|0xBC
|Mode Flags A
or Angular Velocity y
|4 bytes
|*
|-
|0xC0
|Mode Flags B
or Angular Velocity x
|4 bytes
|*
|-
|0xC4
|Mode Flags C
or Angular Velocity z
|4 bytes
|*
|-
|0xC8
|Status Flags A
|4 bytes
|*
|-
|0xCC
|Status Flags B
|4 bytes
|*
|-
|0xD0
|Status Flags C
|4 bytes
|*
|-
|0xD4
|Subtype/Initial State
|4 bytes
|*
|-
|0xD8
|ID
|4 bytes
|*
|-
|0xDC
|Stack Pointer
|4 bytes
|*
|-
|0xE0
|Program Counter (ins. pointer)
|4 bytes
|*
|-
|0xE4
|Frame Pointer
|4 bytes
|*
|-
|0xE8
|Trans Block Program Counter
|4 bytes
|*
|-
|0xEC
|Event Block Program Counter
|4 bytes
|*
|-
|0xF0
|Head Block Program Counter
|4 bytes
|*
|-
|0xF4
|Various
|4 bytes
|*
|-
|0xF8
|Unknown
|4 bytes
|*
|-
|0xFC
|Frame Change Timestamp
|4 bytes
|*
|-
|0x100
|State Change Timestamp
|4 bytes
|*
|-
|0x104
|Animation Lag Counter
|4 bytes
|*
|-
|0x108
|Animation Sequence
|4 bytes
|*
|-
|0x10C
|Animation Frame
|4 bytes
|*
|-
|0x110
|Entity Spawned From
|4 bytes
|*
|-
|0x114
|Path Progress
|4 bytes
|*
|-
|0x118
|Path Length (point count)
|4 bytes
|*
|-
|0x11C
|Ground y
|4 bytes
|*
|-
|0x120
|State Flags
|4 bytes
|*
|-
|0x124
|Speed
|4 bytes
|*
|-
|0x128
|Display Mode
|4 bytes
|*
|-
|0x12C
|Unknown
|4 bytes
|*
|-
|0x130
|Timestamp of Most Recent Landing
|4 bytes
|*
|-
|0x134
|Velocity y at Most Recent Landing
|4 bytes
|*
|-
|0x138
|Z-Index
|4 bytes
|*
|-
|0x13C
|Event Received
|4 bytes
|*
|-
|0x140
|Camera Zoom Factor
|4 bytes
|*
|-
|0x144
|Target Rotation Angle YZ plane
|4 bytes
|*
|-
|0x148
|Collision Hot-Spot Clip Amount
|4 bytes
|*
|-
|0x14C
|Unknown
|4 bytes
|*
|-
|0x150
|Unknown
|4 bytes
|*
|-
|0x154
|Unknown
|4 bytes
|*
|-
|0x158
|Collision Node
|4 bytes
|*
|-
|0x15C
|Object Memory
|64 x 4 bytes
|*
|}

=== List Handle Objects ===
List Handle Objects have a header value of 2. They are not actual objects and instead used only to point to the head object in a list of (children) objects. For this reason their structure contains only 2 fields: the object header and a pointer to the list head object.
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Header
|4 bytes
|2
|-
|0x4
|Head Object of List
|4 bytes
|*
|}

== Structure ==

=== Crash 1 ===
<syntaxhighlight lang="cpp">
struct object;
struct dbllink
{
object *prev;
object *next;
unsigned long unk_8;
};

struct object
{
unsigned long header;
union
{
unsigned long proctype;
object *listchildren;
};
struct bound bound;
entry *local;
entry *external;
entry *zone;
unsigned long state;

union { struct slightmatrix colors;
struct slightmatrix lightmatrix; };
struct scolor color;
struct scolormatrix colormatrix;
struct scolor intensity;

object *self;
object *parent;
object *sibling;
object *children;
object *creator;
object *player;
object *collider;
object *interrupter;

union { struct vector vectors;
struct vector trans; };
struct angle rot;
struct vector scale;
union
{
struct vector velocity;
struct dbllink link;
};
struct angle targetrot;
union
{
struct angle angvelocity;
struct
{
unsigned long modeflagsa;
unsigned long modeflagsb;
unsigned long modeflagsc;
};
};

unsigned long statusa;
unsigned long statusb;
unsigned long statusc;
unsigned long subtype;
unsigned long id;
unsigned long *sp;
unsigned long *pc;
unsigned long *fp;
unsigned long *pctrans;
unsigned long *pcevent;
unsigned long *pchead;
union
{
unsigned long misc_flag;
object *misc_child;
entry *misc_entry;
unsigned long misc_memcard;
};
unsigned long unk_F8;
unsigned long stampanim;
unsigned long stampstate;
unsigned long animcounter;
unsigned long *animseq;
unsigned long animframe;

unsigned char *entity;
signed long pathprogress;
unsigned long pathcount;
signed long groundy;
unsigned long stateflags;
signed long speed;
unsigned long displaymode;
unsigned long unk_12C;
unsigned long stampland;
signed long landyvel;
unsigned long zindex;
unsigned long event;
signed long camzoom;
unsigned long approachyz;
signed long hotspotclip;
signed long unk_14C;
unsigned long unk_150;
unsigned long unk_154;
signed long node;
unsigned long memory[0x40];
};
</syntaxhighlight>

== Field Information ==

=== Header ===
The header field determines whether the object is free, existing, or a list handle:
{| class="article-table"
!Value
!Type
!Description
|-
|0
|Free Object
|An empty or previously terminated object that doesn't actually exist in the game. It has been placed into a 'free object pool' until created or spawned into existence.
|-
|1
|Existing Object
|An actual object 'in use' by the game and created or spawned into existence from a free object.
|-
|2
|List Handle Object
|Not an actual object; used only to point to the head object in a list of (children) objects.
|}

=== Process Type or List Head ===
* When the object is a List Handle, this field points to the head object in its referenced list.
* When the object is ''not'' a List Handle, this field is set to 3 after it is successfully created or spawned.
** note: after successful spawning, this field is actually set to the source entity's <code>proctype</code>. However, all entities appear to have a <code>proctype</code> of 3 (not confirmed**).

=== Bounding Box ===
An object's bounding box specifies the rectangular region of 3-dimensional space which it occupies. It encompasses the geometry rendered for the object's current frame of animation. It is specified by the 3-dimensional fixed-point coordinates of its upper left and lower right points relative to the object's location (which is typically positioned at the center point of the object's animation frame model), and is recalculated for each change in frame of animation.

Fields at offsets 0x8, 0xC, and 0x10, respectively, specify the relative x, y, and z coordinates of the object's upper left bounding box point. Fields at offsets 0x14, 0x18, and 0x1C, respectively, specify the relative x, y, and z coordinates of the object's lower right bounding box point.

=== Other fields... ===
TODO

=== Status Flags A ===
This field is the first bitfield in a sequence of 3 ''object status flag'' bitfields
{| border="1"

!Bit
!Indication/Purpose
!Additional
|-
|1
| object has been stopped by solid ground
| 

|-
|2
| ?
| 

|-
|3
|0 = object is progressing forward along its path

1 = object is progressing backward along its path
|path travelling objects only

|-
|4
|0 = object was rotating counter-clockwise

1 = object was rotating clockwise
|rotating objects only

|-
|5
| object is transitioning from travelling forward to backward/vice versa along its path
|path travelling objects only

|-
|6
| object has changed animation [i.e. first frame of animation]
|state change also assumes change in animation by setting this

|-
|7
|?
| 

|-
|8
| object has been hit from the bottom
| set when collision check does not pass?

|-
|9
| object is moving and not stopped by a wall
| 

|-
|10
| overrides the effect of displacement caused when bits 7 and 16 of status flags b are set, allowing the object to remain stationary
| 

|-
|11
| set when colliding with an octree node and it triggers event
| 

|-
|12
| cleared when spinning or changing direction, reset by sub_243A0
| 

|-
|13
| object has a collider [collider = object that collides with the object's bound volume, specifically after it is clipped of hotspotclip units from each of its faces]
|this bit tested by an object's GOOL code to determine whether another object [i.e. crash] collides with it, so it can send the 'kill' event (0x300)

|-
|14
| object is hitting a bounce box (for setting a higher acceleration)
| 

|-
|15
| set when bouncing on and breaking a box?
|

|-
|16
| object's bounding box needs recalculating
| 

|-
|17
| ?
|recipient process sets this bit when sent event 'crushed by boulder (and ?)' (0x1800, 0x1900)

|-
|18
| object has changed state
| 

|-
|19
| object is on the ground
| 

|-
|20
| ?
|boxes set this at the end of their init routine

|-
|21
| set right after bounce from box/enemy?
| 

|-
|22
| object is a solid object (or supported by a solid object?)
|

|-
|23 to 32
| ?
| 

|}

=== Status Flags B ===
This field is the second bitfield in a sequence of 3 ''object status flag'' bitfields

{| border="1"

!Bit
!Indication/Purpose
!Additional
|-
|1
| object rotates in XZ plane based on target rot angle (cleared during spin?)
|

|-
|2
| object rotates in XZ plane and approaches the opposite direction when travelling backwards along its path (i.e. spins 180 degrees when reaching either end of its path)
|for path travelling objects;
bit 3 must be set for this to take effect

|-
|3
| auto rotate mode
0 = auto banking along curves is outward

1 = a) auto banking along curves is inward

b) object rotates in XZ plane to face the direction of its path (if bit 2 is set, the object will additionally 'reverse' this direction when travelling its path backwards)
|path curve auto banking does not take effect unless bit 12 is set

|-
|4
| 0 = object position is only affected by velocity
1 = object is stopped by solid surfaces: floor, ceiling, walls, and tops/bottoms and sides of solid objects
|**NOTE: see bit 7

|-
|5
| object is collide-able (records space occupied by object and pointer to object in a pair during this frame)
|

|-
|6
| object y velocity is affected by gravity
|

|-
|7
| object displacement is handled by the physics engine:
'''if bit 4 = 0''': displacement is handled by only adding velocity to location (ex. of this is when enemies are killed and spun off into the distance); effect of this may be overridden if bit 10 of status flags a is set and object assumes the ground is at its initial y location (see bit 16)

'''if bit 4 = 1''': displacement is handled with the main collision routine (Crash object is the only object to ever have bit 4 set)
|bit 7 also allows bit 13, 15, and 16 to take effect

when bit 7 is clear, object displacement should be handled manually by the object's GOOL code

|-
|8
| object [speed, velocity, and angular velocity] is controlled with the controller
|

|-
|9
| object does not render
|ex. HUD offscreen, dying in water

|-
|10
| object is 2 dimensional
|

|-
|11
| text object has a backdrop
|

|-
|12
| object auto banks along path curves
|path travelling objects only

|-
|13
| object has air resistance? (causes angvelocity to act as a velocity cap on both pos and neg velocities of its [absolute] value)
| 

|-
|14
| object rotates in YZ plane to approach its target rot angle
|

|-
|15
| object treats XZ plane at Y given by field groundy as solid ground
|

|-
|16
| object assumes the ground is at, and field groundy is set to, its initial y location
|NOTE: object is not effectively 'stopped' at the ground without bits 7 and 15 set

|-
|17
| object is solid at the sides
|

|-
|18
| object is solid at the top?
|

|-
|19
| disable frustum culling?
|

|-
|20
| object optionally rotates in XZ plane to approach its target rot angle
|

|-
|21
| object is shaded based on its parent zone, using the zone's color matrices
|

|-
|22
|?
|

|-
|23
| overrides an initial test in determining the highest object below the source? adds an additional 0x19000 in ground offset calculation?
|guess: stacked object

|-
| 24
|?
|

|-
|25
| object can not be terminated
|

|-
|26
| always display and animate object
|

|-
|27
|?
|

|-
|28
|?
|

|-
|29
| object waits a number of frames until its next animation change/code block burst: may take precedence over 'wait' value from most recent suspending frame primitive (i.e. GOOL ANIM operation)
|also prevents the object from changing state

|-
|30
|?
|

|-
|31
|
|

|-
|32
| object is solid at the bottom?
|forces more elaborate screen culling check (based on object projected 2d area rather than projected 2d midpt)

|}

Memory Map

2019-04-27T17:44:37Z

Chekwob: 4 revisions imported: Initial import from Wikia

A memory map is essentially a table of associations between addresses in a binary executable and descriptions of the data and/or code they locate.

== Crash 1 ==
Currently incomplete.

=== Data ===
{| border="1"

|-
!Address
!Description
!Size
|-
| colspan="3" |TEXT segment data
|-
|0x10000
|"\S%X\\S%07X.NSD" - NSD filename format string (uppercase)
|16 x 1 byte
|-
|0x10010
|"%s%ss%07x.nsd" - NSD filename format string (lowercase)
|16 x 1 byte
|-
|0x10020
|"c:/src/willie/target/" - original codebase target directory string
|24 x 1 byte
|-
|0x10038
|"streams/" - streams directory string
|12 x 1 byte
|-
|0x10044
|"\S%X\\S%07X.NSF" - NSF filename format string (uppercase)
|16 x 1 byte
|-
|0x10054
|"%s%ss%07x.nsf" - NSF filename format string (lowercase)
|16 x 1 byte
|-
|0x10064
|"Inited and Allocated %d pages\n" - paging initialization confirmation debug string
|20 x 1 byte
|-
|0x10084
|jumptables - see Code section
|144 x 4 bytes
|-
|0x102C0
|unknown number sequence
|24 x 1 byte
|-
|0x102D8
|more jumptables - see Code section
|56 x 4 bytes
|-
|0x103B8
|"----stack pop\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x103C8
|"----stack push\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x103D8
|"-----ireg ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x103E8
|"-----null ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x103F8
|"-----sp-double ref\n" - GOOL interpreter debug string
|20 x 1 byte
|-
|0x1040C
|"-----stack ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x1041C
|"-----var ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x1042C
|"-----frac ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x1043C
|"-----int ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x1044C
|"-----pool ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x1045C
|"-----reg ref\n" - GOOL interpreter debug string
|16 x 1 byte
|-
|0x1046C
|"*************** gop %d\n" - GOOL interpreter debug string
|24 x 1 byte
|-
|0x10484
|"******************** return return %d\n" - GOOL interpreter debug string
|40 x 1 byte
|-
|0x104AC
|"********************running pop\n" - GOOL interpreter debug string
|36 x 1 byte
|-
|0x104D0
|"******************** state return %d\n" - GOOL interpreter debug string
|40 x 1 byte
|-
|0x104F8
|more jumptables - see Code section
|600 x 4 bytes
|-
|0x10E58
|"Damaged slot" - memory card string
|16 x 1 byte
|-
|0x10E68
|"PART %d OF %d" - memory card string
|16 x 1 byte
|-
|0x10E78
|"%s%s%02d%06d" - memory card string
|16 x 1 byte
|-
|0x10E88
|"BASCUS-94900" - memory card string
|16 x 1 byte
|-
|0x10E98
|"file descriptor is %d\n" - memory card string
|24 x 1 byte
|-
|0x10EB0
|"Crash (%d%%)" - memory card string
|16 x 1 byte
|-
|0x10EC0
|more jumptables - see Code section
|21 x 4 bytes
|-
|0x10F14
|"0123456789ABCDEF" - int to uppercase hex string conversion array
|20 x 1 byte
|-
|0x10F28
|"0123456789abcdef" - int to lowercase hex string conversion array
|20 x 1 byte
|-
|0x10F3C
|more jumptables - see Code section
|45 x 4 bytes
|-
|0x10FF0
|GPU and CD-ROM debug strings
|1404 bytes
|-
|0x1156C
|more jumptables - see Code section
|5 x 4 bytes
|-
|0x11580
|more CD-ROM and SPU debug strings
|296 bytes
|-
|0x116A8
|more jumptables -see Code section
|32 x 4 bytes
|-
|0x11728
|SEP sequence debug strings
|60 bytes
|-
| colspan="3" |CODE begins at 0x11764, ends at 0x514DC
|-
|0x514DC
| subsystem tables
|21 x 28 bytes
|-
|0x51728
| character table for EID decoding
|64 x 1 byte
|-
|0x51768
| zero vector
|3 x 4 bytes
|-
|0x51774
| texture regions map
|600 x 4 x 2 bytes
|-
|0x52A34
| pre-computed list of (x,y) byte pairs sorted by euclidean distance (for wall detection)
|152 x 2 x 1 byte
|-
|0x52B64
| structures describing player angle and displacement for each controller direction
|16 x 3 x 4 bytes
|-
|0x52C24
| structures describing player velocity for each state (on ground, in air, etc.)
|8 x 4 x 4 bytes
|-
|0x52CA4
|used by GOOL VECB
|4 x 4 bytes
|-
|0x52CB4
| percentages used to scale a monochromatic color for GOOL VECB subop. 1
|12 x 4 bytes
|-
|0x52CE4
|?
|16 x 1 byte
|-
|0x52CF4
| circle bitmap (used for wall detection)
|128 bytes (32x32 bits)
|-
|0x52D74
| ? (referenced by sub_8002EC68 TBD)
|84 x 4 bytes
|-
|0x52EC4
| array 1 (unknown)
|14 x 4 bytes
|-
|0x52EFC
|array 2 (unknown)
|10 x 4 bytes
|-
|0x52F24
|array 3 (unknown)
|11 x 4 bytes
|-
|0x52F50
|array 4 (unknown)
|11 x 4 bytes
|-
|0x52F88
|array 5 (unknown)
|19 x 4 bytes
|-
|0x52FD4
|array 6 (unknown)
|32 x 4 bytes
|-
|0x53054
|array of 6 pointers to the above arrays(referenced by sub_8002EC68 TBD)
|6 x 4 bytes
|-
|0x5306C
| sin/cosine table
|1042 x 2 bytes
|-
|0x53890
| reserved for various library (gpu and etc?) routines
|4876 bytes
|-
|*0x54A20
| pointer for generating the current drawing primitive packet
|4 bytes
|-
|0x54B9C
| square root table
|192 x 2 bytes
|-
|0x54D1C
| atan2 table
|2052 bytes
|-
|0x55520
| reserved for CD-ROM (and SPU?) routines
|3804 bytes
|-
| colspan="3" |global variables
|-
|0x563FC: gp[0]
| ?
|4 bytes

|-
|0x56400: gp[0x4]
| ?
|4 bytes

|-
|...
| 
|7 x 4 bytes

|-
|0x56420: gp[0x24]
| frame buffer destination X
|2 bytes

|-
|0x56422: gp[0x26]
| frame buffer destination Y
|2 bytes

|-
|0x56424: gp[0x28]
| frame buffer destination W (inited in binary with 0x100)
|2 bytes

|-
|0x56426: gp[0x2A]
| frame buffer destination H (inited in binary with 0x80)
|2 bytes

|-
|0x56428: gp[0x2C]
| quit game flag (will break game loop)
|4 bytes

|-
|...
|
|5 x 4 bytes

|-
|0x56440: gp[0x44]
| depth cuing matrix used by sub_80019F90
|32 bytes

|-
|0x56460: gp[0x64]
| ??used by sub_2EC68
|4 bytes

|-
|0x56464: gp[0x68]
| ??used by sub_2EC68
|4 bytes

|-
|0x56468: gp[0x6C]
| ??used by sub_2EC68
|4 bytes

|-
|0x5646C: gp[0x70]
| ??used by sub_2EC68
|4 bytes

|-
|0x56470: gp[0x74]
| ??used by sub_2EC68
|4 bytes

|-
|0x56474: gp[0x78]
| ??used by sub_2EBB4, also sub_19DE0 (wgeo transform routine variant)
|4 bytes

|-
|0x56478: gp[0x7C]
| ??used by sub_2EBB4, also sub_19DE0 (wgeo transform routine variant)
|4 bytes

|-
|0x5647C: gp[0x80]
| ??copied to stack and unused during path routine; inited with 0x80000000
|4 bytes

|-
|0x56480: gp[0x84]
| GOOL interpreter double buffer for const refs, pointer to scratch[0x40]
|4 bytes

|-
|0x56484: gp[0x88]
| index of active const buffer for gp[0x84]
|4 bytes

|-
|0x56488: gp[0x8C]
| GOOL interpreter double buffer for const refs (alt), pointer to scratch[0x40]
|4 bytes

|-
|0x5648C: gp[0x90]
| index of active const buffer for gp[0x8C]
|4 bytes

|-
|0x56490: gp[0x94]
| ? see LDAT postinit/253a0
|4 bytes

|-
|0x56494: gp[0x98]
| ? see LDAT postinit/253a0
|4 bytes

|-
|0x56498: gp[0x9C]
| "0b_pZ\0" string used by demo routine (extends to gp[0xA0])
|8 x 1 byte

|-
|0x564A0: gp[0xA4]
| ? flag that prevents resetting the spawn lists when the level is restarted
|4 bytes

|-
|0x564A4: gp[0xA8]
| amount of camera z trans due to 'lookback' (i.e. moving forward or backward)
|4 bytes

|-
|0x564A8: gp[0xAC]
| amount of camera z trans due to 'camzoom' of the nearest forward or backward camera path
|4 bytes

|-
|0x564AC: gp[0xB0]
| flag for camera 'lookback'
0 = camera is zoomed in (as player moves forward)

1 = camera is zoomed out (as player moves backward)
|4 bytes

|-
|0x564B0: gp[0xB4]
| flag for camera pan x
0 = camera is panned left (as player moves left)

1 = camera is panned right (as player moves right)
| 4 bytes

|-
|0x564B4: gp[0xB8]
| amount of camera y trans due to 'camzoom' of the nearest upward or downward camera path
|4 bytes

|-
|0x564B8: gp[0xBC]
| amount of camera x trans due to 'panx' (i.e. player moving left or right)
|4 bytes

|-
|0x564BC: gp[0xC0]
| ground offset (additional y distance from bottom of player, factored in determining its collision with solid underlying supportive octree nodes)
|4 bytes

|-
|...
|
|2 x 4 bytes
|-
|0x564C8:
gp[0xCC]
|? used by sub_8002EC68
|4 bytes
|-
|0x564CC:
gp[0xD0]
|? used by sub_8002EC68
|4 bytes
|-
|0x564D0
gp[0xD4]
|"lt1rA" (audio entry EID?) string used by sub_8002EC68
|8 x 1 byte
|-
|0x564D8:
gp[0xDC]
|?
|4 bytes
|-
|0x564DC: gp[0xE0]
| random seed (inited to 1)
|4 bytes

|-
|0x564E0: gp[0xE4]
| "CD001" string used by filesystem read routine (sub_8002F8C4)
|4 bytes

|-
|0x564E8
gp[0xEC]
|"." string used by filesystem read routine?
|4 x 1 byte
|-
|0x564EC
gp[0xF0]
|".." string used by filesystem read routine?
|8 x 1 byte
|-
|0x564E8
gp[0xF8]
|??
|4 bytes
|-
|...
|
|2 x 4 bytes
|-
|0x56500: gp[0x104]
| ? see mdat initb (inited with 1)
|4 bytes

|-
|0x56504: gp[0x108]
| "0b_pz" string (EID string for game over screen/zone)
|8 x 1 byte

|-
|0x5650C: gp[0x110]
| "0c_pz" string (EID string for main menu screen/zone)
|8 x 1 byte

|-
|0x56514: gp[0x118]
| "0d_pz" string (EID string for Naughty Dog screen/zone)
|8 x 1 byte

|-
|0x5651C: gp[0x120]
| "0e_pz" string (EID string for options/password/load game menu/zone)
|8 x 1 byte

|-
|0x56524: gp[0x128]
| "0f_pz" string (EID string for 6th zone in map model)
|8 x 1 byte

|-
|0x5652C: gp[0x130]
| "1e_pz" string (EID string for first island (before end) zone in map model)
|8 x 1 byte

|-
|0x56534: gp[0x138]
| "1a_pz" string (EID string for first island (at end/native fortress) zone in map model)
|8 x 1 byte

|-
|0x5653C: gp[0x140]
| "2b_pz" string (EID string for second island zone in map model)
|8 x 1 byte

|-
|0x56544: gp[0x148]
| "3a_pz" string (EID string for third island zone in map model)
|8 x 1 byte

|-
|0x5654C: gp[0x150]
| "0a_pz" string (EID string for Entertainment America & Universal Interactive Screens/zone)
|8 x 1 byte

|-
|0x56554: gp[0x158]
| "%cMapP" EID string to grab the entries in sequence used for palette fading
|8 x 1 byte

|-
|0x5655C: gp[0x160]
| "0MapP" EID string used to grab the first palette entry in sequence for a palette fade
|8 x 1 byte

|-
|0x56568:
gp[0x16C]
|? inited with 1
|4 bytes
|-
|0x5656C:
gp[0x170]
|? inited with -1
|4 bytes
|-
|0x56570:
gp[0x174]
|? inited with -1
|4 bytes
|-
|0x56574:
gp[0x178]
|"bu00:" string used by memory card routines
|8 x 1 byte
|-
|0x5657C:
gp[0x180]
|"%s%s" string used by memory card routines
|8 x 1 byte
|-
|0x56584:
gp[0x188]
|"*" string used by memory card routines
|4 x 1 byte
|-
|0x56588
gp[0x18C]
|"EMPTY" string used by memory card routines
|8 x 1 byte
|-
|0x56590
gp[0x194]
|"~inv!" string used by memory card routines
|8 x 1 byte
|-
|0x56598
gp[0x19C]
|_AllocRestBlockTop
|8 bytes
|-
|0x565A0
gp[0x1A4]
|_AllocMaxBlockSize
|8 bytes
|-
|0x565A8
gp[0x1AC]
|max_heap
|8 bytes
|-
|0x565B0
gp[0x1B4]
|AllocAreaFlag
|8 bytes
|-
|...
|
|3 x 4 bytes
|-
|0x565C0: gp[0x1C4]
| camera speed/most recent change in camera path progress
|4 bytes

|-
|...
|
|6 x 4 bytes

|-
|0x565DC: gp[0x1E0]
| small slope flag?
|4 bytes

|-
|....
|
|34 x 4 bytes

|-
|0x56664: gp[0x268]
| ? used by GOOL MSC
|4 bytes

|-
|..
|
|4 x 4 bytes

|-
|0x56678: gp[0x27C]
| ? see MDAT postinit
|4 bytes

|-
|...
|
|13 x 4 bytes

|-
|0x566AC: gp[0x2B0]
| wall cache: points to scratch[0x180]
|4 bytes

|-
|0X566B0: gp[0x2B4]
| EID of Crash GOOL executable entry
|4 bytes

|-
|0x566B4: gp[0x2B8]
| Crash object
|4 bytes

|-
|0x566B8: gp[0x2BC]
| SLST decoded buffer temp (used for swap)
|4 bytes

|-
|0x566BC: gp[0x2C0]
| SLST decoded back buffer (swapped with front buf, gp[0x304])
|4 bytes

|-
|...
|
|4 bytes

|-
|0x566C4: gp[0x2C8]
| event descriptor for '(software) memory card: end of i/o'
|4 bytes

|-
|0x566C8: gp[0x2CC]
| event descriptor for '(software) memory card: error happened'
|4 bytes

|-
|0x566CC: gp[0x2D0]
| event descriptor for '(software) memory card: timeout'
|4 bytes

|-
|0x566D0: gp[0x2D4]
| event descriptor for '(software) memory card: new device'
|4 bytes

|-
|...
|
|3 x 4 bytes

|-
|0x566E0: gp[0x2E4]
| points to memory allocated by MDAT; structure used by the title sequence
|4 bytes

|-
|0x566E4: gp[0x2E8]
| ? zeroed at LDAT postinit
|4 bytes

|-
|0x566E8: gp[0x2EC]
| ? zeroed at LDAT postinit
|4 bytes

|-
|0x566EC: gp[0x2F0]
| event descriptor for '(hardware) memory card: end of i/o'
|4 bytes

|-
|0x566F0: gp[0x2F4]
| event descriptor for '(hardware) memory card: error happened'
|4 bytes

|-
|0x566F4: gp[0x2F8]
| wall map: points to scratch[0x100]
|4 bytes

|-
|0x566F8: gp[0x2FC]
| event descriptor for '(hardware) memory card: timeout'
|4 bytes

|-
|0x566FC: gp[0x300]
| event descriptor for '(hardware) memory card: new device'
|4 bytes

|-
|0x56700: gp[0x304]
| SLST decoded front buffer (swapped with back buf, gp[0x2C0])
|4 bytes

|-
|0x56704: gp[0x308]
| some demo mode object?
|4 bytes

|-
|0x56708: gp[0x30C]
|?
|4 bytes

|-
|0x5670C: gp[0x310]
| points to scratch[0x380], circle bitmap is copied from 0x52CF4 to here during BINF init routine
|4 bytes
|-
|0x56710
| current level ID
|4 bytes
|-
|0x56714
| next level ID (for changing levels)
|4 bytes
|-
|...
|
|236 bytes
|-
| colspan="3" |DATA segment
|-
|0x56800
|?
|4 bytes
|-
|0x56804
| structures describing SPU hardware voices
|24 x 68 bytes
|-
|0x56E64
|more unknown SPU stuff
|472 bytes
|-
|0x5703C
|reserved by memory card routines
|24 bytes
|-
|0x57054
| reserved by controller routines
|324 bytes
|-
|0x57198
|reserved by CD-ROM routines
|180 bytes
|-
|0x5724C
|reserved by SPU routines
|20 bytes
|-
|0x5726C
|audio matrix?
|10 x 2 bytes
|-
|0x57280
| ? initially 0;
|4 bytes
|-
|0x57284
| ? initially 0;
|4 bytes
|-
|0x57288
| ? initially 0;
|4 bytes
|-
|0x5728C
| 8 wavebank entry EIDs (last 5 are inited to null EID by hardware init routine)
|8 x 4 bytes
|-
|0x572AC
|reserved by SPU routines
|1296 bytes
|-
|0x577BC
|reserved by malloc
|8 bytes
|-
| colspan="3" |***for hword matrices only first 9 hwords used, last 7 are padding for align to 32 bytes
|-
|0x577C4
| viewpoint rotation matrix (including translation by viewpoint translation vector)
|16 x 2 bytes
|-
|0x577E4
| viewpoint rotation matrix negated and scaled 5/8s for Y, negated for Z
|16 x 2 bytes
|-
|0x57804
| copy of 0x577E4 - 0x57804
|16 x 2 bytes
|-
|0x57824
| unknown matrix
|16 x 2 bytes
|-
|0x57844
| 0x57824 scaled 5/8 in the y and negated in the z OR a copy of 0x577E4 in certain case
|?
|-
|0x5785C
| z rotation matrix for a small angle, approximately 11 degrees OR weirdly rotated version of 577E4 in certain case
|?
|-
|0x57864
| camera x [initial value 0]
| 4 bytes
|-
|0x57868
| camera y [initial value 0]
| 4 bytes
|-
|0x5786C
| camera z [initial value 0x1F400]
| 4 bytes
|-
|0x57870
| camera x rotation angle [initial value 0]
| 4 bytes
|-
|0x57874
| camera y rotation angle [initial value 0]
| 4 bytes
|-
|0x57878
| camera z rotation angle [initial value 0]
| 4 bytes
|-
|0x5787C
| camera x scale? [initial value 0x1000]
|4 bytes
|-
|0x57880
| camera y scale? [initial value 0x1000]
|4 bytes
|-
|0x57884
| camera z scale? [initial value 0x1000]
|4 bytes
|-
|0x57888
| camera x @ last time zone flags bit 13 not set [initial value 0]
| 4 bytes
|-
|0x5788C
| camera y @ last time zone flags bit 13 not set [initial value 0xE1000]
| 4 bytes
|-
|0x57890
| camera z @ last time zone flags bit 13 not set [initial value 0x5DC000]
| 4 bytes
|-
|...
|
|24 bytes
|-
|0x578AC
| ? intially 0, cleared by projection routine
| 4 bytes
|-
|0x578B0
| ? initially 0
|2 bytes
|-
|0x578B2
| ? initially 0
|2 bytes
|-
|0x578B4
| ? initially 0x1000
|2 bytes
|-
|...
|
|12 bytes
|-
|0x578C4
| ? initially 0
|4 bytes
|-
|0x578C8
| ? initially 0
|4 bytes
|-
|0x578CC
| ? initially 0
|4 bytes
|-
|0x578D0
| projection distance (from viewer's eye)
|4 bytes
|-
|0x578D4
| starts hword matrix... initially 0x200
|2 bytes
|-
|0x578D6
| initially 0x200
|2 bytes
|-
|0x578D8
| initially 0x200
|2 bytes
|-
|0x578DA
| initially 0x200
|2 bytes
|-
|0x578DC
| initially 0x200
|2 bytes
|-
|0x578DE
| initially 0x200
|2 bytes
|-
|0x578E0
| initially 0x200
|2 bytes
|-
|0x578E2
| initially 0x200
|2 bytes
|-
|0x578E4
| initially 0x200
|2 bytes
|-
|...
|
|48 bytes
|-
|0x57914
| current zone (entry)
|4 bytes
|-
|0x57918
| previous zone header (zone item)
|4 bytes
|-
|0x5791C
| current camera path (zone item)
|4 bytes
|-
|0x57920
| current camera path progress
|4 bytes
|-
|...
|
|12 bytes
|-
|0x57930
| set to 0x57938 when zone flags bit 13 not set, else cleared
|4 bytes
|-
|0x57934
| camera x rotation after most recent adjustment/level update
|4 bytes
|-
|0x57938
| camera y rotation after most recent adjustment/level update
|4 bytes
|-
|0x5793C
| camera z rotation after most recent adjustment/level update
|4 bytes
|-
|0x57940
| camera x rotation before most recent adjustment/level update
|4 bytes
|-
|0x57944
| camera y rotation before most recent adjustment/level update
|4 bytes
|-
|0x59748
| camera z rotation before most recent adjustment/level update
|4 bytes
|-
|0x5794C
| sin(*(0x57930))/16;
|4 bytes
|-
|0x57950
| ?
|4 bytes
|-
|0x57954
| cos(*(0x57930))/16;
|4 bytes
|-
|...
|
|8 bytes
|-
|0x57960
| (active buffer?)
|4 bytes
|-
|...
|
|4 bytes
|-
|0x57968
| 4 byte string? cleared at loadLevel (demo mode sub uses this?)
|8 x 1 byte
|-
|0x57970
| set to *(0x34520) at loadLevel
|4 bytes
|-
|0x57974
| zone checkpoint state: player trans X
|4 bytes
|-
|0x57978
| zone checkpoint state: player trans Y
|4 bytes
|-
|0x5797C
| zone checkpoint state: player trans Z
|4 bytes
|-
|0x57980
| zone checkpoint state: player rotation Y? (rewritten with 0)
|4 bytes
|-
|0x57984
| zone checkpoint state: player rotation X? (rewritten with 0)
|4 bytes
|-
|0x57988
| zone checkpoint state: player rotation Z? (rewritten with 0)
|4 bytes
|-
|0x5798C
| zone checkpoint state: player scale X
|4 bytes
|-
|0x57990
| zone checkpoint state: player scale Y
|4 bytes
|-
|0x57994
| zone checkpoint state: player scale Z
|4 bytes
|-
|0x57998
| zone checkpoint state: current zone EID
|4 bytes
|-
|0x5799C
| zone checkpoint state: current camera path
|4 bytes
|-
|0x579A0
| zone checkpoint state: current camera path progress
|4 bytes
|-
|0x579A4
| zone checkpoint state: either level ID or MDAT/LDAT EID? (saved as 0x5c53c[4])
|4 bytes
|-
|0x579A8
| zone checkpoint state: flag
|4 bytes
|-
|0x579AC
| zone checkpoint state: copy of spawn flags list
|304 x 2 bytes
|-
|0x57E6C
| zone checkpoint state: boxes broken count
|4 bytes
|-
|0x57E70
|reserved for SPU routines
|212 bytes
|-
|0x57F40
| 8 x wavebank page structures
|8 x 44 bytes
|-
|0x580A0
| 16 x texture page structures
|16 x 44 bytes
|-
|0x58360
|reserved for SPU routines
|160 bytes
|-
|0x58400
| buffer count (2)
|4 bytes
|-
|0x58404
| buffer onscreen pointer
|4 bytes
|-
|0x58408
| buffer offscreen pointer
|4 bytes
|-
|0x5840C
| buffer onscreen (mirror?) pointer
|4 bytes
|-
|0x58410 - 0x5A497
| buffer onscreen
|136 bytes
|-
|0x5A498 - 0x5C51F
| buffer offscreen
|136 bytes
|-
|0x5C520
|reserved for SPU routines
|8 bytes
|-
| colspan="3" |paging system structure
|-
|0x5C528
| paging inited flag
|4 bytes
|-
|0x5C52C
| level ID (copied to 0x56710)
|4 bytes
|-
|0x5C530
| pointer to entry hash table bucket pointer array
| 4 bytes
|-
|0x5C534
| pointer to entry hash table
| 4 bytes
|-
|0x5C538
| pointer to (loading screen information from NSD?)
| 4 bytes
|-
|0x5C53C
| pointer to NSD level header
|4 bytes
|-
|0x5C540
| pointer to NSD (structure)
|4 bytes
|-
| 0x5C544
|?
|4 bytes
|-
|0x5C548
| current sector to read from disc
|4 bytes
|-
|0x5C54C
| flag: 0
|4 bytes
|-
|0x5C550
| physical page count
|4 bytes
|-
|0x5C554
| physical page structures
|22 x 44 bytes
|-
|0x5C91C
| virtual page count
|4 bytes
|-
|0x5C920
| virtual page structures
|38 x 44 bytes
|-
|0x5CFA8
| pages allocated
|4 bytes
|-
|0x5CFAC
| page structure of the destination page for the chunk currently being paged
|4 bytes
|-
|0x5CFB0
| pointer to a list of items?
|4 bytes
|-
|0x5CFB4
| most recent page structure set at case 8, and cleared at case 9
|4 bytes
|-
|0x5CFB8
| CID of the chunk that is currently being paged
|4 bytes
|-
|0x5CFBC
| CID->page stucture map (pointer)
|4 bytes
|-
|0x5CFC0
| CID of most recently compressed chunk?
|4 bytes
|-
|0x5CFC4
| reserved for SPU routines
|40 bytes
|-
|0x5CFEC
| surface collision/octree query data
|4176 or 0x1050 bytes
|-
|0x5E03C
| filesystem map
| 64 x 3 x 4 bytes
|-
|0x5E344
|spuVmMaxVoice
|4 bytes
|-
|0x5E348
| spawned level object list
| 256 x 2 bytes
|-
|0x5E548
|reserved for SPU routines
|6672 bytes
|-
|0x5FF58
| spawn list
|304 x 4 bytes
|-
| 0x60418
|reserved for MIDI/SPU routines
|2456 bytes
|-
|0x60DB0
| pointer to player object space(points to space allocated for playerobject)
|4 bytes
|-
|0x60DB4
| pointer to object space (points to space allocated for 96 objects)
|4 bytes
|-
|0x60DB8
| object list A handle
|8 bytes
|-
|0x60DC0
| object list B handle
|8 bytes
|-
|0x60DC8
| object list C handle
|8 bytes
|-
|0x60DD0
| object list D handle
|8 bytes
|-
|0x60DD8
| object list E handle
|8 bytes
|-
|0x60DE0
| object list F handle
|8 bytes
|-
|0x60DE8
| object list G handle
|8 bytes
|-
|0x60DF0
| object list H handle
| 8 bytes
|-
|0x60DF8
| free object list handle
|8 bytes
|-
|0x60E00
| most recently updated object
|4 bytes
|-
|0x60E04
| global game counter
|4 bytes
|-
|0x60E08-0x61887
| object space map
|96 x 28 bytes
|-
|0x61888
| object space map entry count
|4 bytes
|-
| colspan="3" |At 0x6188C starts global variables for GOOL objects
|-
|0x6188C [0x00]
| initialized with level ID in left 3 bytes (by OPAT)
|4 bytes
|-
|0x61890 [0x01]
| ...?
|4 bytes
|-
|0x61894 [0x02]
| screen Y offset base?
|4 bytes
|-
|0x61898 [0x03]
| ...used by the other drawing modes
|4 bytes
|-
|0x6189C [0x04]
| copied to global render/animate flags (bit 3 & 4 set right before title screen fade in) (see mdat postinit)
|4 bytes
|-
|0x618A0 [0x05]
| ? (level reload count?)
|4 bytes
|-
|0x618A4 [0x06]
| instance of DispC state 1
|4 bytes
|-
|0x618A8 [0x07]
| instance of DispC state 0
|4 bytes
|-
|0x618AC [0x08]
| instance of DispC state 0x27, set for ripper roo (level)
|4 bytes
|-
|0x618B0 [0x09]
| global render/animate flags
|4 bytes
|-
|0x618B4 [0x0A]
| ? modified by sub_8002BAB4, called at beginning of sub_8002B2BC (handles Crash 'woah' death sequence)
|4 bytes
|-
|0x618B8 [0x0B]
| ? global central Z of illumination for object brightness?
|4 bytes
|-
|0x618BC [0x0C]
| instance of DispC state 4 (pause menu)
|4 bytes
|-
|0x618C0 [0x0D]
| used by FruiC, incremented (fruit to HUD collection path interpolation factor?)
|4 bytes
|-
|0x618C4 [0x0E]
| instance of DispC state 5
|4 bytes
|-
|0x618C8 [0x0F]
| mirror of 0x57930; used by aku, and fruit for some y positioning
|4 bytes
|-
|0x618CC [0x10]
| aku aku stores pointer to itself here (17A14)
|4 bytes
|-
|0x618D0 [0x11]
| ? set to 0x100 by camera routine for cam mode 0, (5, 6 level); set to 6 by DispC
| 4 bytes
|-
|0x618D4 [0x12]
| title mode buffer? set by DispC
|4 bytes
|-
|0x618D8 [0x13]
|?
|4 bytes
|-
|0x618DC [0x14]
| game progress (0x63 initial progress before start game), (0x1F full completion, i.e. 31+1
| 4 bytes
|-
|0x618E0 [0x15]
|?
|4 bytes
|-
|0x618E4 [0x16]
|?
|4 bytes
|-
|0x618E8 [0x17]
|?
|4 bytes
|-
|0x618EC [0x18]
| init 0; incremented by FruiC (fruit or live counter?)
|4 bytes
|-
|0x618F0 [0x19]
| init 0
|4 bytes
|-
|0x618F4 [0x1A]
| init 0
|4 bytes
|-
|0x618F8 [0x1B]
| init 0
|4 bytes
|-
|0x618FC [0x1C]
| init 0
|4 bytes
|-
|0x61900 [0x1D]
| init 0
|4 bytes
|-
|0x61904 [0x1E]
| set to zone flags when loading a new zone
|4 bytes
|-
|0x61908 [0x1F]
| loaded from mem card routine... used by?
|4 bytes
|-
|0x6190C [0x20]
| loaded from mem card routine... used by?
|4 bytes
|-
|0x61910 [0x21]
| loaded from mem card routine... used by?
|4 bytes
|-
|0x61914 [0x22]
| loaded from mem card routine... used by?
|4 bytes
|-
|0x61918 [0x23]
| loaded from mem card routine... used by?
|4 bytes
|-
|0x6191C [0x24]
| pointer to tnt explosion object (if event spawns it)
|4 bytes
|-
|0x61920 [0x25]
| camera x (0x57864) mirror
|4 bytes
|-
|0x61924 [0x26]
| camera y (0x57868) mirror
|4 bytes
|-
|0x61928 [0x27]
| camera z (0x5786C) mirror
|4 bytes
|-
|0x6192C [0x28]
| camera rot y (0x57870) mirror
|4 bytes
|-
|0x61930 [0x29]
| camera rot x (0x57874) mirror
|4 bytes
|-
|0x61934 [0x2A]
| camera rot z (0x57878) mirror
|4 bytes
|-
|0x61938 [0x2B]
| previous game loop iteration execution time minus VSync time (checked by aku aku, also GemsC and WarpC)
|4 bytes
|-
|0x6193C [0x2C]
| screen x offset (used as arg in call to SetGeomOffset) initially 0, cleared by projection init routine
|4 bytes
|-
|0x61940 [0x2D]
| screen y offset (used as arg in call to SetGeomOffset, after adding initial y offset value at 0x2 << 8) initially 0
|4 bytes
|-
|0x61944 [0x2E]
| set by memory card data load routines, checked by BoxsC, or FruiC, along with game progress at 0x14
|4 bytes
|-
|0x61948 [0x2F]
| maximum initial Z position for entities spawned during title sequences
|4 bytes
|-
|...
|
|4 bytes
|-
|0x61950 [0x31]
| cleared when an event is sent to a TNT explosion fragment object
|4 bytes
|-
|...
|
|4 x 4 bytes
|-
|0x61964 [0x36]
| ? aku aku sets this to 0; also sets to point to itself in certain conditions
|4 bytes
|-
|...
|
|5 x 4 bytes
|-
|0x6197C [0x3C]
| incremental value set by DispC [0x3C]
|4 bytes
|-
|....
|
|4 bytes
|-
|0x61984 [0x3E]
| box count/number of boxes broken
|4 bytes
|-
|0x61988 [0x3F]
| read by GemsC (gems collected?)
|4 bytes
|-
|....
|
|4 bytes
|-
|0x61990 [0x41]
| timestamp of most recent gem render?
|4 bytes
|-
|...
|
|4 bytes
|-
|0x61998 [0x43]
| cleared when a new zone is loaded
|4 bytes
|-
|0x6199C [0x44]
| debug flag (set in prototype?)
|4 bytes
|-
|0x619A0 [0x45]
| ID of most recently hit checkpoint box; when not -1 or 0 and saving state, vector at 0x61A24 recorded in place of objects trans
| 4 bytes
|-
|...
|
|2 x 4 bytes
|-
|0x619AC [0x48]
| ? read by GemsC, also BoxsC and FruiC
|4 bytes
|-
|...
|
|3 x 4 bytes
|-
|0x619BC [0x4C]
| points to self-instantiated DispC state 10
|4 bytes
|-
|...
|
|23 x 4 bytes
|-
|0x61A1C [0x64]
| set to 0xD00 by DispC
|4 bytes
|-
|...
|
|4 bytes
|-
|0x61A24 [0x66]
| trans vector of most recent broken checkpoint box; replaces object trans when saving state if flag 0x619A0 set
|3 x 4 bytes
|-
|...
|
|3 x 4 bytes
|-
|0x61A34 [0x6A]
| fade duration/counter?
|4 bytes
|-
|...
|
|9 x 4 bytes
|-
|0x61A5C [0x74]
| ?? set to 0 for each neighbor zone when loading a new zone
|4 bytes
|-
|0x61A60 [0x75]
| set/incremented by boxes when spawned; reset when loading a new zone for each neighbor zone
| 4 bytes
|-
|0x61A64 [0x76]
| ?? set to 0 for each neighbor zone when loading a new zone
|4 bytes
|-
|0x61A68
|_svm_okof1
|8 bytes
|-
|0x61A70
|_svm_okof2
|8 bytes
|-
|0x61A78
|heap
|* bytes
|}

List of game discs

2019-04-27T17:44:37Z

Chekwob: 1 revision imported: Initial import from Wikia

== Release discs ==

=== Crash 1 ===
{|
! Disc ID
! Region
|-
| [[SCUS-94900]]
| NTSC-U/C
|-
| [[SCES-00344]]
| PAL
|-
| [[SCPS-10031]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91057.

=== Crash 2 ===
{|
! Disc ID
! Region
|-
| [[SCUS-94154]]
| NTSC-U/C
|-
| [[SCES-00967]]
| PAL
|-
| [[SCPS-10047]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91092.

=== Crash 3 ===
{|
! Disc ID
! Region
|-
| [[SCUS-94244]]
| NTSC-U/C
|-
| [[SCES-01420]]
| PAL
|-
| [[SCPS-10073]]
| NTSC-J
|}

The NTSC-J release also appears as SCPS-91164 and SCPS-91318.

== Prerelease discs ==
(stub)

== Demo discs ==

{|
! Disc ID
! Region
! Name
|-
| [[PBPX-95007]]
| PAL
| Demo One EUROPE
|-
| [[PBPX-95008]]
| PAL
| Demo One EUROPE
|-
| [[SCED-00273]]
| PAL
| Autumn/Christmas Releases
|-
| [[SCED-00364]]
| PAL
| Crash Bandicoot / Supersonic Racers / Die Hard Trilogy / Broken Sword / F1
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00456]]
| PAL
| Demo One uk europe aus/nz
|-
| [[SCED-00457]]
| PAL
| Demo One german
|-
| [[SCED-00678]]
| PAL
| Euro Demo 13 GER
|-
| [[SCED-00777]]
| PAL
| Euro Demo 14 FRE
|-
| [[SCED-00823]]
| PAL
| Euro Demo 27
|-
| [[SCED-00936]]
| PAL
| Registered User Demo 02
|-
| [[SCED-00938]]
| PAL
| Essential Playstation IV
|-
| [[SCED-00986]]
| PAL
| Winter Releases - '97 demo 01
|-
| [[SCED-01049]]
| PAL
| Playstation Sampler / Nightmare Creatures / Kurushi / Rapid Racer / ...
|-
| [[SCED-01118]]
| PAL
| Euro Demo 25 fra
|-
| [[SCED-01120]]
| PAL
| Euro Demo 27 fra
|-
| [[SCED-01127]]
| PAL
| Euro Demo 10/98 ger
|-
| [[SCED-01128]]
| PAL
| Euro Demo 11/98 ger
|-
| [[SCED-01129]]
| PAL
| Euro Demo 12/98 ger
|-
| [[SCED-01139]]
| PAL
| Essential Playstation VIII
|-
| [[SCED-01141]]
| PAL
| Essential Playstation X
|-
| [[SCED-01148]]
| PAL
| Euro Demo 38
|-
| [[SCED-01150]]
| PAL
| Euro Demo 40
|-
| [[SCED-01229]]
| PAL
| PlayStation Kids
|-
| [[SCED-01230]]
| PAL
| Registered Users Demo 03
|-
| [[SCED-01385]]
| PAL
| Registered Users Demo
|-
| [[SCED-01441]]
| PAL
| Winter Releases '98
|-
| [[SCED-01570]]
| PAL
| Australian Summer Special
|-
| [[SCED-01636]]
| PAL
| Registered Users Demo
|-
| [[SCED-01713]]
| PAL
| M-6 PlayStation Demo fre
|-
| [[SCED-01739]]
| PAL
| Katalog Spezial Demo ger
|-
| [[SCED-01828]]
| PAL
| Euro Demo 54
|-
| [[SCED-01837]]
| PAL
| Euro Demo 06/99 GER
|-
| [[SCED-01860]]
| PAL
| Euro Demo 40 FRA
|-
| [[SCED-01861]]
| PAL
| Euro Demo 41 FRA
|-
| [[SCED-01988]]
| PAL
| Registered Users Demo 06
|-
| [[SCED-02122]]
| PAL
| OPSM Platinum Special Demo (All)
|-
| [[SCED-02327]]
| PAL
| The Best Games Ever
|-
| [[SCED-02570]]
| PAL
| M6 PlayStation - Best Of Kids Demo
|-
| [[SCED-02655]]
| PAL
| Euro Demo (France) 51
|-
| [[SCED-02851]]
| PAL
| OPSM Best Ever Ever Games Demo
|-
| [[SCED-03103]]
| PAL
| PlayStation Speziale Italia
|-
| [[SCED-03452]]
| PAL
| Euro Demo 75
|-
| [[SCED-03454]]
| PAL
| OPSM Demo 77
|-
| [[SCED-03472]]
| PAL
| Euro Demo Germany 09/01 Deutsch
|-
| [[SCED-03473]]
| PAL
| Euro Demo Germany 10/01 Deutsch
|-
| [[SCED-03790]]
| PAL
| Official PlayStation Magazine 87 EUR
|-
| [[SCED-03791]]
| PAL
| Official PlayStation Magazine 88 EUR
|-
| [[SCED-03905]]
| PAL
| Euro Demo (Germany) 03/04-2003
|-
| [[SCED-04076]]
| PAL
| Euro Demo (Future) 97
|-
| [[SCED-04077]]
| PAL
| Euro Demo (Future) 98
|-
| [[SLED-01633]]
| PAL
| PlayStation Zone CD Vol. 1
|-
| [[SLED-01724]]
| PAL
| PlayStation Zone CD Vol. 2
|-
| [[SLED-01773]]
| PAL
| PlayStation Zone CD Vol. 3
|-
| [[SLED-01783]]
| PAL
| PlayStation Zone CD Vol. 4
|-
| [[SLED-01898]]
| PAL
| PlayStation Zone CD Vol. 5
|-
| [[SLED-02042]]
| PAL
| PlayStation Zone CD Vol. 7
|-
| [[SLED-02078]]
| PAL
| PlayStation Zone CD Vol. 8
|-
| [[SLED-02139]]
| PAL
| PlayStation Zone CD Vol. 9
|}

Level ID

2019-04-27T17:44:37Z

Chekwob: 9 revisions imported: Initial import from Wikia

Each game level is assigned a single character code which signifies the internal name of the level. This character can be a decimal digit (<code>0-9</code>), an uppercase or lowercase ASCII letter (<code>a-z</code>, <code>A-Z</code>), an underscore (<code>_</code>) or an exclamation point (<code>!</code>). For letters, this character is case-sensitive, for instance level <code>g</code> is different from level <code>G</code>.

Some levels are more appropriately identified as game states: for example, level ID 19 in Crash 1 refers to the entire title sequence, main menu, options and password menus, map, and game over screen.

Each level's character code is associated with a number. The hexadecimal reading of this number determines the name of the NSD/NSF file pair which contains the game data for that level. For example, ''Cold Hard Crash'' has level code <code>j</code> which matches hex ID <code>13</code>; therefore, its data is held in the files <code>S00000'''13'''.NSD</code> and <code>S00000'''13'''.NSF</code>.

Tables matching level names to character codes and hex values for each game are presented below.



== Crash 1 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| (none)
|-
| <code>03</code>
| <code>3</code>
| Cortex Power
|-
| <code>04</code>
| <code>4</code>
| ''(unused)'' Cavern Level
|-
| <code>05</code>
| <code>5</code>
| Generator Room
|-
| <code>06</code>
| <code>6</code>
| Heavy Machinery
|-
| <code>07</code>
| <code>7</code>
| Toxic Waste
|-
| <code>08</code>
| <code>8</code>
| Pinstripe (Boss 4)
|-
| <code>09</code>
| <code>9</code>
| N. Sanity Beach
|-
| <code>0A</code>
| <code>a</code>
| Papu Papu (Boss 1)
|-
| <code>0B</code>
| <code>b</code>
| (none)
|-
| <code>0C</code>
| <code>c</code>
| Jungle Rollers
|-
| <code>0D</code>
| <code>d</code>
| (none)
|-
| <code>0E</code>
| <code>e</code>
| Boulders
|-
| <code>0F</code>
| <code>f</code>
| Upstream
|-
| <code>10</code>
| <code>g</code>
| (none)
|-
| <code>11</code>
| <code>h</code>
| Hog Wild
|-
| <code>12</code>
| <code>i</code>
| The Great Gate
|-
| <code>13</code>
| <code>j</code>
| Boulder Dash
|-
| <code>14</code>
| <code>k</code>
| Road to Nowhere
|-
| <code>15</code>
| <code>l</code>
| Rolling Stones
|-
| <code>16</code>
| <code>m</code>
| The High Road
|-
| <code>17</code>
| <code>n</code>
| Ripper Roo (Boss 2)
|-
| <code>18</code>
| <code>o</code>
| Up The Creek
|-
| <code>19</code>
| <code>p</code>
| Map, Main Menu, Title Sequence
|-
| <code>1A</code>
| <code>q</code>
| Native Fortress
|-
| <code>1B</code>
| <code>r</code>
| Nitrus Brio (Boss 5)
|-
| <code>1C</code>
| <code>s</code>
| Temple Ruins
|-
| <code>1D</code>
| <code>t</code>
| Jaws of Darkness
|-
| <code>1E</code>
| <code>u</code>
| Whole Hog
|-
| <code>1F</code>
| <code>v</code>
| Dr. Neo Cortex (Boss 6)
|-
| <code>20</code>
| <code>w</code>
| The Lost City
|-
| <code>21</code>
| <code>x</code>
| Koala Kong (Boss 3)
|-
| <code>22</code>
| <code>y</code>
| ''(unused)'' Stormy Ascent
|-
| <code>23</code>
| <code>z</code>
| Sunset Vista
|-
| <code>24</code>
| <code>A</code>
| Bonus Round (Tawna - short version)
|-
| <code>25</code>
| <code>B</code>
| Bonus Round (Nitrus Brio)
|-
| <code>26</code>
| <code>C</code>
| Bonus Round '''(currently unknown)'''
|-
| <code>27</code>
| <code>D</code>
| (none)
|-
| <code>28</code>
| <code>E</code>
| Lights Out
|-
| <code>29</code>
| <code>F</code>
| The Lab
|-
| <code>2A</code>
| <code>G</code>
| Fumbling in the Dark
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| The Great Hall
|-
| <code>2D</code>
| <code>J</code>
| Level Completion Screen
|-
| <code>2E</code>
| <code>K</code>
| Slippery Climb
|-
| <code>2F</code>
| <code>L</code>
| (none)
|-
| <code>30</code>
| <code>M</code>
| (none)
|-
| <code>31</code>
| <code>N</code>
| (none)
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| Bonus Round (Tawna - long version)
|-
| <code>34</code>
| <code>Q</code>
| Bonus Round (Dr. Neo Cortex)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| Castle Machinery
|-
| <code>38</code>
| <code>U</code>
| Intro
|-
| <code>39</code>
| <code>V</code>
| Ending
|-
| <code>3A</code>
| <code>W</code>
| (none)
|-
| <code>3B</code>
| <code>X</code>
| (none)
|-
| <code>3C</code>
| <code>Y</code>
| (none)
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>4</code> is in an older file format and is not properly compatible with the game engine.

=== Prerelease Versions ===
There are two known leaked prerelease versions of Crash 1. Some additional level slots are used in these versions.

{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>01</code>
| <code>1</code>
| Test Area
|-
| <code>02</code>
| <code>2</code>
| '''(currently unknown)'''
|-
| <code>04</code>
| <code>4</code>
| Cavern Level
|-
| <code>0B</code>
| <code>b</code>
| Cliff Level
|-
| <code>0D</code>
| <code>d</code>
| Waterfall Level
|-
| <code>10</code>
| <code>g</code>
| 2D Donkey Kong
|}

Level <code>2</code> and level <code>g</code> (10) are in significantly older versions of the game's file format and are not compatible with the game engine. The other levels are unfinished and contain some compatibility issues.

== Crash 2 ==
The final version of Crash 2 has .NSD/.NSF files present for 38 level IDs (42 in PAL version).
{| class="wikitable"
!Hex
!#
!Level name
|-
| <code>01</code>
| <code>1</code>
| N/A
|-
| <code>02</code>
| <code>2</code>
|English Warp Room
|-
| <code>03</code>
| <code>3</code>
|Tiny Tiger
|-
| <code>04</code>
| <code>4</code>
|N/A
|-
| <code>05</code>
| <code>5</code>
|N/A
|-
| <code>06</code>
| <code>6</code>
|Ripper Roo
|-
| <code>07</code>
| <code>7</code>
|Dr. Neo Cortex
|-
| <code>08</code>
| <code>8</code>
|Komodo Bros.
|-
| <code>09</code>
| <code>9</code>
|N. Gin
|-
| <code>0A</code>
| <code>a</code>
|Sewer or Later
|-
| <code>0B</code>
| <code>b</code>
|N/A; Test jungle level (jungle1)
|-
| <code>0C</code>
| <code>c</code>
|Night Fight
|-
| <code>0D</code>
| <code>d</code>
|Hangin' Out
|-
| <code>0E</code>
| <code>e</code>
|Snow Go
|-
| <code>0F</code>
| <code>f</code>
|Ruination
|-
| <code>10</code>
| <code>g</code>
|Piston it Away
|-
| <code>11</code>
| <code>h</code>
|Snow Biz
|-
| <code>12</code>
| <code>i</code>
|Rock It
|-
| <code>13</code>
| <code>j</code>
|Cold Hard Crash
|-
| <code>14</code>
| <code>k</code>
|N/A
|-
| <code>15</code>
| <code>l</code>
|Diggin' It
|-
| <code>16</code>
| <code>m</code>
|Road to Ruin
|-
| <code>17</code>
| <code>n</code>
|Un-Bearable
|-
| <code>18</code>
| <code>o</code>
|Crash Dash
|-
| <code>19</code>
| <code>p</code>
|Hang Eight
|-
| <code>1A</code>
| <code>q</code>
|Pack Attack
|-
| <code>1B</code>
| <code>r</code>
|Crash Crush
|-
| <code>1C</code>
| <code>s</code>
|Intro
|-
| <code>1D</code>
| <code>t</code>
|Bear It
|-
| <code>1E</code>
| <code>u</code>
|Turtle Woods
|-
| <code>1F</code>
| <code>v</code>
|The Pits
|-
| <code>20</code>
| <code>w</code>
|Air Crash
|-
| <code>21</code>
| <code>x</code>
|Plant Food
|-
| <code>22</code>
| <code>y</code>
|Bear Down
|-
| <code>23</code>
| <code>z</code>
|The Eel Deal
|-
| <code>24</code>
| <code>A</code>
|Bee-Having
|-
| <code>25</code>
| <code>B</code>
|Totally Bear
|-
| <code>26</code>
| <code>C</code>
|Spaced Out
|-
| <code>27</code>
| <code>D</code>
|Totally Fly
|-
| <code>28</code>
| <code>E</code>
|100% Ending
|-
| <code>29</code>
| <code>F</code>
|Normal Ending
|-
| <code>2A</code>
| <code>G</code>
|N/A
|-
| <code>2B</code>
| <code>H</code>
|N/A
|-
| <code>2C</code>
| <code>I</code>
|N/A
|-
| <code>2D</code>
| <code>J</code>
|Spanish Warp Room (PAL only)
|-
| <code>2E</code>
| <code>K</code>
|French Warp Room (PAL only)
|-
| <code>2F</code>
| <code>L</code>
|German Warp Room (PAL only)
|-
| <code>30</code>
| <code>M</code>
|Italian Warp Room (PAL only)
|-
| <code>31</code>
| <code>N</code>
|N/A
|-
| <code>32</code>
| <code>O</code>
|N/A
|-
| <code>33</code>
| <code>P</code>
|N/A
|-
| <code>34</code>
| <code>Q</code>
|N/A
|-
| <code>35</code>
| <code>R</code>
|N/A
|-
| <code>36</code>
| <code>S</code>
|N/A
|-
| <code>37</code>
| <code>T</code>
|N/A
|-
| <code>38</code>
| <code>U</code>
|N/A
|-
| <code>39</code>
| <code>V</code>
|N/A
|-
| <code>3A</code>
| <code>W</code>
|N/A
|-
| <code>3B</code>
| <code>X</code>
|Game Over Screen
|-
| <code>3C</code>
| <code>Y</code>
|Title Screen
|}

== Crash 3 ==
{| class="wikitable"
! Hex
! #
! Level Name
|-
| <code>00</code>
| <code>0</code>
| (none)
|-
| <code>01</code>
| <code>1</code>
| (none)
|-
| <code>02</code>
| <code>2</code>
| Warp Room (English or Japanese)
|-
| <code>03</code>
| <code>3</code>
| Dingodile (Boss 2)
|-
| <code>04</code>
| <code>4</code>
| N. Tropy (Boss 3)
|-
| <code>05</code>
| <code>5</code>
| N. Gin (Boss 4)
|-
| <code>06</code>
| <code>6</code>
| Tiny (Boss 1)
|-
| <code>07</code>
| <code>7</code>
| Dr. Neo Cortex (Boss 5)
|-
| <code>08</code>
| <code>8</code>
| (none)
|-
| <code>09</code>
| <code>9</code>
| (none)
|-
| <code>0A</code>
| <code>a</code>
| Orient Express
|-
| <code>0B</code>
| <code>b</code>
| Toad Village
|-
| <code>0C</code>
| <code>c</code>
| Bone Yard
|-
| <code>0D</code>
| <code>d</code>
| Tell No Tales
|-
| <code>0E</code>
| <code>e</code>
| Under Pressure
|-
| <code>0F</code>
| <code>f</code>
| Gee Wiz
|-
| <code>10</code>
| <code>g</code>
| Dino Might!
|-
| <code>11</code>
| <code>h</code>
| Midnight Run
|-
| <code>12</code>
| <code>i</code>
| Tomb Time
|-
| <code>13</code>
| <code>j</code>
| Bye Bye Blimps
|-
| <code>14</code>
| <code>k</code>
| Road Crash
|-
| <code>15</code>
| <code>l</code>
| Hog Ride
|-
| <code>16</code>
| <code>m</code>
| Hang'em High
|-
| <code>17</code>
| <code>n</code>
| Mad Bombers
|-
| <code>18</code>
| <code>o</code>
| Tomb Wader
|-
| <code>19</code>
| <code>p</code>
| Makin' Waves
|-
| <code>1A</code>
| <code>q</code>
| High Time
|-
| <code>1B</code>
| <code>r</code>
| Future Frenzy
|-
| <code>1C</code>
| <code>s</code>
| Deep Trouble
|-
| <code>1D</code>
| <code>t</code>
| Double Header
|-
| <code>1E</code>
| <code>u</code>
| Sphynxinator
|-
| <code>1F</code>
| <code>v</code>
| Rings of Power
|-
| <code>20</code>
| <code>w</code>
| Orange Asphalt
|-
| <code>21</code>
| <code>x</code>
| Ski Crazed
|-
| <code>22</code>
| <code>y</code>
| Flaming Passion
|-
| <code>23</code>
| <code>z</code>
| Future Frenzy
|-
| <code>24</code>
| <code>A</code>
| Bug Lite
|-
| <code>25</code>
| <code>B</code>
| Area 51?
|-
| <code>26</code>
| <code>C</code>
| Eggipus Rex
|-
| <code>27</code>
| <code>D</code>
| Hot Coco
|-
| <code>28</code>
| <code>E</code>
| Opening Cutscene (English and Japanese)
|-
| <code>29</code>
| <code>F</code>
| Any% Ending Cutscene
|-
| <code>2A</code>
| <code>G</code>
| 100% Ending Cutscene
|-
| <code>2B</code>
| <code>H</code>
| (none)
|-
| <code>2C</code>
| <code>I</code>
| (none)
|-
| <code>2D</code>
| <code>J</code>
| Opening Cutscene (Spanish, PAL only)
|-
| <code>2E</code>
| <code>K</code>
| Opening Cutscene (French, PAL only)
|-
| <code>2F</code>
| <code>L</code>
| Opening Cutscene (German, PAL only)
|-
| <code>30</code>
| <code>M</code>
| Opening Cutscene (Italian, PAL only)
|-
| <code>31</code>
| <code>N</code>
| Gone Tomorrow
|-
| <code>32</code>
| <code>O</code>
| (none)
|-
| <code>33</code>
| <code>P</code>
| (none)
|-
| <code>34</code>
| <code>Q</code>
| (none)
|-
| <code>35</code>
| <code>R</code>
| (none)
|-
| <code>36</code>
| <code>S</code>
| (none)
|-
| <code>37</code>
| <code>T</code>
| (none)
|-
| <code>38</code>
| <code>U</code>
| (none)
|-
| <code>39</code>
| <code>V</code>
| (none)
|-
| <code>3A</code>
| <code>W</code>
| Intermission Vortex
|-
| <code>3B</code>
| <code>X</code>
| Game Over Screen
|-
| <code>3C</code>
| <code>Y</code>
| Title Screen
|-
| <code>3D</code>
| <code>Z</code>
| (none)
|-
| <code>3E</code>
| <code>_</code>
| (none)
|-
| <code>3F</code>
| <code>!</code>
| (none)
|}

Level <code>v</code> (1F), ''Rings of Power'', appears in the S2 directory rather than S1.

Game Loop

2019-04-27T17:44:36Z

Chekwob: 6 revisions imported: Initial import from Wikia

The central flow construct in a video game is its game loop. In a single iteration of the game loop, all the necessary logic is performed in updating the game state, including processing of user input, before the game scene is finally rendered to the display.

The window of time during which an iteration of the game loop takes place is commonly referred to as a frame.

== Crash 1 ==
The game loop routine is located at <code>0x11FC4</code> in Crash 1. From the <code>main</code> routine, the game loop routine is passed the level id of an 'initial level' as its argument; in Crash 1 this value is 19-the level ID for the title sequence, main menu, and then possibly map if 'a game is started'.

=== Outline ===
<pre>
sub_80011FC4(levelid)
{
A) sub_80026140 - Game initialization
B) sub_80015B58 - Paging and subsystem initialization
C) sub_80011DD0 - Load entries and/or create main game objects
(HUD/display, Crash, Aku Aku, Shadows, Boxes, Fruit)
GAME LOOP:
{
1) Code for handling game pause/start button press
2) If Crash object does not exist:
A) sub_8002E98C - Create HUD and initialize level
3) Code for loading a new level if necessary
4) Update pages
A) sub_800134C8 - UpdatePages()
5) Spawn all objects in current zone [for those that have their respawn bit set]
A) sub_80025928 - SpawnObjects()
6) Update camera
A) sub_8002EC68 - level dependent routine A
B) sub_8002EBB4 - level dependent routine B
C) sub_8002B2BC - UpdateCamera()
7) Update matrices
A) sub_80017A14 - UpdateMatrices()
- recalculate camera translation, rotation, scale, and light matrices
- create world models for current zone
8) Create transformed primitives for current zone world models
dependent on current zone render mode:
sub_80019508 - default world model primitive creation routine
sub_80019BCC - w.m.p.c.r high road/road to nowhere depth shader variant
sub_80019DE0 - w.m.p.c.r ripple effect vertex position shader variant
sub_80019F90 - w.m.p.c.r lightning effect vertex shader variant
sub_8001A0CC - w.m.p.c.r darken depth effect shader variant
sub_8001A2E0 - w.m.p.c.r darken effect shader variant
9) Update all objects and create transformed primitives for them
A) sub_8001D5EC - UpdateObjects()
10) If current level is title screen (0x19) then do title screen routine
A) sub_800326D8 - title screen routine
11) Send transformed primitives to GPU for rendering
A) sub_80016E5C - GPU routine
}
}
</pre>

=== Game initialization ===
The game loop routine begins with a call to the game initialization routine, located at <code>0x26140</code>. This initializes all global game variables.

=== Paging and subsystem initialization ===
After executing the game initialization routine, the game still has no data to work with: nothing from the disc has been loaded into memory other than the currently executing binary. At this point, the [[Paging and Subsystem Initialization|paging and subsystem initialization routine]] is called. This routine has 2 input parameters, the first being the level id of a level whose content shall be paged from disc, and the second a pointer to the location of storage for the resultant [[Paging and Subsystem Initialization#Paging System Structure|paging system structure]]. The arguments specified in the call are the current level's ID (passed as the argument to the game loop routine), and a pointer to the game's global [[Paging and Subsystem Initialization#Paging System Structure|paging system structure]]-located at <code>0x5C528</code>. After execution of the paging and subsystem initialization routine, the paging system structure will include all the necessary information for paging data from disc, specifically that data located in the current level's corresponding NSF file.

=== Load executables for and/or create main game objects ===
Once paging has been initialized, the appropriate paging routines are used to load all [[GOOL Executable|GOOL executable entry]] data for the main or 'universal' game objects (HUD/display, Crash, Aku Aku, shadows, boxes, fruit) from the current level's corresponding NSF file (i.e. the current NSF file) into main memory. Most NSF files contain the same copy of data for each of these objects (hence the term universal), with a few exceptions: for example, The Great Hall does not contain any box objects in its layout, so its NSF file does not contain the [[GOOL Executable|GOOL executable]] for the box object. Consequently, no box objects are spawned in an instance of the game on level 2C. The routine located at <code>0x11DD0</code> loads all existing universal game object executables into main memory.

GOOL Interpreter

2019-04-27T17:44:36Z

Chekwob: 18 revisions imported: Initial import from Wikia

In the Crash games, the GOOL Interpreter is responsible for interpreting an object's executable bytecode. This bytecode instructs the interpreter to perform a specific sequence of operations that can conditionally or unconditionally alter specific characteristics of the object (ex. appearance, location, status, etc.), and should ultimately render the object according to its changing characteristics. As a result, the player observes a lively, animated, and interactive enemy, box, collectible item, or whatever other kind of in-game object it may be.

== Interpretation ==
A single ''interpretation'' of an object's bytecode consists of the following steps:
# ''Fetch'' the instruction at the object's program counter location
#* Read the instruction at the object's program counter location
#* Point the object's program counter to the location of the following instruction
# ''Perform'' the operation specified by the fetched instruction
# ''Continue'' repeating steps 1 and 2 until a suspending instruction is fetched
(A suspending instruction is typically either a RET, which marks the end of a block, or ANIF/ANIS, which change the object's current frame of animation.)

A single call to the GOOL interpreter routine with some desired object as its first argument results in a single interpretation of that object's bytecode. The GOOL bytecode interpreter routine expects an object that provides the following information:
* The location in its bytecode at which the interpreter shall begin its interpretation = object's program counter
* The location in its memory of a stack frame created for the interpretation = object's frame pointer
* The location in its memory at which the interpreter shall begin pushing the results of/popping the operands for interpreted instructions = object's stack pointer
Prior to an interpretation, each of these fields (program counter, frame pointer, stack pointer) is modified according to the object's current state [descriptor] and the type of interpretation.

== Types of interpretation ==
Many separate interpretations of an object's bytecode can occur within a single frame. The GOOL interpreter routine can be called with the same object from up to 7 distinct locations in a single iteration of the game loop. Each of the 7 calls to the interpreter routine with that object, and thus the ensuing interpretations of its bytecode, occurs under a separate condition. The 7 interpretations are identified based on the conditions under which they occur, and are as follows:
* One that occurs at a specified rate, i.e. after a specific amount of time has elapsed since its previous occurrence. (Code Block interpretation)
* One that [always] occurs [for each frame]. (Trans Block interpretation)
* One that occurs whenever the object is sent an event and its current state specifies the location of an event service routine. (Event Block interpretation)
* One that occurs whenever the object is sent an event and: its current state does not specify an event service routine or its event service routine failed to return an event, and the event sent maps to an event handler. (Handles Block interpretation)
* One that occurs whenever the object changes state. (Head Block interpretation)
* One that occurs whenever the object changes state and its recent Trans Block interpretation was unsuccessful (*Trans Block interpretation)
* One that occurs when the object minimizes the distance during another object's query to 'find the nearest object', and the event sent for asynchronous handling (from the querying object) maps to an event handler. (*Handles Block interpretation)

Ignoring the details for now, the latter 2 types are just a Trans Block and Handles Block interpretation, respectively, although their calls cross-reference the interpreter routine from different locations. Thus, there are a total of 5 types. These 5 types are more simply viewed as 5 separate threads of execution of the object's bytecode. To demonstrate, here is the expanded game loop routine with only the calls to routines that have a descendant call to the interpreter routine:

<pre>
sub_80011FC4(levelid)
{
...
C) sub_80011DD0 - Load entries and/or create universal game objects
(HUD/display, Crash, Aku Aku, Shadows, Boxes, Fruit)
1) sub_8001C6C8 - CreateObject() [called once for each object created]
...
GAME LOOP:
{
1) Code for handling game pause/start button press
A) If start pressed...
i) If pause menu object does not exist....
1) sub_8001C6C8 - CreateObject() [create pause menu object]
...
else
1) sub_80024040 - SendEvent() [destroy pause menu object]
...
2) If Crash object does not exist:
A) sub_8002E98C - Create HUD and initialize level
i) sub_8001C6C8 - CreateObject() [create HUD object]
ii)sub_80026650 - Reinitialize Level
1) sub_8001C6C8 - CreateObject() [create Crash object]
...
3) Code for loading a new level if necessary
A) If new level to load
...
ii)sub_80011DD0 - Load entries and/or create universal game objects
1) sub_8001C6C8 - CreateObject() [called once for each object created]
...
...
5) Spawn all objects in current zone [for those that have their respawn bit set]
A) sub_80025928 - Spawn objects
1) sub_8001BCC8 - SpawnObject() [called for each object spawned]
...
...
9) Update all objects and create transformed primitives for them
A) sub_8001D5EC - UpdateObjects()
1) sub_8001DA0C - UpdateObject() [called for each existing object]
...
}
}
</pre>
Based on the above, consider an arbitrary frame of execution in terms of a single object. CreateObject() or SpawnObject() will not be called more than once [to create that object] in that frame; that is-the object is not created or spawned more than once, or even spawned after it is created and vice-versa. The object may not even be created/spawned in that frame because it either already exists or does not exist since the game has not requested it be created/spawned. If it is an existing object, it will also be updated only once in that frame. For a single object, the above can be reduced the following series of potential calls:

<pre>
sub_80011FC4(levelid)
{
...
GAME LOOP:
{
...
CreateObject(obj,...) or SpawnObject(obj,...)
...
SendEvent(src,obj,...)
...
UpdateObject(obj)
}
}
</pre>

What the above leaves out, however, are the number of other locations at which a call to the SendEvent() routine reside. Some are located before the CreateObject or SpawnObject routine calls, some after, some within the UpdateObject routine itself, and even some within the interpreter routine, since there exist several types of GOOL instructions that allow another object to send an event to the recipient object. In fact, there is nothing preventing the object from being the recipient of more than one event sent (from potentially multiple sources) in a single frame. There may be an interpretation for each event sent to the object during that frame, and there is no limit on the number of events that can be sent. Thus, there may be many calls to SendEvent() [with the object as the recipient] in a single frame, but still only at most one call to CreateObject/SpawnObject() and UpdateObject(). Without getting too far off track, it is simply necessary to understand that each of these routines contains (or calls a routine that calls a routine that contains) a call to the interpreter routine:

<pre>
sub_80011FC4(levelid)
{
...
GAME LOOP:
{
...
CreateObject(obj,...) or SpawnObject(obj,...)
InitObject(obj, ...)
ChangeObjectState(obj, ...)
CreateObjectStackFrame(obj); // *create initial stack frame
-if there is a head block to interpret for the object
CreateObjectStackFrame(obj);
obj->pc = obj->pchead;
InterpretObject(obj, 0x13, &stateref); // # 1 (head block interpretation)

SendEvent(src,obj,...) // there may be multiple calls to this
-if there is an event service routine for the object (in its current state)
CreateObjectStackFrame(obj);
obj->pc = obj->pcevent;
InterpretObject(obj, 0x8, &stateref); // # 2 (event block interpretation)
-if there is not an event service routine for the object (in its current state)
or the event service routine failed to return an event
-if the event maps to an event handler in the event->state/handler map
CreateObjectStackFrame(obj);
obj->pc = handlerlocation;
InterpretObject(obj, 0x3, &stateref); // # 3 (handles block interpretation)
-else
ChangeObjectState(obj,state,...); // *

UpdateObject(obj)
-if the object is able to animate
-if there is a trans block to interpret for the object (in its current state)
CreateObjectStackFrame(obj);
obj->pc = obj->pctrans;
InterpretObject(obj, 0x3, &stateref); // # 4 (trans block interpretation)
-if at least n ticks have elapsed, where n is given by the 'wait' operand of the
most recently suspending animation type instruction of the object's code block
InterpretObject(obj, 0x4, &stateref); // # 5 (code block interpretation)

}
}
</pre>
Notice that immediately prior to each call [to the interpreter routine], with the exception of #5, a new stack frame is created for the object (which includes pointing its frame pointer and stack pointer, respectively, to the beginning and ending of its new frame), and its program counter is pointed to a distinct location within its bytecode. If each bytecode instruction is represented by a pseudo-instruction, a potential sequence of calls to the interpreter routine in a single frame [for only that object] might be represented by the following:

<pre>
label | address | pseudo-instruction

pcevent: 0x34 N // call A
0x38 N
0x3C S
...
pchead: 0x0 N // call B
0x4 N
0x8 N
0xC S
...
pctrans: 0x50 N // call C
0x54 N
0x58 N
0x5C N
0x60 N
0x64 N
0x68 S
...
*pccode: 0x70 N // call D
0x74 N
0x78 N
0x7C N
0x80 S
...
pcevent: 0x34 N // call E
0x38 N
0x3C S
...
pcevent: 0x34 N // call F
0x38 N
0x3C S
</pre>

Each call above to the interpreter routine is represented by the sequence of instructions (represented as pseudo-instructions) fetched during its interpretation. An N pseudo-instruction represents an instruction that did not suspend the interpreter, causing the next instruction in sequence to be fetched and interpreted. An S pseudo-instruction represents an instruction that did suspend the interpreter, causing the interpreter routine to end the interpretation/return to its caller. Each pseudo-instruction is listed with the address of the instruction it represents in the object's bytecode [relative to the beginning].

The first instruction fetched in each interpretation is also marked with a label; this label is given the name of the object field that points to its associated instruction. Immediately prior to each interpretation, with the exception of the one marked *pccode, the object's program counter is pointed to the location in ''this'' particular field; it is this operation that causes each interpretation to begin at the location it does. This particular object field is also primarily responsible for determining the type of interpretation:
{| class="article-table"
!Field
!Interpretation Type
|-
|pctrans
|Trans Block Interpretation
|-
|pcevent
|Event Block Intepretation
|-
|pchead
|Head Block Interpretation
|-
|pc
|Code Block Interpretation
|}
The <code>pctrans</code>, <code>pcevent</code>, and <code>pchead</code> fields each contain a pointer to/the absolute location of an individual ''block'' in the object's bytecode. These fields locate the respective entry points for 3 separate ''threads'' of interpretation for the object-a trans thread, an event thread, and a head thread. Whenever the object changes state, its <code>pctrans</code> and <code>pcevent</code> fields are modified according to the state descriptor for its new state; its <code>pchead</code> field is then cleared. (If the object wishes to modify its <code>pchead</code> field, it does so via a MOVC instruction in its bytecode.)

Whenever the object changes state, its program counter (<code>pc</code> field) is also set directly to the location of the code block specified by the <code>pccode</code> field of the state descriptor for its new state. The entirety of the object's stack contents are then unwound, or the object's stack pointer is reset to its initial location, and an initial stack frame is [re]created. This program counter location and stack configuration is then restored after each subsequent non-code block interpretation is completed. (That is-since those interpretations require the program counter value to be replaced with a new location and a new stack frame to be created, after they are completed, the original program counter location and initial stack frame are restored). When the interpretation marked #5 in the above pseudo-code (the code block interpretation) finally occurs, the object's program counter will point to its code block and its stack frame will be the initial frame. The code block interpretation is yet another thread of interpretation for the object-a code thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, handles blocks are viewed as being equivalent to event blocks, so handles interpretations and threads are simply ignored. The timeline to the right shows an arbitrary frame of execution in terms of the times elapsed for the various interpretations of a single object's bytecode. Towards the beginning of the frame, the interpreter has performed a code block interpretation and a trans block interpretation for the object. Towards the end of the frame, the interpreter has performed an event block interpretation for that object, as it has been sent an event from some [unknown] source. The following timeline extends this timeline [to the right] to 6 arbitrary frames of execution:
[[File:Goolinterp2b.png|thumb|733x733px]]

The extended timeline makes it clear that this particular object has been configured to have its code block interpretation occur every other frame. It also shows the performance of more than one event block interpretation for that object during the second frame. The following timeline shows the same 6 frames of execution in terms of the times elapsed for all interpretations of each existing object's bytecode; in this particular instance, there are only 2 existing objects.
[[File:Goolinterp2c.png|thumb|733x733px|none]]

== Stack Frame (incomplete) ==
A new stack frame is created for an object immediately prior to an interpretation of its bytecode. It is also created when jumping to and linking a bytecode routine via the JAL instruction. An object's ''initial'' stack frame is created when it enters its initial state, and is recreated for each subsequent state change (after the unwinding the stack). The initial stack frame is used for the object's code block interpretation. At any given point in time, an object's frame pointer and stack pointer, respectively, locate the beginning and end of its ''current'' stack frame.

=== Format ===
A stack frame has the following format:
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|<nowiki>-0x4 x </nowiki>''a''
|**Argument ''a''
|4 bytes
|*
|-
|0x0
|Preserved Interpreter Mode Flags
|4 bytes
|0xFFFF for initial frame; * otherwise
|-
|0x4
|Preserved Program Counter
|4 bytes
|*
|-
|0x8
|Preserved Frame Pointer Relative Offset
|2 bytes
|f
|-
|0xA
|Preserved Stack Pointer Relative Offset
|2 bytes
|s
|-
|0xC
|Frame Data
|* x 4 bytes
|*
|}
(**Arguments come before frames and are not actually 'part' of them)

=== Initial Stack Frame ===
When the object is first created/spawned, or when it changes state, its program counter is pointed to the code block with offset <code>pccode</code> (given by the state descriptor for its initial or new state), its frame pointer is cleared, and its stack pointer is ''reset'' to its initial location:
[[File:Goolinterp3b.png|none|thumb|646x646px]]
The object's initial stack frame is then [re]created by pushing the following sequence of values to the stack:
* 0x0000FFFF - Interpreter Mode Flags. Not an actual interpreter mode flags value but rather an indicator that an unwinding of this frame shall not restore interpreter mode flags.
* <code>obj->pc</code> - Program Counter. At this point, it points to the code block for the object's initial/new state.
* <code>(((unsigned long)obj->fp - (unsigned long)&obj->self) << 16) | ((unsigned long)obj->sp - (unsigned long)&obj->self))</code> Frame Pointer and Stack Pointer relative offsets. At this point, frame pointer (<code>obj->fp</code>) is 0 and stack pointer points to its initial location; this combined value should be of the form 0x0000****.
The object's frame pointer is then pointed to the beginning of that frame. With these values having been pushed to its stack, the object's stack pointer now points to the end of that frame. Thus, immediately following the instantiation or state change, the object's current stack frame is its initial stack frame.
[[File:Goolinterp3d.png|none|thumb|756x756px]]
During the object's code block interpretation, this frame is then ''extended ''with additional data, including stack operands and/or the results of interpreted instructions.

=== Non-Initial Stack Frame ===
After an object's initial stack frame is created, but before its next code block interpretation occurs, several other non-code block interpretations may be performed. Immediately prior to performing any of these interpretations, a new stack frame is created ''on top ''of the initial stack frame, and ''then'' the current program counter value (which contains the code block location) is replaced with the location of the non-code block. This frame is created by pushing the following sequence of values to the stack:
* <code>modeflags</code> - Interpreter Mode Flags
* <code>obj->pc</code> - Program Counter. At this point, it points to the '''code block '''for the object's initial/new state.
* <code>(((unsigned long)obj->fp - (unsigned long)&obj->self) << 16) | ((unsigned long)obj->sp - (unsigned long)&obj->self))</code> Frame Pointer and Stack Pointer relative offsets. At this point, frame pointer points to the beginning of the initial frame, and stack pointer points to the end of the initial frame.
The object's frame pointer is then pointed to the beginning of that frame. With these values having been pushed to its stack, the object's stack pointer now points to the end of that frame. Thus, immediately following the creation of the frame, ''it'' is the object's current stack frame-that is, the initial stack frame is no longer the current stack frame.
[[File:Goolinterp3e.png|none|thumb|573x573px]]
When the following interpretation finishes, the object's program counter is restored to the code block location preserved in the current frame, and the preserved frame pointer and stack pointer offsets are used to restore the initial stack frame as the current frame.

'''UNFINISHED'''

== Interpreter Mode Flags ==
TBD

== GOOL Instructions ==

=== Crash 1 ===
The GOOL Interpreter in Crash 1 recognizes a total of 58 different GOOL instructions:
* 6 Arithmetic Instructions (incl SHA*)
* 4 Non-bitwise Logical/Logical Comparison Instructions
* 4 Bitwise Logical Instructions
* 5 Comparison Instructions
* 5 Data Transfer Instructions
* 8 Mathematical Function Instructions
* 4 Control Flow Instructions
* 19 Miscellaneous/Multi-Purpose Instructions

==== GOOL Instruction Tables ====

===== Main Instruction Table =====
The GOOL instruction table below lists the opcode, mnemonic/name, format, operands (based on explicit and/or implicit specification of source origin and/or destination target), general operation (represented with c-style statement), and a description for each GOOL instruction.
<div style="font-family:monospace;font-size:10px;">
{| border="1"

|-
! Opcode
! Name
! Encoding/Format
!Explicit GOOL ops
in
!Explicit IMM. ops
in
!Implicit STACK ops
in
! Operation
! Implicit STACK out
!Explicit
GOOL ops out
! Description

|-
| 0/0x00
| ADD
| '''00000000'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L + R
|O
|
| add

|-
| 1/0x01
| SUB
| '''00000001'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L - R
|O
|
| subtract

|-
| 2/0x02
| MUL
| '''00000010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L * R
|O
|
| multiply

|-
| 3/0x03
| DIV
| '''00000011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L / R
|O
|
| divide

|-
| 4/0X04
| CEQ
| '''00000100'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L == R),
O = ((L ^ R) == 0)
|O
|
| check if equal

|-
| 5/0x05
| ANDL
| 00000101RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L && R),
O = (L ? (R > 0) : 0)
|O
|
| logical and

|-
| 6/0x06
| ORL
| 00000110RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
|O
| 
| logical or

|-
| 7/0x07
| ANDB
| 00000111RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L & R
|O
|
| bitwise and

|-
| 8/0x08
| ORB
| 00001000RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = L | R</nowiki>
|O
|
| bitwise or

|-
| 9/0x09
| SLT
| 00001001RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L < R
|O
|
| set less than

|-
|10/0x0A
| SLE
| 00001010RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L <= R)
|O
|
| set less than or equal

|-
|11/0x0B
| SGT
| 00001011RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L > R
|O
|
| set greater than

|-
|12/0x0C
| SGE
| 00001100RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L >= R)
|O
|
| set greater than or equal

|-
|13/0x0D
| MOD
| 00001101RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L % R
|O
|
| modulo

|-
|14/0x0E
| XOR
| 00001110RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L ^ R
|O
|
| exclusive or

|-
|15/0x0F
| TST
| 00001111RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (((L & R) ^ R) == 0)
|O
|
| test bit

|-
|16/0x10
| RND
| 00010000AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
| O = B+(rand() % (A - B))
|O
|
| random

|-
|17/0x11
| MOVE
| 00010001SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = S
|
| [D]
| move data

|-
|18/0x12
| NOTL
| 00010010SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S == 0)
|
| D
| logical not

|-
|19/0x13
| PATH
| 00010011AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
|R = 0x100
| [R,A]
| varies
| P
| B
| path progress

|-
|20/0x14
| LEA
| 00010100SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address

|-
|21/0x15
| SHA
| 00010101RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| arithmetic shift

|-
|22/0x16
| PSHV
| 00010110AAAAAAAAAAAABBBBBBBBBBBB
| [A,[B]]
|
|
| [arg_buf = A]
I = A; J = B;
|[I,[J]]
|
| push value to stack

|-
|23/0x17
| NOTB
| 00010111SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not

|-
|24/0x18
| MOVC
| 000110000000RRRRRRIIIIIIIIIIIIII
|
| R,C
|
| see docs
| O
|
| move code pointer

|-
|25/0x19
| ABS
| 00011001SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S: S
|
| D
| absolute value

|-
|26/0x1A
| PAD
| 00011010000TDDDDSSPPBBBBBBBBBBBB
|
|B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons

|-
|27/0x1B
| SPD
| 00011011VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
|S = B + ((V*gvel) >> 10)
| S
|
| calculate speed

|-
|28/0x1C
| MSC
| 00011100PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various; see docs
| ***
| ***
| multi-purpose

|-
|29/0x1D
| PRS
| 00011101PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
| O
|
| driven sine wave

|-
|30/0x1E
| SSAW
| 00011110DDDDDDDDDDDDPPPPPPPPPPPP
| M,P
|
|
| O = (M + frameCount) % P
| O
|
| synchronized saw wave

|-
|31/0x1F
| RGL
| 00011111000000000000IIIIIIIIIIII
| I
|
|
| O = globals[I >> 8]
| O
|
| read global variable

|-
|32/0x20
| WGL
| 00100000SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I << 8] = *S
|
|
| write global variable

|-
|33/0x21
| ANGD
| 00100001RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = angdist(L,R)
|
|
| angle between

|-
|34/0x22
| APCH
| 00100010RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
| S = 0x100
| [R,S]
| O = approach(L,R,S)
| O
|
| approach a value

|-
|35/0x23
| CVMR
| 00100011000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
|
|
|color vector or matrix read

|-
|36/0x24
| CVMW
| 00100011000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
|color vector or matrix write

|-
|37/0x25
| ROT
| 00100101RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
| [R,S]
| O = rotate(L,R,S,0)
| O
|
| approach an angle

|-
|38/0x26
| PSHP
| 001001100AAAAAAAAAAABBBBBBBBBBBB
| [A,[B]]
|
|
| I = &A; J = &B;
|
| [I,[J]]
| push pointer to stack

|-
|39/0X27
| ANID
| 00100111FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>5]
|
| D
|set animation

|-
|128/0x80
| DBG
| 10000000RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|
|
|
| debug print ops (beta only)

|-
|129/0x81
| NOP
| 10000001000000000000000000000000
|
|
|
|
|
|
| no operation

|-
|130/0x82
| CFL
| 10000010TTCCRRRRRRIIIIIIIIIIIIII
|
| T,C,R,I
|
|
|
|
| general control flow

|-
|
| BRA
| 100000100000RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch

|-
|
| BNEZ
| 100000100001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero

|-
|
| BEQZ
| 100000100010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero

|-
|
| CST
| 100000100100RRRRRRSSSSSSSSSSSSSS
|
| R,S
|
|
|
|
| change state

|-
|
| CSNZ
| 100000100101RRRRRRSSSSSSSSSSSSSS
|
| R,S
|
|
|
|
| change state not zero

|-
|
| CSEZ
| 100000100110RRRRRRSSSSSSSSSSSSSS
|
| R,S
|
|
|
|
| change state equal zero

|-
|
| RET
| 100000101000RRRRRRIIIIIIIIIIIIII
|
| R,I
|
|
|
|
| return

|-
|131/0x83
| ANIS
| 10000011HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| change animation sequence

|-
|132/0x84
| ANIF
| 10000100HHTTTTTTFFFFFFFFFFFFFFFF
| F
| T,H
|
|
| W
|
| change animation frame

|-
|133/0x85
| VECA
| 10000101CCCTTTBBBAAAVVVVVVVVVVVV
| V
| T,A,B,C
|
|
| *
| **
| multi-purpose vector calcs

|-
|134/0x86
| JAL
| 10000110VVVV000000IIIIIIIIIIIIII
|
| I,V
|
|
|
|
|jump and link

|-
|135/0x87
| EVNT
| 10000111LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
|send an event

|-
|136/0x88
| RSTT
| 10001000TTCCRRRRRR**************
|
| R,C,T,*
| **
|
| 
|
|state return guard = true variant
|-
|137/0x89
| RSTF
| 10001001TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
|state return guard = false variant
|-
|-
|138/0x8A
| CHLD
| 10001010AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects

|-
|139/0x8B
| NTRY
| 10001011TTTTTTTTTTTTEEEEEEEEEEEE
|
| T,E
|
|
|
|
|multi-purpose page operation

|-
|140/0x8C
| SNDA
| 10001100AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
|adjust audio levels

|-
|141/0x8D
| SNDB
| 10001101VVVVRRRRRRSSSSSSSSSSSSS
| S
| V,R
|
|
|
| 
|play sound effect

|-
|142/0x8E
| VECB
| 10001110CCCTTTBBBAAAVVVVVVVVVVVV
| V
| T,A,B,C
|
|
|
| 
|multi-purpose vector calcs

|-
|143/0x8F
| EVNB
| 10001111LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
| 
|broadcast an event

|-
|144/0x90
| EVNU
| 10010000LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
| 
| 
|send event unknown variant

|-
|145/0x91
| CHLF
| 10100000AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
| [C],
arg[0 to A]
|
|
| 
|spawn children objects;
no replacement if obj pool full

|}
</div>

Note that a few instructions can not be represented with a single mnemonic; operations for these instructions are not only determined by their opcode but also their primary operation subtype and possibly secondary operation subtype fields. These instructions have their own tables, which are given in the following sections.

===== State Return Instruction Table =====
<div style="font-family:monospace;font-size:10px;">
{| border="1"
!Opcode
!Name
!Encoding/Format
!Explicit
IMM. ops

in
!Description
|-
|136/0x88
|RSTT
|10001000TTCCRRRRRR**************
|R,C,T,*
|state return guard = true variant
|-
|
|RST
|100010000100RRRRRRSSSSSSSSSSSSSS
|R,S
|state return guard = true
|-
|
|RSNT
|100010000101RRRRRRSSSSSSSSSSSSSS
|R,S
|state return if nonzero guard = true
|-
|
|RSZT
|100010000110RRRRRRSSSSSSSSSSSSSS
|R,S
|state return if equal zero guard = true
|-
|
|RSCT
|100010000111RRRRRRSSSSSSSSSSSSSS
|R,S
|state return eval prev cond guard = true
|-
|
|RNT
|100010001000RRRRRRxxxxxxxxxxxxxx
|R
|null return guard = true
|-
|
|RNNT
|100010001001RRRRRRxxxxxxxxxxxxxx
|R
|null return if nonzero guard = true
|-
|
|RNZT
|100010001010RRRRRRxxxxxxxxxxxxxx
|R
|null return if equal zero guard = true
|-
|
|RNCT
|100010001011RRRRRRxxxxxxxxxxxxxx
|R
|null return eval prev cond guard = true
|-
|
|GDT
|100010001100RRRRRRxxxxxxxxxxxxxx
|R
|guard = true
|-
|
|GNT
|100010001101RRRRRRxxxxxxxxxxxxxx
|R
|if nonzero guard = true
|-
|
|GZT
|100010001110RRRRRRxxxxxxxxxxxxxx
|R
|if equal zero guard = true
|-
|
|GCT
|100010001111RRRRRRxxxxxxxxxxxxxx
|R
|eval prev cond guard = true
|-
|
|GBNT
|100010000001RRRRRRVVVVIIIIIIIIII
|R,V,I
|if nonzero guard = true else branch
|-
|
|GBZT
|100010000010RRRRRRVVVVIIIIIIIIII
|R,V,I
|if equal zero guard = true else branch
|-
|137/0x89
| RSTF
| 10001001TTCCRRRRRR**************
| R,C,T,*
|state return guard = false variant
|-
|
|RSF
|100010000100RRRRRRSSSSSSSSSSSSSS
|R,S
|state return guard = false
|-
|
|RSNF
|100010000101RRRRRRSSSSSSSSSSSSSS
|R,S
|state return if nonzero guard = false
|-
|
|RSZF
|100010000110RRRRRRSSSSSSSSSSSSSS
|R,S
|state return if equal zero guard = false
|-
|
|RSCF
|100010000111RRRRRRSSSSSSSSSSSSSS
|R,S
|state return eval prev cond guard = false
|-
|
|RNF
|100010001000RRRRRRxxxxxxxxxxxxxx
|R
|null return guard = false
|-
|
|RNNF
|100010001001RRRRRRxxxxxxxxxxxxxx
|R
|null return if nonzero guard = false
|-
|
|RNZF
|100010001010RRRRRRxxxxxxxxxxxxxx
|R
|null return if equal zero guard = false
|-
|
|RNCF
|100010001011RRRRRRxxxxxxxxxxxxxx
|R
|null return eval prev cond guard = false
|-
|
|GDF
|100010001100RRRRRRxxxxxxxxxxxxxx
|R
|guard = false
|-
|
|GNF
|100010001101RRRRRRxxxxxxxxxxxxxx
|R
|if nonzero guard = false
|-
|
|GZF
|100010001110RRRRRRxxxxxxxxxxxxxx
|R
|if equal zero guard = false
|-
|
|GCF
|100010001111RRRRRRxxxxxxxxxxxxxx
|R
|eval prev cond guard = false
|-
|
|GBNF
|100010000001RRRRRRVVVVIIIIIIIIII
|R,V,I
|if nonzero guard = false else branch
|-
|
|GBZF
|100010000010RRRRRRVVVVIIIIIIIIII
|R,V,I
|if equal zero guard = false else branch
|-
|}
</div>

===== Operand Name Table =====
<div style="font-family:monospace;font-size:10px;">

{| border="1"
!
Specification Format
| rowspan="2" |A
|AAAAAAAAAAAA
|AAAA
|AAA (EVNT/EVNU/EVNB)
|AAA (VECA/VECB)
|-
!Name
|Value A
|Argument Count
|Argument Count
|Vector A Index
|-
!Specification Format
| rowspan="2" |B
|BBBBBBBBBBBB
|BBBBBBBBBBBB (PAD)
|BBBBBBBBBBBB (SPD)
|BBB
|-
!Name
|Value B
|Controller Buttons
|Base Speed
|Vector B Index
|-
!Specification Format
| rowspan="2" |C
|CCCCCCCCCCCC
|CCCCCC
|CCC
|CC
|-
!Name
|Color Value
|Spawn Count
|Vector C Index
|Conditional Check Type
|-
!Specification Format
| rowspan="2" |D
|DDDDDDDDDDDD
|DDDDDDDDDDDD (PRS)
|DDDD
|
|-
!Name
|Destination
|Wave Phase
|Directional Buttons
|
|-
!Specification Format
| rowspan="2" |E
|EEEEEEEEEEEE (NTRY)
|EEEEEEEEEEEE (EVNT/EVNU/EVNB)
|
|
|-
!Name
|Entry
|Event
|
|
|-
!Specification Format
| rowspan="2" |F
|FFFFFFFFFFFFFFFF
|FFFFFFFFFFFF
|FFFFFFF
|
|-
!Name
|Animation Frame
|Animation Descriptor Offset
|Animation Frame
|
|-
!
Specification Format
| rowspan="2" |H
|HH
|
|
|
|-
!Name
|Horizontal Flip
|
|
|
|-
!
Specification Format
| rowspan="2" |I
|IIIIIIIIIIIIII
|IIIIIIIIIIII
|IIIIIIIIII
|IIIIII
|-
!Name
|Immediate Code Location
|Global Variable Index
|Immediate Branch Offset
|Color Index
|-
!
Specification Format
| rowspan="2" |L
|LLLLLLLLLLLL
|LLL
|
|
|-
!Name
|Left Operand
|Object Link Index
|
|
|-
!
Specification Format
| rowspan="2" |P
|PPPPPPPPPPPP
|PPPP
|PP
|
|-
!Name
|Wave Period
|Primary Operation Subtype
|Primary Check Type
|
|-
!
Specification Format
| rowspan="2" |R
|RRRRRRRRRRRR
|RRRRRR
|
|
|-
!Name
|Right Operand
|Object Register Index
|
|
|-
!
Specification Format
| rowspan="4" |S
|SSSSSSSSSSSSSS
|SSSSSSSSSSSS
|SSSSSSSSS
|SSSSSS
|-
!Name
|State
|Source
|Animation Sequence Index
|Subtype
|-
!
Specification Format
|SSSSS
|SS
|
|
|-
!Name
|Secondary Operation Subtype
|Secondary Check Type
|
|
|-
!
Specification Format
| rowspan="4" |T
|TTTTTTTTTTTT
|TTTTTTTT
|TTTTTT
|TTT
|-
!Name
|Operation Subtype
|(Object) Type
|Time
|Operation Subtype
|-
!
Specification Format
|TT
|T
|
|
|-
!Name
|Operation Subtype
|Truth Invert Toggle
|
|
|-
!
Specification Format
| rowspan="2" |V
|VVVVVVVVVVVV
|VVVV
|VVVV (SNDB)
|
|-
!Name
|Velocity
|Variable Count
|Volume
|
|}
</div>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are unknown. The basic arithmetic and logical operations are preserved the same as in Crash 1, but most others have been changed.

Crash 2 GOOL code may also contain sections of machine code for the MIPS processor architecture (used by the playstation).

==== GOOLv2 Instruction Table ====
The GOOL instruction table below lists the opcode, mnemonic/name, format, operands (based on explicit and/or implicit specification of source origin and/or destination target), general operation (represented with c-style statement), and a description for each GOOL instruction.
<div style="font-family:monospace;font-size:10px;">
{| border="1"

|-
! Opcode
! Name
! Encoding/Format
!Explicit GOOL ops
in
!Explicit IMM. ops
in
!Implicit STACK ops
in
! Operation
! Implicit STACK out
!Explicit
GOOL ops out
! Description

|-
| 0/0x00
| ADD
| '''00000000'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L + R
|O
|
| add

|-
| 1/0x01
| SUB
| '''00000001'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L - R
|O
|
| subtract

|-
| 2/0x02
| MUL
| '''00000010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L * R
|O
|
| multiply

|-
| 3/0x03
| DIV
| '''00000011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L / R
|O
|
| divide

|-
| 4/0X04
| CEQ
| '''00000100'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L == R),
O = ((L ^ R) == 0)
|O
|
| check if equal

|-
| 5/0x05
| ANDL
| '''00000101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L && R),
O = (L ? (R > 0) : 0)
|O
|
| logical and

|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
|O
| 
| logical or

|-
| 7/0x07
| ANDB
| '''00000111'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L & R
|O
|
| bitwise and

|-
| 8/0x08
| ORB
| '''00001000'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = L | R</nowiki>
|O
|
| bitwise or

|-
| 9/0x09
| SLT
| '''00001001'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L < R
|O
|
| set less than

|-
|10/0x0A
| SLE
| '''00001010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L <= R)
|O
|
| set less than or equal

|-
|11/0x0B
| SGT
| '''00001011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L > R
|O
|
| set greater than

|-
|12/0x0C
| SGE
| '''00001100'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (L >= R)
|O
|
| set greater than or equal

|-
|13/0x0D
| MOD
| '''00001101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L % R
|O
|
| modulo

|-
|14/0x0E
| XOR
| '''00001110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = L ^ R
|O
|
| exclusive or

|-
|15/0x0F
| TST
| '''00001111'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (((L & R) ^ R) == 0)
|O
|
| test bit

|-
|16/0x10
| RND
| '''00010000'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
| O = B+(rand() % (A - B))
|O
|
| random

|-
|17/0x11
| MOVE
| '''00010001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = S
|
| [D]
| move data

|-
|18/0x12
| NOTL
| '''00010010'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S == 0)
|
| D
| logical not

|-
|19/0x13
| PATH
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
|R = 0x100
| [R,A]
| varies
| P
| B
| path progress (unconfirmed for c2)

|-
|20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address (unconfirmed for c2)

|-
|21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| arithmetic shift

|-
|22/0x16
| PSHV
| '''00010110'''AAAAAAAAAAAABBBBBBBBBBBB
| [A,[B]]
|
|
| [arg_buf = A]
I = A; J = B;
|[I,[J]]
|
| push value to stack (unconfirmed for c2)

|-
|23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not

|-
|24/0x18
| MOVC
| '''00011000'''0000RRRRRRIIIIIIIIIIIIII
|
| R,C
|
| see docs
| O
|
| move code pointer (unconfirmed for c2)

|-
|25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S: S
|
| D
| absolute value

|-
|26/0x1A
| ?
| '''00011010'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|27/0x1B
| ?
| '''00011011'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|28/0x1C
| ?
| '''00011100'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|29/0x1D
| ?
| '''00011101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = (R + TICKS) % L
|O
|
| get ticks

|-
|31/0x1F
| ?
| '''00011111'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|32/0x20
| ?
| '''00100000'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|33/0x21
| ?
| '''00100001'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|34/0x22
| ?
| '''00100010'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|35/0x23
| ?
| '''00100011'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|36/0x24
| ?
| '''00100100'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|37/0x25
| ?
| '''00100101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|38/0x26
| ?
| '''00100110'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|39/0x27
| ?
| '''00100111'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|40/0x28
| ?
| '''00101000'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|41/0x29
| ?
| '''00101001'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|42/0x2A
| ?
| '''00101010'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|43/0x2B
| ?
| '''00101011'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|44/0x2C
| ?
| '''00101100'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|45/0x2D
| ?
| '''00101101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|46/0x2E
| ?
| '''00101110'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|47/0x2F
| NOP
| '''00101111'''????????????????????????
|
|
|
|
|
|
| no operation

|-
|48/0x30
| ?
| '''00110000'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|49/0x31
| RET
| '''00110001'''????????????????????????
|
|
|
|
|
|
| conditionally stop gool execution

|-
|50/0x32
| BRA
| '''00110010'''????????????????????????
|
|
|
|
|
|
| branch

|-
|51/0x33
| BNEZ
| '''00110011'''????????????????????????
|
|
|
|
|
|
| branch not equal zero

|-
|52/0x34
| BEQZ
| '''00110100'''????????????????????????
|
|
|
|
|
|
| branch equal zero

|-
|53/0x35
| ?
| '''00110101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|54/0x36
| ?
| '''00110110'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|55/0x37
| ?
| '''00110111'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|56/0x38
| ?
| '''00111000'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|57/0x39
| ?
| '''00111001'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|58/0x3A
| ?
| '''00111010'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|59/0x3B
| ?
| '''00111011'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|60/0x3C
| ?
| '''00111100'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|61/0x3D
| ?
| '''00111101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|62/0x3E
| ?
| '''00111110'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|63/0x3F
| ?
| '''00111111'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|64/0x40
| ?
| '''01000000'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|65/0x41
| ?
| '''01000001'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|66/0x42
| ?
| '''01000010'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|67/0x43
| ?
| '''01000011'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|68/0x44
| ?
| '''01000100'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|69/0x45
| ?
| '''01000101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|70/0x46
| ?
| '''01000110'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|71/0x47
| ?
| '''01000111'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|72/0x48
| ?
| '''01001000'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native code

|-
|74/0x4A
| ?
| '''01001010'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|75/0x4B
| ?
| '''01001011'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|76/0x4C
| ?
| '''01001100'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|77/0x4D
| ?
| '''01001101'''????????????????????????
|
|
|
|
|
|
| unknown

|-
|78/0x4E
| ?
| '''01001110'''????????????????????????
|
|
|
|
|
|
| unknown
|}
</div>

=== GOOL Instruction Operands ===
...
* In/Source type operands
** Explicitly specified (i.e. origin = determined by operand's corresponding bitfield from the instruction)
*** GOOL in/source operand
*** Immediate operand
** Implicitly specified (i.e. origin = top of object's stack; implicitly popped from top of object's stack)
*** Stack in/source operand
* Out/Destination type operands
** Explicitly specified (i.e. target = determined by operand's corresponding bitfield from the instruction)
*** GOOL out/destination operand
** Implicitly specified (i.e. target = top of object's stack; implicitly pushed to top of object's stack)
*** Stack out/destination operand/result*
<nowiki>*</nowiki>technically not an 'operand', but rather a ''result'' of the instruction's overall operation; it is implied that instructions that use [an] operand(s) of this type always pushes it/them (i.e the result(s)) to the top of the object's stack.

==== Explicit Operands ====
A GOOL instruction's explicit operands are ''explicitly'' specified in its lower 24 bits (operand portion). Each explicitly specified operand is either an immediate operand, or a GOOL operand.

===== Immediate Operands =====
An immediate operand ''directly'' specifies its value in its corresponding bitfield (within the operand portion) of the instruction. The number of immediate operands and their positions/bit-lengths varies between instructions.

Immediate Operands are in operands (source operands).

===== GOOL Operands =====
Conversely, a GOOL operand is specified as a ''reference'' to its actual value or destination location. Each GOOL operand is 12 bits in length; a GOOL instruction may require the specification of at most 2 GOOL operands, within the upper and/or lower halves of its operand portion, respectively. The 12 bit GOOL reference that specifies a GOOL operand encodes a [32 bit] pointer to its corresponding source value and/or destination location. Operations for instructions that require GOOL operand specification first translate the corresponding GOOL reference(s) to yield their decoded pointer(s) before accessing pointed data.

See the GOOL Reference Translation section for more information.

Depending on how a GOOL operand is used by its instruction, it may be an ''in'' (source) operand, an ''out'' (destination) operand, or both (''inout'' operand). If an instruction only reads the [input] value located by its translated GOOL operand (a pointer), it is an ''in'' (source) operand. If an instruction only writes a result/value to the location of its translated GOOL operand, it is an ''out'' (destination) operand. If an operand meets both of these criteria it is an ''inout'' operand.

==== Implicit Operands ====
===== Implicit In Operands =====
Some GOOL instructions may require the ''implicit'' specification of one or more (implicit) in operands. In operands are implicitly specified prior to an instruction's interpretation by pushing their value(s)-which must remain the topmost values at interpretation-to the object's stack. It is implied that these so-called implicit operands will exist on the stack for the instruction to pop and use as input.
===== Implicit Out Operands =====
For most GOOL instructions, the net effect of their operation involves an implicit push of one or more results to the object's stack. That is-it is implied or expected that these instructions will ultimately push their results to the object's stack.

=== GOOL Reference Translation ===
The following table lists the encoding format, potential type name, and a descriptive type name for each of the possible GOOL reference types:

<div style="font-family:monospace;">
{| class="article-table"
!Format
!Potential Type Name
!Descriptive Type Name
|-
|00RRRRRRRRRR
|Ireg Ref
|object local executable data pool reference
|-
|01RRRRRRRRRR
|Pool Ref
|object external executable data pool reference
|-
|100IIIIIIIII
|Int Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 256 (range: -32768 - 32512)
|-
|10110SSSSSSS
|Stack Ref
|object frame argument/local variable reference [peek stack @ location relative to fp]
|-
|101111100000
|Null Ref
|null reference (translates to 0)
|-
|101111110000
|Sp-Double Ref
|double stack pop reference (translates to 1)
|-
|110LLLMMMMMM
|Reg Ref
|object link memory reference
|-
|111MMMMMMMMM (M != 0x1F)
|Var Ref
|object field/memory reference
|-
|111000011111
|Stack Pop/Push
|stack pop/push reference
|}
</div>
Potential GOOL Reference type names have been deduced based on what appears to be an unreferenced array of GOOL interpreter debug strings at 0x103B8.

==== Stack Pop/Push ====
{| class="article-table" border="1" style="font-family:monospace;"
!Format
! colspan="3" |Description
|-
|111000011111
| colspan="3" |Stack Pop/Push Reference
|}
A GOOL reference of this format translates differently depending on whether the operand that specifies it is an ''in'' operand or an ''out'' operand:
* ''In'' operands specified as a reference of this type translate to a pointer to the top of the object's stack after an ensuing pop of the value located there (i.e. stack pointer is decremented).
* ''Out'' operands specified as a reference of this type translate to a pointer to the top of the object's stack prior to an incrementation of its stack pointer. A stack push will result from the translation's incrementing of the object's stack pointer and the instruction's ultimate dereferencing of the returned/translated pointer for a write.

==== Var Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |111FFFFFFFFF
| colspan="3" |Object Field/Memory Reference
|-
!Field
!Description
!Domain
!Range
!
|-
|F
|Object Field Index
|0 to 0x1FF
|0x60 to 0x860
|R = 4N
|}
GOOL References of this format translate to a pointer to the <code>A</code>th object field in relation to the object's <code>self</code> field.

Most of an object's significant fields are located past a <code>0x60</code> byte offset from the beginning of its structure-i.e. past its <code>self</code> field. Note that the last of these fields is the object's array of/address space for its [local] memory where its global variables and stack contents are stored. Because object fields are 4 bytes in size and an object's <code>self </code>field is located at a 0x60 byte offset from the beginning of its structure, then the formula:

<code>0x60 + (A * 4)</code>

gives the byte offset of the actual field located by the translated pointer.

If <code>A</code> = <code>0x1F</code>, then the reference will have the format <code>111000011111</code>; this is, however, already defined as the format for a stack pop/push reference-the processing of which takes precedence over that of var references. Notice that if such a reference were not instead translated as a stack pop/push reference, its translated pointer would locate the field at byte offset <code>0x60 + (0x1F * 4) = 0xDC</code>-the object's stack pointer. Then, it should not be possible to directly modify an object's stack pointer by accessing a translated reference. Only indirectly via translation of a stack push/pop reference should the object's stack pointer be modified.

==== Reg Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |110LLLFFFFFF
| colspan="3" |Object Link Field/Memory Reference
|-
!Field
!Description
!Domain
!Range
!
|-
|F
|Link Object Field Index
|0 to 0x3F
|0x60 to 0x15C
|R = 4N
|-
|L
|Object Link Index
|0 to 7
|0x60 to 0x7C
|R = 4N
|}
GOOL references of this format translate to a pointer to the <code>A</code>th object field in relation to the object's <code>B</code>th link object's <code>self</code> field. An object's ''link objects'' are referred to by the group of 8 object pointers beginning with its <code>self</code> field; the first of these pointers is the object's <code>self</code> link, the second a pointer to its <code>parent</code> object, the third a pointer to its <code>sibling</code> object, and so on.

==== Ireg Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |00RRRRRRRRRR
| colspan="3" |Object Local Executable Data Pool Reference
|-
!Field
!Description
!Domain
!Range
!
|-
|R
|Index of Value in Pool
|0 to 0x3FF
|0 to 0xFFC
|R = 4N
|}
GOOL references of this format translate to a pointer to the predefined constant long at an offset of <code>R</code> longs relative to the beginning of the object's local executable's constant data pool item.

A GOOL executable's constant data pool item is essentially a table of predefined constants. For example, it includes the EIDs of any entries, preconfigured bitfields and bit selectors, audio sample parameters (volume, pan, etc), specific speeds or velocities, and other constants referenced by this type.

NOTE: if an instruction's ''out'' operand is specified as a reference of this type, its operation will ultimately replace the constant at the translated location with its output result. A write to the executable's data pool should generally be avoided unless a global change to that constant, and therefore an equal change in behavior for each object that is an instance of that executable, is desired.

==== Pool Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |01RRRRRRRRRR
| colspan="3" |Object External Executable Data Pool Reference
|-
!Field
!Description
!Domain
!Range
!
|-
|R
|Index of Value in Pool
|0 to 0x3FF
|0 to 0xFFC
|R = 4N
|}
GOOL references of this format translate to a pointer to the predefined constant long at an offset of <code>R</code> longs relative to the beginning of the object's external executable's constant data pool item.

The same considerations for ireg refs apply to pool refs.

==== Frac Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |100CCCCCCCCC or
100IIIIIFFFF
| colspan="3" |Reference to Constant Multiple of 16
|-
!Field
!Description
!Domain
!Range
!
|-
|C
|Constant that will
be multiplied by 16
|0 to 0x1FF
| -8192 to 8176
-0x2000 to 0x1FF0

-16.0 to 15.9375?
|R = 16N
R = 0x10N

R = 0.0625N
|-
|I
|Integral Portion?
|0 to 0x1F
| -15 to 16
|R = 1N
|-
|F
|Fractional Portion?
|0 to 15
|0 to 0.9375
|R = 0.0625N
|}
GOOL references of this format translate to a pointer to the value <code>(16*C)</code>.

Two signed long ''constant buffers'' are located at offsets <code>0x40</code> and <code>0x44</code>, respectively, in scratch memory (as referenced by the pointer at memory location <code>0x56480</code> [<code>gp$(0x44)</code>].) At any point during the game's execution, the ''currently active constant buffer'' is either the buffer at offset <code>0x40</code> or <code>0x44</code>, and is indicated by either a <code>0</code> or a <code>1</code> in the unsigned long at memory location <code>0x56484</code> [<code>gp$(0x48)</code>]. Translation for references of this format consists of the following steps:
*Write the value <code>(16*C)</code>-that is, 16 times the value specified by the <code>C</code> bits-to the currently active constant buffer.
*Swap the currently active and inactive constant buffers (that is, if <code>0</code> previously indicated the currently active constant buffer, change it to a <code>1</code>; conversely, if it is a <code>1</code>, change it to a <code>0</code>).
*Return a pointer to the <code>(16*C)</code> signed long value in the buffer it was written to (which, after the swap, will always be the currently inactive buffer.)

This double-buffer allows the sufficient specification of up to 2 constant type GOOL references per instruction; each of the 2 buffers will keep track of up to 2 constants to be used by operations of instructions with the corresponding operands.

<code>C</code> can be specified as a negative constant with the following 2's complement format:

* <code>C = 1NNNNNNNN (-N): V = 11111111111111111111NNNNNNNN0000 (16 * -N)</code>
* <code>C = 0NNNNNNNN ( N): V = 00000000000000000000NNNNNNNN0000 (16 * N)</code>

Where <code>V</code> is the calculated signed long that will be written to the appropriate constant buffer for the specified formats of <code>C</code>.

Note: ''out'' operands are not meant to specify a reference of this type; any that do so are useless. Translation of this reference type returns a pointer to the currently inactive constant buffer after storing the appropriate constant value <code>(C * 16)</code> in the currently active constant buffer and then swapping the 2 buffers. The constant value in the inactive constant buffer would ultimately be overwritten with an expected result of the instruction with the out operand. However, since that buffer could only be accessed via subsequent translation of another frac or int ref, which would involve first overwriting its current value (the result) with a new constant value, then that result could never be accessed [without first being overwritten].

==== Int Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |1010IIIIIIII
| colspan="3" |Reference to Constant Multiple of 256
|-
!Field
!Description
!Domain
!Range
!
|-
|I
|Constant (int) that will
be multiplied by 256
|0 to 0xFF
| -32768 to 32512
-0x8000 to 0x7F00
|R = 256N
R = 0x100N
|}
GOOL references of this format are translated almost identically to frac refs; the only difference is in the calculation for the constant written to the buffer:

* <code>I = 1NNNNNNN (-N): V = 1111111111111111NNNNNNNN00000000 (256 * -N)</code>
* <code>I = 0NNNNNNN ( N): V = 0000000000000000NNNNNNNN00000000 (256 * N)</code>

The same considerations for frac refs apply to int refs.

==== Stack Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |10110SSSSSSS
| colspan="3" |Object Frame Argument/Local Variable Reference [peek stack at location relative to fp]
|-
!Field
!Description
!Domain
!Range
!
|-
|S
|Argument/Local Variable Index/Offset
relative to object fp
|0 to 0x7F
-64 args to +63 local vars
| -0x100 to 0xFC
|R = 4N
|}
GOOL references of this format translate to a pointer to the long that is <code>S</code> longs (<code>4*S</code> bytes) relative to the object's current frame pointer. If <code>S</code> is specified as a negative value/offset, it refers to an argument; this is because arguments are located ''before'' the start of the stack frame. If <code>S</code> is specified as a positive offset (> 3), it refers to a local variable (i.e. operation result).

<code>S</code> can be specified as a negative offset with the following 2's complement format:

* <code>S = 1NNNNNN (-N): O = 111111111111111111111111NNNNNN00 (4 * -N)</code> (argument offset)
* <code>S = 0NNNNNN ( N): O = 000000000000000000000000NNNNNN00 (4 * N)</code> (local variable offset)

==== Null Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |101111100000 = 0xBE0
| colspan="3" |Null Reference
(translates to <code>0</code>)
|}
GOOL references of this format translate to the value <code>0</code> (i.e. invalid pointer to address <code>0</code>). Some instructions will return without making any calculations or pushing any results if an operand is specified as a reference of this type.

Most other instructions do not account for translated references of this type. They assume that a translated reference will always point to a valid memory location. After these instructions translate a null ref, they will attempt to access the memory at address <code>0x0</code>-which lies in the kernel code segment-thus resulting in a trap.

In the instruction table, brackets '[]' around one or more of an instruction's explicit operands (*given that parenthesis '()' are not listed around any other operand) indicate that, if any of those operands are specified as null refs, the instruction will return before performing their associated calculations. Brackets '[]' around one or more of an instruction's implicit operands (*given that parenthesis '()' are not listed around any other operand) indicate that, if the 'corresponding' explicit operands are specified as null refs, they (the implicit operands) do not actually exist. The order in which associated calculations are performed is indicated by the nested bracketing of operands.

For example, the <code>PSHV</code> instruction is listed with explicit GOOL in operands <code>[A,[B]]</code>, and implicit stack out operands <code>[I,[J]]</code>-aliases for the respective destinations of two subsequent stack pushes. These operand nestings indicate that:

* If only operand <code>B</code> is specified as a null ref, the instruction returns before operation <code>J = B</code> (equivalently, <code>push(obj,B)</code>) is performed. As a result, only operation <code>I = A</code> (equivalently, <code>push(obj,A)</code>) is performed.
* If operand <code>A</code> is specified as a null ref, the instruction returns before <code>push(obj,A)</code> is performed; then <code>push(obj,B)</code> is also never performed-so the instruction does nothing. It does not matter whether or not <code>B</code> is a null ref because its associated calculation/operation (i.e. push to stack) is never performed.
* If neither operand <code>A</code> nor operand <code>B</code> are specified as null refs, both/all operations-<code>push(obj,A)</code> followed by <code>push(obj,B)</code>-are performed.

==== SP-Double Ref ====
{| class="article-table" border="1" style="font-family:monospace;"
! colspan="2" |Format
! colspan="3" |Description
|-
| colspan="2" |101111110000 = 0xBF0
| colspan="3" |Double Stack Pop Reference
(translates to <code>1</code>)
|}
GOOL references of this format translate to the value <code>1</code> (i.e. invalid pointer to address <code>1</code>). Specification of sp-double refs is exclusive to a few specific instructions. Most instructions do not account for translated references of this type. They assume that a translated reference will always point to a valid memory location. After these instructions translate an sp-double ref, they will attempt to access the memory at address <code>0x1</code>-which lies in the kernel code segment-thus resulting in a trap.

For a few instructions, if [a specific] one of their operands is explicitly specified as an sp-double ref, the actual values for both that operand and some other operand will be implicitly popped (in 2 subsequent pops) from the object's stack; no actual translation of the reference is performed. Alternatively, if that operand is not specified as an sp-double ref, then it is a valid reference to its actual value (and will be translated to a pointer that can be dereferenced to resolve that value); the other operand will then instead take on some ''default'' value.

In the instruction table, parenthesis '()' around one of an instruction's explicit operands indicate that: if that operand is specified as an sp-double ref, the instruction will pop the actual values for the bracketed '[]' pair of implicit stack in operands including that operand, in the order listed; otherwise the operand is a valid reference to its actual value, and its paired operand-for example, <code>P</code>-will take on a default value of <code>V</code>, where <code>P = V</code> is listed as an explicit immediate operand for that instruction.

For example, the <code>PATH</code> instruction is listed with explicit GOOL in operands <code>(A),B</code>, explicit immediate in operand <code>R = 0x100</code>, and implicit stack in operands <code>[R,A]</code>. If operand <code>A</code> is specified as an sp-double ref, the values for <code>R</code> and <code>A</code> will be popped from the object's stack, in that order. Otherwise, <code>R</code> [rate of path travel] will take on a default value of <code>0x100</code> (<code>1.0</code>) and <code>A</code>'s reference will be translated to resolve its value (by dereferencing, just as the majority of other instructions do for GOOL operands.)

=== GOOL Instruction Operations ===
TBD

GOOL Executable

2019-04-27T17:44:33Z

Chekwob: 2 revisions imported: Initial import from Wikia

A GOOL Executable is a type of entry that describes the behavior or application of a particular type of game object. GOOL executables contain a header, executable compiled [GOOL] bytecode, a constant pool, a mapping of subtypes to [initial] states, a mapping of events to states/interrupts, state descriptors, and animation sequence, text, and sprite descriptors. They are Type 11 entries.

== Format ==

=== Item 1: Header ===
{| class="article-table"
|+Item 1: Header
!Offset
!Field
!Size
!Value
|-
|0x0
|Object Type
|4 bytes
|
|-
|0x4
|Object Category
|4 bytes
|
|-
|0x8
|unknown
|4 bytes
|
|-
|0xC
|Initial Stack Frame Offset
|4 bytes
|
|-
|0x10
|Subtype->State Map Index
|4 bytes
|s
|-
|0x14
|unknown
|4 bytes
|
|}

=== Item 2: Executable Bytecode ===
{| class="article-table"
|+Item 2: Executable Bytecode
!Offset
!Field
!Size
!Value
|-
|0x0
|Code
|* x 4 bytes
|*
|}

=== Item 3: Constant Data Pool ===
{| class="article-table"
|+
Item 3: Constant Data Pool
!Offset
!Field
!Size
!Value
|-
|0x0
|Data
|* x 4 bytes
|*
|}

=== Item 4: State Map ===
{| class="article-table"
|+Item 4: State Map
!Offset
!Field
!Size
!Value
|-
|0x0
|Event->State/Interrupt Map
|s x 2 bytes
|*
|-
|0x0 + (2 x s)
|Subtype->State Map
|* x 2 bytes
|*
|}
<nowiki>*</nowiki>0xFF is a null state

=== Item 5: State Descriptors/Definitions ===
{| class="article-table"
|+Item 5: State Descriptors/Definitions
!Offset
!Field
!Size
!Value
|-
|0x0
|State Descriptors
|* x 16 bytes
|*
|-
| colspan="4" |(format of state descriptor ''d'')
|-
|(''d'' x 16) + 0x0
|State Flags
|4 bytes
|*
|-
|(''d'' x 16) + 0x4
|Object Status C Flags
|4 bytes
|*
|-
|(''d ''x 16) + 0x8
|External Executable EID (*index in const pool)
|2 bytes
|*
|-
|(''d ''x 16) + 0xA
|Event Block Program Counter Offset
|2 bytes
|*
|-
|(''d ''x 16) + 0xC
|Trans Block Program Counter Offset
|2 bytes
|*
|-
|(''d ''x 16) + 0xE
|Code Block Program Counter Offset
|2 bytes
|*
|}

=== Item 6: Animation Descriptors ===
{| class="article-table"
|+
Item 6: Animation Descriptors
!Offset
!Field
!Size
!Value
|-
|0x0
|Animation Descriptors
|* x * bytes
|
|}
Animation descriptors are stored contiguously, occupying the 6th item of the GOOL executable entry. Each type of animation descriptor has a different structure; the size of an animation descriptor is entirely dependent upon its type.

==== Type 1 - Vertex Animation ====
Type 1 animation descriptors simply specify an SVTX entry that contains their representative vertex animation. This is the most frequently used type.
{| class="article-table"
|+
Animation Descriptor Type 1 format
!Offset
!Field
!Size
!Value
|-
|0x0
|Type
|1 byte
|1
|-
|0x1
|Unused
|1 byte
|*
|-
|0x2
|Frame Count
|1 byte
|c
|-
|0x3
|Unused
|1 byte
|*
|-
|0x4
|SVTX Model EID
|4 bytes
|*
|}

==== Type 2 - Sprite Animation ====
Type 2 descriptors specify a separate square for each frame of animation, each square to be transformed and rendered as a blended textured quad. Square dimensions are not specified in the descriptor but are calculated from the instanced object's scale vector.
{| class="article-table"
|+
Animation Descriptor Type 2 format
!Offset
!Field
!Size
!Value
|-
|0x0
|Type
|1 byte
|2
|-
|0x1
|Unused
|1 byte
|*
|-
|0x2
|Frame Count
|1 byte
|c
|-
|0x3
|Unused
|1 byte
|*
|-
|0x4
|Texture Page EID
|4 bytes
|*
|-
|0x8
|CLUT/Texture info
|c x 2 x 4 bytes
|
|}

Type 3 - Font Map

Type 3 descriptors associate with each ascii character, in lexicographic order, a separate region (location/dimensions determined by texture and color info) of a specified Texture Page. Also specified for each region are the dimensions of a textured blended quad to be rendered, with that [region of the texture page as its] texture. Type 4 descriptors, which specify a string of text, will reference a type 3 descriptor. As characters in the type 4 descriptor string are stepped through, the referenced type 3 descriptor will determine the corresponding quads to be rendered. The Type 3 descriptor may additionally specify a separate region of the texture page as [the texture for] a text backdrop [quad].
{| class="article-table"
|+
Animation Descriptor Type 3 format
!Offset
!Field
!Size
!Value
|-
|0x0
|Type
|1 byte
|2
|-
|0x1
|Unused
|1 byte
|*
|-
|0x2
|Font Map Length
|1 byte
|c
|-
|0x3
|Unused
|1 byte
|*
|-
|0x4
|Texture Page EID
|4 bytes
|*
|-
|0x8
|Font Map
|c x 12 bytes
|*
|-
| colspan="4" |(font mapping structure ''d'')
|-
|0x8 + (''d ''x 12) + 0x0
|CLUT info
|4 bytes
|*
|-
|0x8 + (''d ''x 12) + 0x4
|Texture info
|4 bytes
|*
|-
|0x8 + (''d'' x 12) + 0x8
|Character Width
|2 bytes
|*
|-
|0x8 + (''d ''x 12) + 0xA
|Character Height
|2 bytes
|*
|-
| colspan="4" |(end)
|-
|0x8 + (''c'' x 12) + 0x0
|Backdrop CLUT info
|4 bytes
|*
|-
|0x8 + (''c ''x 12) + 0x4
|Backdrop Texture info
|4 bytes
|*
|}

==== Type 4 - Text Animation ====
Type 4 descriptors specify a separate string of text for each frame of animation. They also specify the offset of a source font map (Type 3 descriptor) to use to render that text.
{| class="article-table"
|+
Animation Descriptor Type 4 format
!Offset
!Field
!Size
!Value
|-
|0x0
|Type
|1 byte
|4
|-
|0x1
|Unused
|1 byte
|*
|-
|0x2
|String/Frame Count
|1 byte
|c
|-
|0x3
|Unused
|1 byte
|*
|-
|0x4
|Unknown
|4 bytes
|*
|-
|0x8
|Font Map Offset
|4 bytes
|*
|-
|0xC
|Strings
|c x * bytes
|*
|}

Each string ends with a null terminator character (\0) and can have up to 4 individual format specifiers (beginning with %); they are processed with a call to printf, with 4 corresponding arguments the 2nd, 3rd, 4th, and 5th words, respectively, before (or below) the top of the instanced object's stack.

These strings can also contain several types of ''extended'' format specifiers. These begin with a tilde '~' and can be specified as one of the following:
{| class="article-table"
!Specifier
!Output/Function
|-
|~n
|Newline
|-
|~%
|Newline
|-
|~c0
|Disable shading (inst. obj's. color matrices will ''not'' affect proceeding chars)
|-
|~c1
|Enable shading (inst. obj's. color matrices ''will'' affect proceeding chars)
|-
|~p#
|Skips the following character if the value at (2 + #) count words before/below
the top of the instanced objects stack is 1. Used to auto change from singular

to plural forms of the noun(s) introduced by the corresponding cardinal

determiner (i.e. 1 'box' to n 'boxes' for n != 1)
|-
|~sx####
|Set width of following character to # (min 1, max 4 digits)
|-
|~sy####
|Set height of following character to # (min 1, max 4 digits)
|}
<nowiki>*</nowiki> if the instanced object has bit 11 of its statusb flags set, rendering of the text will include a backdrop that spans the area occupied by the text.

==== Type 5 - Fragment Animation ====
Type 5 descriptors specify a number of rectangles that compose a miniature model for each frame of animation. These are to be transformed and rendered as multiple blended textured quads.

This type is typically used for smaller objects such as fragments of exploding TNT and sparkling specks spawned by Aku Aku and by Warp Panels.
{| class="article-table"
|+
Animation Descriptor Type 5 format
!Offset
!Field
!Size
!Value
|-
|0x0
|Type
|1 byte
|5
|-
|0x1
|Unused
|1 byte
|*
|-
|0x2
|Frame Count
|1 byte
|c
|-
|0x3
|Unused
|1 byte
|*
|-
|0x4
|Texture Page EID
|4 bytes
|*
|-
|0x8
|Rectangle Count
|4 bytes
|r
|-
|0xC
|Rectangles
|c x r x 16 bytes
|*
|-
| colspan="4" |(Rectangle structure ''d'','' ''frame ''f'')
|-
|0xC + (''d ''x'' f ''x'' ''16) ''+ ''0x0
|CLUT info
|4 bytes
|*
|-
|0xC + (''d ''x ''f ''x 16) + 0x4
|Texture info
|4 bytes
|*
|-
|0xC + (''d ''x ''f ''x 16) + 0x8
|X1
|2 bytes
|*
|-
|0xC + (''d ''x ''f ''x 16) + 0xA
|Y1
|2 bytes
|*
|-
|0xC + (''d ''x ''f ''x 16) + 0xC
|X2
|2 bytes
|*
|-
|0xC + (''d ''x ''f ''x 16) + 0xE
|Y2
|2 bytes
|*
|}

Entity

2019-04-27T17:44:33Z

Chekwob: 20 revisions imported: Initial import from Wikia

:''This article is for the ''Crash 2/3'' entity format.''
An '''''entity''''' is an item that stores a collection of values (hereafter referred to as "fields") that can represent either a game [[object]] or a camera rail in Crash 2 and 3.
==Format==
{|class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Length of this item
|4 bytes
|*
|-
|0x4
|Unknown
|4 bytes x 2
|*
|-
|0xC
|Field count
|4 bytes
|hc
|-
|0x10
|Field info structures (headers)
|hc * 8 bytes
|*
|-
|>=0x18
|Field data structures (data)
|(varies)
|*
|-
!colspan="4"|''Field Info Structure''
|-
|0x0
|Type
|2 bytes
|*
|-
|0x2
|Offset to the ''field data'' relative to 12 bytes at the start of the item
|2 bytes
|offset
|-
|0x4
|Flags
|Byte
|*
|-
|0x5
|Element size
|Byte
|es
|-
|0x6
|Row count
|2 bytes
|rc
|-
!colspan="4"|''Field Data Structure''
|-
|0x0
|Element count
|2 bytes * rc
|ec
|-
|0x0 + rc * 2
|Metavalues
|2 bytes * rc
|*
|-
|0x0 + rc * 4
|Data
|es * ec * rc
|*
|-
|}

==Type==
The format and usage of the field data depends on the field type. Incomplete list.
{|class="article-table"
!Type
!Name
!Purpose
!Format
!Uses Metavalues?
|-
|0x2C
|Name
|String of characters for the internal name used to refer to the entity. Its only purpose is for the devs to distinguish entities so whatever you put here won't directly affect the game
|Unspecified
|No
|-
|0x4B
|Position
|List of position points to be used by the entity. More than one position can be used to make the entity follow a path (as long as it is programmed to do so)
|Int16 for each X, Y and Z coordinate
|No
|-
|0x9F
|ID
|Value to uniquely identify the entity that is used to draw it, destroy it (see victims below) and other miscellaneous behaviors
|Int32'''1'''
|No
|-
|0xA4
|General Settings
|List of values that can be used to change a certain object's behavior (i.e. flags, delay, speed)
|Int32 (UInt8 + Int24, but can be combined in different ways)
|No
|-
|0xA9
|Type
|Type of the entity
|Int32
|No
|-
|0xAA
|Subtype
|Variant of the entity
|Int32
|No
|-
|0x103
|SLST EID
|EID of the SLST [[entry]] to be used by this camera rail
|Int32
|No
|-
|0x109
|Neighbor camera rails (untested)
|Contains information about neighboring [[zone]]s
|Int32
|Yes
|-
|0x118
|Misc Settings 1
|???
|Int32
|No
|-
|0x13B
|Draw List A
|List of values that determine which entities should despawn while the camera is in this zone'''2'''
|Int32
|Yes
|-
|0x13C
|Draw List B
|List of values that determine which entities should spawn while the camera is in this zone'''2'''
|Int32
|Yes
|-
|0x208
|Load List A
|List of EIDs to load when the camera is in this zone
|Int32
|Yes
|-
|0x209
|Load List B
|List of EIDs to deload when the camera is in this zone
|Int32
|Yes
|-
|0x277
|Misc Settings 2
|Value that can be used to change a certain object's DDA behavior (i.e. deaths until DDA checkpoint) or other settings like Y rotation.
|Int32
|No
|-
|0x287
|Victim
|List of entity IDs to destroy on certain occasions (i.e. TNT is despawned, Nitro Switch activated)
|Int16
|No
|-
|0x288
|Section ID
|Value to uniquely identify a "section" of the level and is used in checkpoints for the game to know which DDA checkpoints have been triggered and at what point in the level the player is (i.e. First real checkpoint has this set to 1, the next DDA checkpoint will have a 1 too, the next real checkpoint will have a 2, etc.)
|Int32
|No
|-
|0x28B
|Box count
|Number of boxes in the level; Should only be used in obj_willy
|Int32
|No
|-
|0x30E
|Scale
|Indicates the scale of the object. ''Crash 3''-only; 1 = Position/4 in-game; 2 = Position/2 in-game; 3 = Normal; 4 = Position*2 in-game; etc.
|Int32
|No
|-
|0x336
|Time Trial crate type
|BoxOC-only. Affects what the crate will turn into during time trial mode. ''Crash 3''-only
|Int32
|No
|-
|0x337
|Bonus box count
|Number of boxes in the level's bonus; Should only be used in obj_willy. ''Crash 3''-only
|Int32
|No
|}
'''1''' Other lists store this as an Int16, so setting this to a value higher than the maximum value that can be stored in a 16-bit field (65535) may cause serious issues.

'''2''' The roles of draw lists is reversed when the camera is going backwards.

'''NOTE:''' When proceeding from one camera path to the next, all entities should be despawned at the "connection" point for proper disposal of resources. Same applies to entry loading and disposal, as the game seems smart enough not to dispose of resources it's also immediately told to load.

Entry point

2019-04-27T17:44:33Z

Chekwob: 3 revisions imported: Initial import from Wikia

An entry point locates the first section of code (subroutine) executed by a CPU after its source executable is loaded into main memory. A common symbolic name for the entry point routine is <code>start</code>.

== Entry point locations ==
The following lists the location of the entry point for each of the Crash games:

*Crash 1 - 0x3E018

== start() ==
The <code>start</code> routine sets the location of the global pointer, initializes the heap, and calls the <code>main</code> routine.

== main() ==
The <code>main</code> routine calls 3 subroutines. The first of these routines performs hardware initialization. The second contains the [[Game Loop|game loop]]. The third releases any resources allocated during hardware initialization. Prior to execution of these routines, the game loop condition at <code>0x56410</code> is set to true/1.

In each game, the level id for the 'initial level' is passed as an argument to the [[Game Loop|game loop routine]]. The initial level isn't actually a 'level' per-se, but rather a game state, which includes the title sequence, options menu, password menu (Crash 1), map (Crash 1), and game over screen.
__FORCETOC__
__NEWSECTIONLINK__

Entry

2019-04-27T17:44:33Z

Chekwob: 9 revisions imported: Initial import from Wikia

Entries are the intermediate level data containers in NSF files. They are containers for 'items'-the lowest level data containers in NSF files.

== Format ==
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Magic Number
|4 bytes
|0x100FFFF
|-
|0x4
|ID
|4 bytes
|*
|-
|0x8
|Type
|4 bytes
|*
|-
|0xC
|Item Count
|4 bytes
|c
|-
|0x10
|Item Offsets
|c x 4 bytes
|*
|-
|0x10 + (c x 4)
|Items
|c x * bytes
|*
|}

== Structure ==
<syntaxhighlight lang="cpp">
struct entry
{
const unsigned long magic = 0x100FFFF;
unsigned long EID;
unsigned long type;
unsigned long itemcount;
union
{
unsigned long itemoffset[itemcount];
item *itemptr[itemcount];
};
item items[itemcount];
};
</syntaxhighlight>
== Types ==
An entry's type determines the specific kind of content contained in its items.
{| border="1"
|Type
|Name
|Subsystem
|Description
|-
|1
|Object Model Vertices/Animation
|SVTX
|contains multiple key frames of animation for an object
|-
|2
|Object Model Polygons
|TGEO
|contains polygons used by a Type 1 entry
|-
|3
|World Geometry
|WGEO
|contains polygons and vertices for a section of the level
|-
|4
|Display List
|SLST
|contains delta encoded display lists, describing the change in z-ordering of polygon primitives at each point of a corresponding camera path
|-
|5
|Texture Page
|TPAG
|describes texture/palette data used by polygons
|-
|6
|Level Data
|LDAT
|contains a level's initial settings such as Crash's starting location
|-
|7
|Zone Data
|ZDAT
|contains a 'zone' - a collection of world models to render, objects to spawn, a camera path, collision octree, and misc attributes
|-
|11
|GOOL Executable
|GOOL
|contains a header, compiled GOOL bytecode, const pool, state map, state descriptors, and animation sequence/text/sprite descriptors for an object
|-
|12
|Audio
|ADIO
|contains audio data for a sound effect
|-
|13
|MIDI
|MIDI
|contains the MIDI sequence(s) for a level's background music and/or a wavebank header (VH)
|-
|14
|Instruments
|INST
|describes instruments used to play a MIDI
|-
|15
|Image Data (Crash 1) Video Collision (Crash 2/3)
|IMAG (Crash 1) VCOL (Crash 2/3)
|contains image data (i.e. anti-piracy message, SCE screen)1 (Crash 1) contains special collision detection rules? (i.e. digging, chased by boulder) (Crash 2/3)
|-
|17
|Map Data (Crash 1) Raw Data (Crash 3)
|MDAT (Crash 1) RAWD (Crash 3)
|contains data describing how a new level should be loaded when selected (Crash 1) contains miscellaneous 3D terrain data (scenery in baron levels, water in levels with water) (Crash 3)
|-
| 18
|Palettes for fading transitions
|IPAL
|describes the CLUTs used during a fade transition
|-
|19
|Demo playback
|PBAK
|contains a pre-recorded sequence of button presses for playback
|-
|20
|Cutscene Model
Vertices/Animation (Crash 1) Speech Audio (Crash 2/3)
|CVTX (Crash 1) SDIO (Crash 2/3)
|contains vertices for cutscene models (Crash 1) contains speech audio (Crash 2/3)
|-
|21
|2D Animation/Video (Crash 2/3)
|VIDO (Crash 2/3)
|contains data for a sprite animated or not (i.e. mount texture while digging, warp portal, save icons)
|}
1 - NSD files may contain these kinds of entries, but without any header.

== Entry IDs/EIDs ==
Like chunks, each entry has also been assigned a unique ID. Unlike CIDs, however, entry IDs (EIDs) have not been precomputed based on index. Each EID encodes a unique 5 character identifier string. Each entry has been assigned an EID that encodes an appropriate identifier.

=== Encoding scheme ===
EIDs use the following [32 bit] encoding scheme:

0EEEEEEDDDDDDCCCCCCBBBBBBAAAAAA1

where the [6 bit] fields A, B, C, D, and E, respectively, in that order, are indices of 5 characters in the following conversion table:
{| class="article-table"
|Index
|0
|1
|2
|3
|4
|5
|6
|7
|8
|9
|A
|B
|C
|D
|E
|F
|-
|Char
|0
|1
|2
|3
|4
|5
|6
|7
|8
|9
|a
|b
|c
|d
|e
|f
|-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Index
|10
|11
|12
|13
|14
|15
|16
|17
|18
|19
|1A
|1B
|1C
|1D
|1E
|1F
|-
|Char
|g
|h
|i
|j
|k
|l
|m
|n
|o
|p
|q
|r
|s
|t
|u
|v
|-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Index
|20
|21
|22
|23
|24
|25
|26
|27
|28
|29
|2A
|2B
|2C
|2D
|2E
|2F
|-
|Char
|w
|x
|y
|z
|A
|B
|C
|D
|E
|F
|G
|H
|I
|J
|K
|L
|-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Index
|30
|31
|32
|33
|34
|35
|36
|37
|38
|39
|3A
|3B
|3C
|3D
|3E
|3F
|-
|Char
|M
|N
|O
|P
|Q
|R
|S
|T
|U
|V
|W
|X
|Y
|Z
|_
|!
|}

The conversion table above is used by the EID encoding and decoding routines and is located at the following addresses in each of the Crash games:
* Crash 1 - <code>0x51728</code>

=== Null EID ===
The EID with value <code>0x6396347F</code>, which translates to <code>NONE!</code>, is used frequently throughout the game code. It represents a null EID.
[[Category:Structure]]

Main Page

2019-04-27T17:44:32Z

Chekwob: 14 revisions imported: Initial import from Wikia

Camera Update

2019-04-27T17:44:32Z

Chekwob: 1 revision imported: Initial import from Wikia

'''UNFINISHED'''

Each game tracks the camera's current progress within a level with the following:
* Current zone in which the camera resides
* Current path, in that zone, that the camera is travelling
* Current progress of the camera along that path
...

== Camera Follow Mode ==
In Camera Follow Mode, updating the camera refers to the process of recalculating the camera's current progress and updating the level [with the recalculated progress] as the player progresses towards (or digresses from) the goal. This may include updating the current zone if the camera and player venture into a neighboring zone and/or updating the current path if the camera and player pass either of its endpoints into territory of a neighboring path, along which the camera would follow closer to-providing a more appropriate view of the player.

The camera's current progress is determined by the index of the point in the current path that is closest to-not the player, but instead-a point otherwise known as the ''unprojected camera location'', which is located a number of units to the left or right (in the X direction), above or below (in the Y direction), and behind the player (in the Z direction). The camera is ultimately positioned at the location of the point with index equal to the current progress value. Note that, without the additional adjustments, the camera would be positioned directly at the player's approximate location along the path [i.e. closest point], which may fail to provide a full view of the player. For example, in forward/backward zones this would provide a sort of first-person view rather than a full view of the player; however, if the point were adjusted somewhat backwards, its closest point on the path would be a point that were approximately behind the player. In left/right zones this may not matter as their paths span left to right and are typically already positioned somewhat behind the player's roaming area.

At any instant there may be some point among [the current path's] neighboring paths that is closer to the unprojected camera location than any other point in the current path. This would mean that the player has progressed/retrogressed so far such that the unprojected camera location is now closer to [the point in] some neighboring path-and thus projects to a point that either passes the end or backtracks before the beginning of the current path. In these cases, the neighboring path with the point closest to the unprojected camera location is chosen to replace the current path.

=== Camera Follow Routine ===
The ''camera follow routine'' handles updating the camera in Camera Follow Mode. Its generalized operation is as follows:
# Calculate [updated] unprojected camera location
# Find the path among the current path and its neighbors [with point] closest to the unprojected camera location
# Update level with potentially any combination of the following:
#* A new current zone = if it is different from the current, the parent zone of the path closest to the unprojected camera location
#* A new current path = if it is different from the current, the path closest to the unprojected camera location
#* A new current progress = the index of the point closest to the unprojected camera location, in the path that contains it

==== Operation ====
Note: camera ''looks forward ''or ''looks backward ''do not actually refer to the ''camera'' looking forward or back. Instead, these refer to the camera looking to a point that is ''adjusted'' either forward or backward as the ''player ''looks forward or back.
# Calculate [updated] unprojected camera location
#* Determine the nearest neighboring camera paths [to the camera]
#** If current progress at less than half way or at most 50 points into the current path, nearest neighbors include all preceding neighbors
#** If current progress at or more than half way or at most 50 points from the end of the current path, nearest neighbors include all proceeding neighbors
#* Determine z look/x pan flags
#** If current zone intended for forward/backward travel
#*** If up is pressed, [set flag for] camera ''looks forward''
#*** If down is pressed, [set flag for] camera ''looks backward''
#** If current zone intended for left/right travel
#*** If left pressed, [set flag for] camera ''pans left''
#*** If right pressed, [set flag for] camera ''pans right''
#** If current zone not intended for forward/backward travel
#*** Camera is forced to either look forward or back, depending on zone flag
#* Determine z look/x pan factors
#** Increase or decrease ''z look'' factor at rate of 50 m/frame, depending on whether cam looks forward or backward; restrict this factor to the range -300m to 300m (*Cortex Power: -1200m to 1200m)
#** Increase or decrease ''x pan'' factor at rate of 100 m/frame, depending on whether cam pans left or right; restrict this factor to the range -300m to 0m [offsets left] if the current path travels left or to the range 0m to 300m [offsets right] if the current path travels right
#* Determine y pan/z zoom factors
#** If the current or at least one nearest neighbor path travels forward/backward and the current progress is at least 10 points into and from the end of the current path
#*** If the current path travels forward/backward, seek ''z zoom'' factor from its previous value towards the current path's <code>camzoom</code> value at a rate of 25 m/frame.
#*** Else if there exists a nearest forward/backward [travelling] neighbor, set ''z zoom'' factor to the neighbor's <code>camzoom</code> value
#** If the current or at least one nearest neighbor path travels up/down
#*** If the current path travels up/down, seek ''y pan'' factor from its previous value towards the current path's <code>camzoom</code> value at a rate of 100 m/frame.
#*** Else if there exists a nearest up/down [travelling] neighbor, set ''y pan'' factor to the neighbor's <code>camzoom</code> value.
#* Determine total z adjustment factor by sum of ''z look'', ''z zoom'', and player's <code>camzoom</code> value; let total x and y adjustment factors be ''x'' and ''y pan'' factors, respectively.
#* Calculate unprojected camera location by adding x, y, and z adjustment factors respectively to player location.
# Find the path among the current path and its neighbors that is ''closest'' to the unprojected camera location
#* For the current path
#** If the current path travels forward/backward
#*** TBD
#** If the current path does not travel forward/backward
#*** Calculate the unprojected camera location's projected progress along the current path
#**** Calculate vector ''a'' as the direction vector that spans from the current path's start location (i.e. position of initial point 0) to the unprojected camera location
#**** Let vector ''b'' be the current path's direction vector; graphically this refers to a unit vector that is a linear approximation of the path, starting at its start location and pointing in its direction
#**** Calculate the camera's projected distance along the current path by computing the scalar projection of ''a'' onto ''b''. Since ''b''-the path's direction vector-is already a unit vector, this is just the dot product of ''a'' and ''b''.
#**** Divide the camera's projected distance along the current path by the average distance between its path points. This directly converts the camera's projected distance along the path to the index of a point [along the path]-i.e. the camera's projected progress along the path.
#*** If the projected progress refers to a point before the path entrance or past the path exit (i.e. is an invalid point index)
#**** Reset progress to either the index of the first point or the last point in the path
#**** Mark the projected change in progress as non-existent
#*** Get the actual [projected] camera location at the projected progress point
#**** If this camera location is any more than 12.5 m from the unprojected camera location in either the x, y, or z dimension, then eliminate this path from being a potential closest
#*** Calculate and record euclidean distance from unprojected camera location to actual camera location; this is the equivalently the distance from the unprojected camera location to the [nearest point on the] path
#** If the path is still a potential closest
#*** Calculate and record the [absolute] projected change in progress by computing absolute value of the difference between current progress and projected progress
#*** If the [non-absolute] projected change shows a decrease in progress, mark the projected change as a digression; else if it shows an increase in progress, mark it as a progression
#* For each of the current path's nearest neighbors
#** If that neighbor path travels forward/backward
#*** TBD
#** If that neighbor path does not travel forward/backward
#*** Calculate the unprojected camera location's projected progress along that [neighbor] path
#**** This is done in the same way as for the current path
#*** If the path's parent zone header flags bit 19 set: if the path travels left/right and the unprojected camera location is more than 50m under the [initial point of] the path, eliminate this path from being a potential closest
#*** If this path and the current path both travel in the same y and z direction (i.e. either up-left, up-right, down-left, down-right, or do not at all travel up/down and left/right)
#**** If this path is in front of the current path (i.e. such that, if chosen as the new/closest path, the camera would 'enter' at its ''entrance'' point)
#***** If the projected progress lies before the path's entrance cutoff point, then eliminate this path from being a potential closest
#***** Else if the projected progress lies before the path's default entrance point (0), eliminate this path from being a potential closest
#**** Else if this path is behind the current path (i.e. such that, if chosen as the new/closest path, the camera would 'enter' at its ''exit'' point)
#***** If the projected progress lies after the path's exit cutoff point, then eliminate this path from being a potential closest
#***** Else if the projected progress lies after the end of the path/the path's default exit point, eliminate this path from being a potential closest
#*** Get the actual [projected] camera location at the projected progress point
#**** If this camera location is any more than 12.5 meters from the unprojected camera location in either the x, y, or z dimension, then eliminate this path from being a potential closest
#*** Calculate and record euclidean distance from unprojected camera location to actual camera location
#** If this path is still a potential closest, then calculate and record the total [absolute] projected change in progress:
#*** If this path is further from the goal than the current path
#**** ''From the perspective of the player as it faces towards the goal: ''if this path is in ''front'' of the current path
#***** This doesn't make sense. From the perspective of the player as it faces towards the goal, a path that is further from the goal than the current path must either be behind, to the left, to the right, above, or below it. this path could not possibly be in front of the current path if it is supposedly further from the goal; such paths do not exist in any zone entry of any NSF; an incorrect progress calculation will ensue for such paths
#**** ''From the perspective of the player as it faces towards the goal: ''if this path is ''behind'' the current path
#***** -the camera will 'exit' from the current path's ''front endpoint'' as the ''exit'' point
#***** -the camera will 'enter' at the new path's ''back endpoint'' as the ''entrance'' point
#***** Get the amount of progress so far accumulated in relation to the ''exit'' point or ''front'' of the ''current'' path-this is just the current progress. (The camera would first have to move back this amount to reach ''this'' path.)
#***** Get the projected amount of progress along ''this'' path [if it were chosen] in relation to its ''back'' endpoint (i.e. last point) as the ''entrance'' point
#****** Compute the absolute difference between current progress and projected progress
#****** Subtract the computed difference from the length of the path/index of its last progress point
#***** Sum the 2 progress amounts to get the total projected change in progress; record this value
#*** If this path is closer to the goal than the current path
#**** ''From the perspective of the player as it faces towards the goal: ''If this path is ''in front'' of the current path
#***** - the camera will 'exit' from the current path's ''back endpoint'' as the ''exit'' point
#***** - the camera will 'enter' at the new path's ''front endpoint'' as the ''entrance'' point
#***** Get the amount of progress that would need to be accumulated to reach the ''exit'' point of the ''current path''
#****** Compute difference of current path length [index of its last progress point] and current progress to find remaining progress
#***** Get projected amount of progress along ''this'' path [if it were chosen] in relation to its ''front'' ''endpoint'' (i.e. first point) as the ''entrance'' point
#****** Compute the absolute difference between current progress and projected progress
#***** Sum the 2 progress amounts to get the total projected change in progress; record this value
#**** ''From the perspective of the player as it faces towards the goal: ''If this path is ''behind'' the current path
#***** This doesn't make sense; see above. An incorrect progress calculation will ensue.
#* Using the information recorded for each of the potentially closest paths
#** Choose the closest path to the unprojected [updated] camera location (i.e. with minimum euclidean distance) for which it, preferably, would exhibit a projected change in progress [upon updating current progress using the total projected change]
#** If no path exists for which the updated camera location corresponds to a projected change in progress
#*** Return without updating level; not necessary
# Update level:
#* Approximate the distance between the current camera location and the new [updated] projected camera location: multiply change in progress recorded [for the chosen path] by the average distance between points in the current path (this converts the change in progress to a change in distance).
#** If this distance is less than .45778m?
#*** Record the projected change in progress as camera speed
#*** Update the level with new projected progress as the current progress; the camera will not have moved far and will thus remain on the current path, so there will be no change in and no updating of current path or zone
#** If this distance is greater than [or equal to] .45778m?
#*** Update camera speed
#**** If the projected change in progress is less than or equal to 2 points
#***** Set camera speed to half the projected change in progress
#**** If the projected change in progress is between 2 and 5 points
#***** Set camera speed to 2 points/frame
#**** If the projected change in progress is 5 or more points (impossible delta)
#***** Set camera speed to half the projected change in progress if it is more than camera speed; else increment camera speed by 1 point/frame
#*** Update the level with a new progress, given the updated camera speed
#**** If the projected change in progress would bring the camera ''closer to'' the goal
#***** If the chosen path [closest to the approximate camera location] is the current path
#****** Calculate an ''alternate new progress ''(used rather than the new projected progress) by adding camera speed to the current progress.
#****** Update the level with the alternate new progress as the current progress; the camera will remain on the current path, so there will be no change in and no updating of current path or zone
#***** If the chosen path is a neighboring path [rather than the current path], then the projected change in progress should bring the camera out of the current path and into that neighboring path-which is past the current path:
#****** Also, calculate an ''alternate new progress'' by adding camera speed to the current progress. For further verification that, at its ultimate new progress, the camera will indeed be brought into that neighboring path, if the alternate new progress would exceed the length of the path (i.e. cross the ''back endpoint''), then it would be an invalid progress-a progress which would instead refer to a point in the neighboring path past the current path: (else treat as if the chosen path were the current path; see above)
#******* Readjust the alternate new progress in relation to the ''front'' ''endpoint'' of the neighboring path
#******** Subtract length of the current path from the alternate new progress to get the amount of [the alternate new] progress that would exceed the ''back endpoint'' of the current path into the neighboring path
#******** If the neighboring path is behind the current path, negate the amount of exceeding progress
#******** Add this to the index of the neighboring path's ''front endpoint''
#******** Set the alternate new progress to this readjusted value
#******* Update the level with:
#******** The neighboring path's parent zone as the current zone
#******** The neighboring path as the current path
#******** Whichever is less: either the projected new progress or the alternate new progress, as the current progress.
#**** If the projected change in progress would bring the camera further from the goal
#***** If the chosen path [closest to the approximate camera location] is the current path
#****** Calculate an ''alternate new progress'' [used rather than the new projected progress] by subtracting camera speed from the current progress.
#****** Update the level with the alternate new progress as the current progress; the camera will remain on the current path, so there will be no change in and no updating of current path or zone
#***** If the chosen path is a neighboring path [rather than the current path], then the projected change in progress should bring the camera out of the current path and into that neighboring path-which is behind the current path.
#****** Also, calculate an ''alternate new progress'' by subtracting camera speed from the current progress. For further verification that, at its ultimate new progress, the camera will indeed be brought into that neighboring path, if the alternate new progress would be less than 0 (i.e. cross the ''front endpoint''), then it would be an invalid progress-a progress which would instead refer to a point in the neighboring path that falls short of the current path: (else treat as if the chosen path were the current path; see above)
#******* Readjust the alternate new progress in relation to the ''back endpoint'' of the neighboring path
#******** The amount of progress that exceeds the ''front endpoint'' of the current path into the neighboring path is just the current progress
#******** If the neighboring path is ''in front'' of the current path, negate the amount of exceeding progress
#******** Add this to the index of the neighboring path's ''back endpoint''
#******** Set the alternate new progress to this readjusted value
#******* Update the level with:
#******** The neighboring path's parent zone as the current zone
#******** The neighboring path as the current path
#******** Whichever is less: either the projected new progress or the alternate new progress, as the current progress.

Chunk

2019-04-27T17:44:32Z

Chekwob: 8 revisions imported: Initial import from Wikia

Chunks (a.k.a. pages) are the highest level data containers in NSF files. Each chunk is 64KB (0x10000 bytes) in size, in congruence with the 64KB pages allocated to contain them.

== Format ==

=== Uncompressed chunks ===

==== Non-texture chunks ====
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Magic Number
|2 bytes
|0x1234
|-
|0x2
|Type
|2 bytes
|!=1
|-
|0x4
|ID
|4 bytes
|*
|-
|0x8
|Entry Count
|4 bytes
|c
|-
|0xC
|Checksum
|4 bytes
|*
|-
|0x10
|Entry Offsets
|4 x c bytes
|*
|-
|0x10 + (4 x c)
|End of last Entry
|4 bytes
|*
|-
|0x10 + (4 x (c+1) )
|Entries
|* x c bytes
|*
|}

==== Texture chunks ====
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Magic Number
|2 bytes
|0x1234
|-
|0x2
|Type
|2 bytes
|1
|-
|0x4
|Texture Page EID
|4 bytes
|*
|-
|0x8
|Tex. Page Entry Type
|4 bytes
|5
|-
|0xC
|Checksum
|4 bytes
|*
|-
|0x10
|Texture data
|0xFFF0/65520 bytes
|*
|}

=== Compressed chunks ===
{| class="article-table"
!Offset
!Field
!Size
!Value
|-
|0x0
|Magic Number
|2 bytes
|0x1235
|-
|0x2
|Unused
|2 bytes
|*
|-
|0x4
|Length
|4 bytes
|l
|-
|0x8
|Skip
|4 bytes
|s
|-
|0xC
|Compressed data
|n bytes
|*
|-
|0xC+n
|Skipped data
|s bytes
|*
|-
|0xC+n+s
|Uncompressed data
|(0x10000 - l) bytes
|*
|}

== Structure ==
<syntaxhighlight lang="cpp">
struct chunk
{
const unsigned short magic = 0x1234;
unsigned short type;
union
{
struct // normal chunks
{
unsigned long CID;
unsigned long entrycount;
unsigned long checksum;
union
{
unsigned long entryoffset[entrycount];
entry *entryptr[entrycount];
};
entry entries[entrycount];
};
struct // texture chunks
{
unsigned long EID;
unsigned long entrytype = 5;
unsigned long checksum;
unsigned char data[0xFFF0];
};
};
};

struct chunk_compressed
{
const unsigned short magic = 0x1235;
const unsigned short unused = 0;
unsigned long length;
unsigned long skip;
unsigned char compressed[];
unsigned char skipped[skip];
unsigned char uncompressed[0x10000-length];
};
</syntaxhighlight>
== Types ==
{| class="article-table"
!Type
!Name
|-
|0
|Normal Chunk
|-
|1
|Texture Chunk
|-
|2
|Prototype Sound Chunk
|-
|3
|Sound Chunk
|-
|4
|Wavebank Chunk
|-
|5
|Speech Chunk
|}

=== Non-texture chunks ===
Non-texture chunks are containers for 'entries'-the intermediate level data containers in NSF files.

=== Texture chunks ===
Texture chunks contain palette and texture data used by game models.

== Chunk IDs/CIDs ==
Each chunk has a unique ID. A chunk ID has been assigned to each chunk according to its index in the NSF file. The formula for a chunk ID, or CID, is: '(index << 1) - 1', where chunk indices start at 1. This is equivalent to '(index << 1) | 1' when chunks are zero-indexed. Thus, a chunk's index is contained in the leftmost 31 bits of its CID. The rightmost bit or LSB in a CID is an indicator bit or tag, and is always 1. A CID is typically stored in a tagged union with its replacement entry pointer as the key in an entry hash table slot. Its replacement pointer locates an entry contained in the chunk with that CID.

Texture chunks do not have a CID field with precomputed value. The texture paging routines manually compute CIDs for texture chunks.
[[Category:Structure]]

== Checksums ==
Each chunk includes a 32-bit checksum which can be used to verify the integrity of the chunk data. At least some PAL versions of the games enforce these checksums.

The checksum is computed as follows:

# Start with the value <code>0x12345678</code>.
# For each byte of the 64K chunk:
#* Add that byte to the current value. For the bytes from the checksum field itself (bytes 12 through 15), consider their value to be zero.
#* Circularly left-shift the current value by three bits.
# The final value is the correct checksum.

This procedure is also described by this C function:

<syntaxhighlight lang="cpp">
uint32_t nsfChecksum(const unsigned char *data)
{
uint32_t checksum = 0x12345678;
for (int i = 0;i < 65536;i++) {
if (i < 12 || i >= 16)
checksum += data[i];
checksum = checksum << 3 | checksum >> 29;
}
return checksum;
}
</syntaxhighlight>

Camera Properties Crash 2/3

2019-04-27T17:44:32Z

Chekwob: 21 revisions imported: Initial import from Wikia

== First camera item ==

=== Property 0x29: cameramode ===
00000001 000000MM
* MM = mode
MM = 01; 3d views (normal route/game over screen/titles)

MM = 02; limited input? (platform routes/cutscenes)

MM = 03; sideviews
MM = 04; all round view (warp rooms)

MM = 08; limited input? (transitional space/no man's land )

=== Property 0x4B: vectors/path ===
CCCCCCCC + CCCCCCCC x [XXXX ZZZZ YYYY]
* CCCCCCCC = count of path points
* XXXX = X-coordinate
* ZZZZ = Z-coordinate
* YYYY = Y-coordinate

=== Property 0xC9: ? ===
T.b.d. Might be related to bonus or transportation platforms

=== Property 0x103: SLST ===
Contains the EID of the accompanying SLST entry

=== Property 0x109: path links ===

This property contains information about which (neighbouring) paths and zones are linked with the current path. It consists of 4-byte words, with the 'path beginning/ending' as the main building block.

The property can have different lengths and formats depending on the type of situation. A path can begin where another one ends/end where another begins, be the very end/beginning of the level or converge from/split up in multiple paths.

A path beginning/ending contains the following data:

MMZZPP**
* MM = begin/end flag, 01 is for beginnings, 02 for endings
* ZZ = (neighbouring) zone index where this path begins if (MM=01) / ends if (MM=02)
* PP = (neighbouring) zone's path index where this path begins if (MM=01) / ends if (MM=02)
* <nowiki>**</nowiki> = unknown; (neighbouring) zone's path's point index where this path begins if (MM=01) / ends if (MM=02)
The indices refer to the zones in the order as they come in the zone's header. The first zone is always a reference to the itself (index 0x00), i.e. the zone where the header is in.

'''Type 1 and 2: (first word == 1)'''

'''Type 1:''' path with single end and beginning '''(MM second word == 00)'''

00000001 0000CCCC 01ZZPP** 02ZZPP**
* CCCC = count of path points - 1 (end is at)
'''Type 2:''' path with single beginning '''(MM second word == 01)'''

00000001 01ZZPP**

'''Type 3 and 4: (first word !== 1)'''

'''Type 3:''' path with single end '''(MM second word == 02)'''

CCCC0001 02ZZPP**
* CCCC = count of path points - 1 (end is at)
'''Type 4:''' path with multiple endings/beginnings '''(MM second word !== 02)'''

EEEEBBBB CCCC0000 + BBBB x [01ZZPP**] + EEEE x [02ZZPP**]
* EEEE = count of endings
* BBBB = count of beginnings
* CCCC = count of path points - 1 (ends are at)

=== Property 0x130: camera's field of view ===
00000001 FFFFFFFF
* FFFFFFFF = field of view; the default value is 0x120

=== Property 0x162: ? ===
T.b.d. Might be an ID, value seems to be increase throughout the level

=== Property 0x16D: camera path related ===
T.b.d.

=== Property 0x173: camera path number in zone ===
00000001 NNNNNNNN
* NNNNNNNN = camera path number in the zone, the first one being 0
[[Category:Crash 2/3]]

=== Property 0x174: camera path item number ===
00000001 NNNNNNNN
* NNNNNNNN = camera path item number in the zone; is either 0, 1, 2

=== Property 0x176: camera path number of links ===
00000001 NNNNNNNN EEEEBBBB
* CCCCCCCC = count of path points - 1
* EEEE = number of linked paths at end
* BBBB = number of linked paths at beginning
=== Property 0x1AA: camera path related ===
T.b.d.

== Second camera item ==

=== Property 0x1FA: camera path backgrounds ===
This property contains the ABGR channels (Alpha, Blue, Green, Red respectively) to form the background color in the camera path. Camera paths can have two The base format is:

00000003 FFFF****
* FFFF = flag, if set to 0, there is only one (set of) background color(s)
'''Type 1: '''single color set '''(flag == 0) and (X < 4)'''

00000003 0000000X AABBGGRR(top) AABBGGRR(bottom)
* RR = value of red channel
* GG = value of green channel
* BB = value of blue channel
* AA = value of alpha channel
* X = background division, if set to 1, only the top color is used to fill the entire background, if set to 2, both the colors are used with the background split in a top and bottom color
'''Type 2: '''two color sets '''(flag == 0) and (X >= 4)'''

00000003 0000SSSS 0000000X AABBGGRR(top 1)AABBGGRR(bottom 1) 0000000X AABBGGRR(top 2) AABBGGRR(bottom 2)
* SSSS = index of pathpoint from where 2nd color set starts to be applied

'''Type 3: '''three color sets '''(flag !== 0)'''

00000003 EEEESSSS 0000000X AABBGGRR(top 1) AABBGGRR(bottom 1) 0000000X AABBGGRR(top 2) 0000000X AABBGGRR(bottom 2) 0000000X AABBGGRR(top 3) AABBGGRR(bottom 3)
* EEEE = index of pathpoint from where 3rd color set starts to be applied
* SSSS = index of pathpoint from where 2nd color set starts to be applied

CD-ROM Directory Structure

2019-04-27T17:44:31Z

Chekwob: 9 revisions imported: Initial import from Wikia

== Root directory ==
A Crash Bandicoot game CD will have a root directory with contents similar to the following:
* /BANJ - [Crash 2 and 3 NTSC-J only] Almost nothing is known for sure.
** 1. - ???
** 2. - ???
** B0.DAT to B25.DAT - ???
** BAN320.IKI - [Crash 2 and 3] ???
** BAN320I.EXE - [Crash 2 only] Code for BAN320.IKI?
** GOODIES.EXE - Blank space. Reserved?
** MOVIE.EXE - Blank space. Reserved?
* /BANJ_M - [Crash 3 NTSC-J only] Contains movie sequences from the Goodies menu in .IKI format.
* /BANJ_P - [Crash 3 NTSC-J only] PocketStation stuff?
* /DRAGON - [Crash 3 only] contains Spyro the Dragon demo files
* /S0 - contains [[NSD]]/NSF files in 00-0F range
* /S1 - contains [[NSD]]/NSF files in 10-1F range. Does not contain 1F in Crash 3.
* /S2 - contains [[NSD]]/NSF files in 20-2F range. Contains 1F in Crash 3.
* /S3 - contains [[NSD]]/NSF files in 30-3F range
* ZBSPTREE.WAD - [Crash 1 NTSC-U and PAL only] Binary space partitioning tree data? Dummy file to take space? Can be deleted freely.
* ABSPTREE.WAD - [Crash 1 NTSC-J only] Same as ZBSPTREE.WAD?
* ZTAIL.WAD - [Crash 1 NTSC-J only] Unknown. Not same as *BSPTREE.WAD.
* SYSTEM.CNF - [[CD-ROM Directory Structure#Boot Information|Disc boot information]]
* SCUS_***.** - [NTSC only] Crash Bandicoot [[CD-ROM Directory Structure#Binary executable|binary executable]]
* SCES_***.** - [PAL only] Crash Bandicoot [[CD-ROM Directory Structure#Binary executable|binary executable]]
* SCPS_***.** - [NTSC-J only] Crash Bandicoot [[CD-ROM Directory Structure#Binary executable|binary executable]]
* KDAT.DAT - [Crash 1 and 3 PAL and NTSC-J and Crash 2 NTSC-J only] Unknown. Has no purpose? Located in S3 in Crash 1 and 2, but in S0 in Crash 3.
* S0/WARPSC*S.BIN - [Crash 3 only] Another executable? 


== Binary executable ==
All executable code for the game is located in its binary executable. Depending on game episode and region, this may be one of the following:
* SCUS_949.00 - Crash Bandicoot (NTSC)
* SCES_003.44 - Crash Bandicoot (PAL)
* SCPS_100.31 - クラッシュ・バンディクー
* PSX.EXE - Crash Bandicoot (BETA 96/03/08)
* SCUS_941.54 - Crash Bandicoot 2: Cortex Strikes Back (NTSC)
* SCES_009.67 - Crash Bandicoot 2: Cortex Strikes Back (PAL)
* SCPS_100.47 - クラッシュバンディクー　2:　コルテックスのぎゃくしゅう！
* SCUS_942.44 - Crash Bandicoot: Warped (NTSC)
* SCES_014.20 - Crash Bandicoot 3: Warped (PAL)
* SCPS_100.73 - クラッシュ・バンディクー3 ブッとび!世界一周

== Boot information ==
After powering on, the system searches the disc for the SYSTEM.CNF file. This file contains a list of directives that control the boot process. This includes the path of an initial binary executable (i.e. one of the binaries listed above) that will be loaded into memory for subsequent execution.

== Game content ==
In the S0-S3 directories are .[[NSD]]/.NSF file pairs with the name S00000**.[[NSD]]/.NSF. Each pair corresponds to a specific level in the game, and these files contain the game data for that level.

An NSF file comprises most of the actual data for its associated level, which includes graphic models, music and sound data, [[GOOL Executable|executable object code]], collision octrees, and level layout.

An [[NSD|NSD file]] is essentially an index for its paired NSF file, but also includes some additional information.