Crash Bandicoot Hacking Wiki - User contributions [en]

NSD

2026-02-08T09:00:53Z

Mddass:

NSD 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 (in sectors)
|4 bytes
|*
|-
|0x41C
|Compressed Chunk Count
|4 bytes
|*
|-
|0x420
|Compressed Chunk Info (size 6 bits in sectors, then offset in sectors)
|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
|Entity count
|4 bytes
|*
|-
|0x520 + (8 x s) + 0x10
|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

User:Mddass/List of GOOL Executables

2024-05-26T15:38:53Z

Mddass: /* Crash 3 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General purpose ASCII text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

== Crash 2 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="12"|0
|<code>WillC</code>
|rowspan="12"|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>Wil2C</code>
|
|rowspan="11"|<code>WillC</code>
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>WiliC</code>
|
|<code>7</code> <code>i</code> <code>q</code>
|-

|<code>Wil9C</code>
|
|<code>9</code>
|-

|<code>WilaC</code>
|
|<code>a</code> <code>d</code> <code>u</code> <code>z</code>
|-

|<code>WildC</code>
|
|<code>d</code> <code>z</code>
|-

|<code>WileC</code>
|
|<code>e</code> <code>h</code> <code>j</code> <code>r</code> <code>t</code> <code>w</code> <code>y</code> <code>z</code> <code>B</code>
|-

|<code>WilnC</code>
|
|<code>l</code> <code>A</code>
|-

|<code>WiloC</code>
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

|<code>WiltC</code>
|
|<code>n</code> <code>t</code> <code>y</code> <code>B</code>
|-

|<code>WilkC</code>
|
|<code>p</code> <code>w</code> <code>x</code>
|-

|<code>WilsC</code>
|
|<code>s</code>
|-

!1
|<code>WarpC</code>
|5
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!2
|<code>TurtC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!6
|<code>BirdC</code>
|3
|
|
|<code>u</code> <code>v</code>
|-

!7
|<code>FiFaC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!8
|<code>SwarC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!10
|<code>MonkC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!11
|<code>GoriC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!12
|<code>SeweC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!13
|<code>ScrbC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>h</code> <code>j</code> <code>l</code> <code>m</code> <code>p</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>C</code>
|-

!15
|<code>JunOC</code>
|5
|
|
|<code>c</code> <code>o</code> <code>p</code> <code>s</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>D</code> <code>F</code>
|-

!16
|<code>WeldC</code>
|3
|
|
|<code>a</code> <code>d</code>
|-

!17
|<code>CardC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!18
|<code>BeeOC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!19
|<code>RRooC</code>
|3
|
|
|<code>6</code>
|-

!20
|<code>ArmaC</code>
|3
|
|
|<code>n</code> <code>s</code> <code>u</code> <code>v</code> <code>A</code>
|-

!21
|<code>MecWC</code>
|3
|
|
|<code>d</code> <code>z</code>
|-

!22
|<code>CortC</code>
|3
|
|
|<code>7</code>
|-

!24
|<code>SealC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code> <code>t</code> <code>y</code>
|-

!25
|<code>PengC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!26
|<code>RPltC</code>
|6
|
|
|<code>f</code> <code>m</code>
|-

!27
|<code>PorcC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!28
|<code>RatOC</code>
|3
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>m</code> <code>z</code> <code>D</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!30
|<code>OstrC</code>
|3
|
|
|<code>u</code>
|-

!31
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code>
|-

!32
|<code>SmasC</code>
|5
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!33
|<code>ABanC</code>
|3
|
|
|<code>n</code> <code>A</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>3</code> <code>6</code> <code>8</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>SpaOC</code>
|5
|
|
|<code>i</code> <code>q</code>
|-

!36
|<code>CHeOC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!37
|<code>LenFC</code>
|2
|
|
|<code>2</code> <code>c</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!38
|<code>PlanC</code>
|3
|
|
|<code>l</code> <code>p</code> <code>w</code> <code>x</code> <code>A</code>
|-

!39
|<code>AlpOC</code>
|3
|
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

!41
|<code>BoudC</code>
|5
|
|
|<code>n</code> <code>o</code> <code>r</code>
|-

!42
|<code>SLabC</code>
|3
|
|
|<code>i</code> <code>q</code>
|-

!43
|<code>TazOC</code>
|6
|
|
|<code>3</code>
|-

!44
|<code>Taz3C</code>
|3
|
|
|<code>3</code>
|-

!45
|<code>LJckC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!46
|<code>DraFC</code>
|3
|
|
|<code>c</code> <code>D</code>
|-

!47
|<code>RivOC</code>
|5
|
|
|<code>p</code> <code>w</code> <code>x</code>
|-

!48
|<code>BerOC</code>
|5
|
|
|<code>2</code> <code>n</code> <code>t</code> <code>y</code> <code>B</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!50
|<code>IntOC</code>
|5
|
|
|<code>s</code>
|-

!51
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!53
|<code>FredC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!54
|<code>KimoC</code>
|3
|
|
|<code>8</code>
|-

!55
|<code>DynOC</code>
|5
|
|
|<code>g</code> <code>C</code>
|-

!56
|<code>APusC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!57
|<code>FflOC</code>
|5
|
|
|<code>c</code> <code>D</code>
|-

!58
|<code>NGinC</code>
|3
|
|
|<code>9</code>
|-

!60
|<code>LighC</code>
|9
|
|
|<code>f</code> <code>u</code>
|-

!61
|<code>WinOC</code>
|5
|
|
|<code>E</code> <code>F</code>
|-

!62
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-
|}
</div>

== Crash 3 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="15"|0
|<code>WillC</code>
|rowspan="15"|1
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

|<code>Wil2C</code>
|
|rowspan="14"|<code>WillC</code>
|<code>2</code>
|-

|<code>Wil3C</code>
|
|<code>3</code> <code>4</code> <code>6</code> <code>7</code>
|-

|<code>Wil5C</code>
|
|<code>5</code>
|-

|<code>WilaC</code>
|
|<code>a</code> <code>h</code>
|-

|<code>WiltC</code>
|
|<code>a</code> <code>h</code>
|-

|<code>WilfC</code>
|
|<code>b</code> <code>f</code> <code>t</code>
|-

|<code>WilcC</code>
|
|<code>c</code> <code>g</code> <code>C</code>
|-

|<code>WildC</code>
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

|<code>WileC</code>
|
|<code>e</code> <code>s</code>
|-

|<code>WiliC</code>
|
|<code>i</code> <code>o</code> <code>u</code> <code>A</code>
|-

|<code>WiljC</code>
|
|<code>j</code> <code>n</code> <code>v</code>
|-

|<code>WilkC</code>
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

|<code>WilmC</code>
|
|<code>m</code> <code>q</code> <code>y</code>
|-

|<code>WilrC</code>
|
|<code>r</code> <code>z</code>
|-

!2
|<code>AtoOC</code>
|3
|
|
|<code>e</code> <code>s</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>G</code> <code>W</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!6
|<code>Drg0C</code>
|3
|
|
|<code>a</code> <code>h</code>
|-

!7
|<code>AhoOC</code>
|3
|
|
|<code>a</code> <code>h</code>
|-

!8
|<code>ChoOC</code>
|5
|
|
|<code>a</code> <code>h</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>G</code> <code>W</code> <code>X</code> <code>Y</code>
|-

!10
|<code>BerOC</code>
|5
|
|
|<code>a</code> <code>h</code>
|-

!11
|<code>MeoOC</code>
|3
|
|
|<code>b</code> <code>f</code> <code>t</code>
|-

!12
|<code>CknOC</code>
|3
|
|
|<code>b</code> <code>f</code>
|-

!13
|<code>GrasC</code>
|3
|
|
|<code>c</code> <code>g</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>i</code> <code>m</code> <code>o</code> <code>q</code> <code>r</code> <code>u</code> <code>y</code> <code>A</code>
|-

!15
|<code>OcoOC</code>
|3
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!16
|<code>DioOC</code>
|3
|
|
|<code>c</code> <code>g</code> <code>C</code>
|-

!17
|<code>TriOC</code>
|3
|
|
|<code>c</code> <code>g</code>
|-

!18
|<code>DinoC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!19
|<code>DpAOC</code>
|3
|
|
|<code>c</code> <code>g</code>
|-

!20
|<code>SwiOC</code>
|5
|
|
|<code>e</code> <code>s</code>
|-

!21
|<code>FisCC</code>
|3
|
|
|<code>g</code>
|-

!22
|<code>FshOC</code>
|3
|
|
|<code>e</code>
|-

!23
|<code>MinOC</code>
|3
|
|
|<code>e</code> <code>s</code>
|-

!24
|<code>NgiOC</code>
|5
|
|
|<code>5</code>
|-

!25
|<code>WAsOC</code>
|3
|
|
|<code>f</code> <code>t</code>
|-

!26
|<code>WObOC</code>
|3
|
|
|<code>2</code> <code>E</code>
|-

!27
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!28
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>a</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>G</code>
|-

!rowspan="2"|30
|<code>WEfOC</code>
|rowspan="2"|5
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>F</code>
|-

|<code>WEf2C</code>
|
|<code>WEfOC</code>
|<code>2</code>
|-

!31
|<code>RunOC</code>
|3
|
|
|<code>h</code>
|-

!32
|<code>BarOC</code>
|5
|
|
|<code>5</code> <code>j</code> <code>n</code> <code>v</code>
|-

!33
|<code>CardC</code>
|5
|
|
|<code>2</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>2</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>VLAOC</code>
|3
|
|
|<code>j</code> <code>n</code>
|-

!36
|<code>ZeppC</code>
|3
|
|
|<code>j</code> <code>n</code> <code>v</code>
|-

!37
|<code>EgoOC</code>
|3
|
|
|<code>i</code> <code>u</code> <code>A</code>
|-

!38
|<code>SwAOC</code>
|3
|
|
|<code>i</code> <code>u</code>
|-

!39
|<code>MnVOC</code>
|3
|
|
|<code>i</code> <code>u</code>
|-

!40
|<code>DSmOC</code>
|3
|
|
|<code>i</code> <code>u</code> <code>A</code>
|-

!41
|<code>FlAOC</code>
|3
|
|
|<code>i</code> <code>u</code>
|-

!42
|<code>OcMiC</code>
|3
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!43
|<code>BikOC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!44
|<code>GullC</code>
|3
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!45
|<code>HaDOC</code>
|3
|
|
|<code>i</code>
|-

!46
|<code>StrkC</code>
|3
|
|
|<code>d</code> <code>p</code>
|-

!47
|<code>SharC</code>
|3
|
|
|<code>d</code> <code>D</code>
|-

!48
|<code>BLnFC</code>
|2
|
|
|<code>j</code> <code>n</code> <code>v</code>
|-

!49
|<code>CrAsC</code>
|3
|
|
|<code>d</code>
|-

!50
|<code>HRdOC</code>
|3
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!51
|<code>DonOC</code>
|5
|
|
|<code>Y</code>
|-

!52
|<code>TigOC</code>
|3
|
|
|<code>6</code>
|-

!53
|<code>MBaOC</code>
|5
|
|
|<code>b</code> <code>f</code>
|-

!54
|<code>AraOC</code>
|3
|
|
|<code>m</code> <code>q</code> <code>y</code>
|-

!55
|<code>BOMOC</code>
|3
|
|
|<code>n</code>
|-

!56
|<code>WaveC</code>
|5
|
|
|<code>o</code>
|-

!57
|<code>SarOC</code>
|3
|
|
|<code>u</code> <code>A</code>
|-

!58
|<code>ScpOC</code>
|3
|
|
|<code>m</code> <code>q</code>
|-

!59
|<code>GurOC</code>
|3
|
|
|<code>m</code> <code>q</code>
|-

!60
|<code>KfAOC</code>
|3
|
|
|<code>q</code> <code>y</code>
|-

!61
|<code>ArGOC</code>
|3
|
|
|<code>m</code> <code>y</code>
|-

!62
|<code>CpCOC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!63
|<code>RBrOC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!64
|<code>BiROC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!65
|<code>VAsOC</code>
|3
|
|
|<code>m</code> <code>q</code> <code>y</code>
|-

!66
|<code>EntNC</code>
|2
|
|
|<code>5</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!67
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code>
|-

!68
|<code>NGinC</code>
|3
|
|
|<code>5</code>
|-

!69
|<code>WavOC</code>
|5
|
|
|<code>o</code>
|-

!70
|<code>VorOC</code>
|3
|
|
|<code>s</code>
|-

!71
|<code>ScarC</code>
|3
|
|
|<code>o</code>
|-

!73
|<code>ButOC</code>
|3
|
|
|<code>2</code>
|-

!74
|<code>FatLC</code>
|3
|
|
|<code>q</code> <code>y</code>
|-

!75
|<code>SheiC</code>
|3
|
|
|<code>o</code>
|-

!76
|<code>JGatC</code>
|3
|
|
|<code>o</code> <code>A</code>
|-

!77
|<code>FutOC</code>
|5
|
|
|<code>r</code> <code>z</code>
|-

!78
|<code>WStOC</code>
|2
|
|
|<code>2</code>
|-

!79
|<code>JumpC</code>
|3
|
|
|<code>r</code> <code>z</code>
|-

!81
|<code>GiaOC</code>
|3
|
|
|<code>t</code>
|-

!82
|<code>UfoOC</code>
|3
|
|
|<code>r</code> <code>z</code>
|-

!83
|<code>SpinC</code>
|3
|
|
|<code>r</code> <code>z</code>
|-

!84
|<code>CocoC</code>
|5
|
|
|<code>2</code>
|-

!85
|<code>StVOC</code>
|3
|
|
|<code>c</code> <code>g</code> <code>C</code>
|-

!86
|<code>WpSOC</code>
|5
|
|
|<code>2</code>
|-

!87
|<code>BaROC</code>
|3
|
|
|<code>v</code>
|-

!88
|<code>DingC</code>
|3
|
|
|<code>3</code>
|-

!89
|<code>NTroC</code>
|3
|
|
|<code>4</code>
|-

!90
|<code>NTrOC</code>
|5
|
|
|<code>4</code>
|-

!91
|<code>HUdOC</code>
|3
|
|
|<code>B</code>
|-

!92
|<code>RoboC</code>
|3
|
|
|<code>z</code>
|-

!93
|<code>FflOC</code>
|5
|
|
|<code>A</code>
|-

!94
|<code>NCorC</code>
|3
|
|
|<code>7</code>
|-

!95
|<code>ButFC</code>
|5
|
|
|<code>a</code> <code>b</code> <code>c</code> <code>f</code> <code>g</code> <code>l</code> <code>t</code> <code>w</code> <code>C</code> <code>E</code>
|-

!96
|<code>IntOC</code>
|5
|
|
|<code>E</code>
|-

!97
|<code>HeadC</code>
|5
|
|
|<code>W</code>
|-

!98
|<code>FakeC</code>
|3
|
|
|<code>b</code> <code>p</code>
|-

!99
|<code>WinOC</code>
|5
|
|
|<code>F</code> <code>G</code>
|-

!100
|<code>CredC</code>
|5
|
|
|<code>F</code> <code>G</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2024-05-26T15:27:02Z

Mddass: /* Crash 3 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General purpose ASCII text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

== Crash 2 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="12"|0
|<code>WillC</code>
|rowspan="12"|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>Wil2C</code>
|
|rowspan="11"|<code>WillC</code>
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>WiliC</code>
|
|<code>7</code> <code>i</code> <code>q</code>
|-

|<code>Wil9C</code>
|
|<code>9</code>
|-

|<code>WilaC</code>
|
|<code>a</code> <code>d</code> <code>u</code> <code>z</code>
|-

|<code>WildC</code>
|
|<code>d</code> <code>z</code>
|-

|<code>WileC</code>
|
|<code>e</code> <code>h</code> <code>j</code> <code>r</code> <code>t</code> <code>w</code> <code>y</code> <code>z</code> <code>B</code>
|-

|<code>WilnC</code>
|
|<code>l</code> <code>A</code>
|-

|<code>WiloC</code>
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

|<code>WiltC</code>
|
|<code>n</code> <code>t</code> <code>y</code> <code>B</code>
|-

|<code>WilkC</code>
|
|<code>p</code> <code>w</code> <code>x</code>
|-

|<code>WilsC</code>
|
|<code>s</code>
|-

!1
|<code>WarpC</code>
|5
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!2
|<code>TurtC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!6
|<code>BirdC</code>
|3
|
|
|<code>u</code> <code>v</code>
|-

!7
|<code>FiFaC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!8
|<code>SwarC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!10
|<code>MonkC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!11
|<code>GoriC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!12
|<code>SeweC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!13
|<code>ScrbC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>h</code> <code>j</code> <code>l</code> <code>m</code> <code>p</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>C</code>
|-

!15
|<code>JunOC</code>
|5
|
|
|<code>c</code> <code>o</code> <code>p</code> <code>s</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>D</code> <code>F</code>
|-

!16
|<code>WeldC</code>
|3
|
|
|<code>a</code> <code>d</code>
|-

!17
|<code>CardC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!18
|<code>BeeOC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!19
|<code>RRooC</code>
|3
|
|
|<code>6</code>
|-

!20
|<code>ArmaC</code>
|3
|
|
|<code>n</code> <code>s</code> <code>u</code> <code>v</code> <code>A</code>
|-

!21
|<code>MecWC</code>
|3
|
|
|<code>d</code> <code>z</code>
|-

!22
|<code>CortC</code>
|3
|
|
|<code>7</code>
|-

!24
|<code>SealC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code> <code>t</code> <code>y</code>
|-

!25
|<code>PengC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!26
|<code>RPltC</code>
|6
|
|
|<code>f</code> <code>m</code>
|-

!27
|<code>PorcC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!28
|<code>RatOC</code>
|3
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>m</code> <code>z</code> <code>D</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!30
|<code>OstrC</code>
|3
|
|
|<code>u</code>
|-

!31
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code>
|-

!32
|<code>SmasC</code>
|5
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!33
|<code>ABanC</code>
|3
|
|
|<code>n</code> <code>A</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>3</code> <code>6</code> <code>8</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>SpaOC</code>
|5
|
|
|<code>i</code> <code>q</code>
|-

!36
|<code>CHeOC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!37
|<code>LenFC</code>
|2
|
|
|<code>2</code> <code>c</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!38
|<code>PlanC</code>
|3
|
|
|<code>l</code> <code>p</code> <code>w</code> <code>x</code> <code>A</code>
|-

!39
|<code>AlpOC</code>
|3
|
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

!41
|<code>BoudC</code>
|5
|
|
|<code>n</code> <code>o</code> <code>r</code>
|-

!42
|<code>SLabC</code>
|3
|
|
|<code>i</code> <code>q</code>
|-

!43
|<code>TazOC</code>
|6
|
|
|<code>3</code>
|-

!44
|<code>Taz3C</code>
|3
|
|
|<code>3</code>
|-

!45
|<code>LJckC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!46
|<code>DraFC</code>
|3
|
|
|<code>c</code> <code>D</code>
|-

!47
|<code>RivOC</code>
|5
|
|
|<code>p</code> <code>w</code> <code>x</code>
|-

!48
|<code>BerOC</code>
|5
|
|
|<code>2</code> <code>n</code> <code>t</code> <code>y</code> <code>B</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!50
|<code>IntOC</code>
|5
|
|
|<code>s</code>
|-

!51
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!53
|<code>FredC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!54
|<code>KimoC</code>
|3
|
|
|<code>8</code>
|-

!55
|<code>DynOC</code>
|5
|
|
|<code>g</code> <code>C</code>
|-

!56
|<code>APusC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!57
|<code>FflOC</code>
|5
|
|
|<code>c</code> <code>D</code>
|-

!58
|<code>NGinC</code>
|3
|
|
|<code>9</code>
|-

!60
|<code>LighC</code>
|9
|
|
|<code>f</code> <code>u</code>
|-

!61
|<code>WinOC</code>
|5
|
|
|<code>E</code> <code>F</code>
|-

!62
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-
|}
</div>

== Crash 3 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-
!0
|<code>Wil2C</code>
|1
|
|
|<code>2</code>
|-

!0
|<code>WillC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!0
|<code>Wil3C</code>
|1
|
|
|<code>3</code> <code>4</code> <code>6</code> <code>7</code>
|-

!0
|<code>Wil5C</code>
|1
|
|
|<code>5</code>
|-

!0
|<code>WilaC</code>
|1
|
|
|<code>a</code> <code>h</code>
|-

!0
|<code>WiltC</code>
|1
|
|
|<code>a</code> <code>h</code>
|-

!0
|<code>WilfC</code>
|1
|
|
|<code>b</code> <code>f</code> <code>t</code>
|-

!0
|<code>WilcC</code>
|1
|
|
|<code>c</code> <code>g</code> <code>C</code>
|-

!0
|<code>WildC</code>
|1
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!0
|<code>WileC</code>
|1
|
|
|<code>e</code> <code>s</code>
|-

!0
|<code>WiliC</code>
|1
|
|
|<code>i</code> <code>o</code> <code>u</code> <code>A</code>
|-

!0
|<code>WiljC</code>
|1
|
|
|<code>j</code> <code>n</code> <code>v</code>
|-

!0
|<code>WilkC</code>
|1
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!0
|<code>WilmC</code>
|1
|
|
|<code>m</code> <code>q</code> <code>y</code>
|-

!0
|<code>WilrC</code>
|1
|
|
|<code>r</code> <code>z</code>
|-

!2
|<code>AtoOC</code>
|3
|
|
|<code>e</code> <code>s</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>G</code> <code>W</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!6
|<code>Drg0C</code>
|3
|
|
|<code>a</code> <code>h</code>
|-

!7
|<code>AhoOC</code>
|3
|
|
|<code>a</code> <code>h</code>
|-

!8
|<code>ChoOC</code>
|5
|
|
|<code>a</code> <code>h</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>G</code> <code>W</code> <code>X</code> <code>Y</code>
|-

!10
|<code>BerOC</code>
|5
|
|
|<code>a</code> <code>h</code>
|-

!11
|<code>MeoOC</code>
|3
|
|
|<code>b</code> <code>f</code> <code>t</code>
|-

!12
|<code>CknOC</code>
|3
|
|
|<code>b</code> <code>f</code>
|-

!13
|<code>GrasC</code>
|3
|
|
|<code>c</code> <code>g</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>i</code> <code>m</code> <code>o</code> <code>q</code> <code>r</code> <code>u</code> <code>y</code> <code>A</code>
|-

!15
|<code>OcoOC</code>
|3
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!16
|<code>DioOC</code>
|3
|
|
|<code>c</code> <code>g</code> <code>C</code>
|-

!17
|<code>TriOC</code>
|3
|
|
|<code>c</code> <code>g</code>
|-

!18
|<code>DinoC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!19
|<code>DpAOC</code>
|3
|
|
|<code>c</code> <code>g</code>
|-

!20
|<code>SwiOC</code>
|5
|
|
|<code>e</code> <code>s</code>
|-

!21
|<code>FisCC</code>
|3
|
|
|<code>g</code>
|-

!22
|<code>FshOC</code>
|3
|
|
|<code>e</code>
|-

!23
|<code>MinOC</code>
|3
|
|
|<code>e</code> <code>s</code>
|-

!24
|<code>NgiOC</code>
|5
|
|
|<code>5</code>
|-

!25
|<code>WAsOC</code>
|3
|
|
|<code>f</code> <code>t</code>
|-

!26
|<code>WObOC</code>
|3
|
|
|<code>2</code> <code>E</code>
|-

!27
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!28
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>a</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>G</code>
|-

!30
|<code>WEf2C</code>
|5
|
|
|<code>2</code>
|-

!30
|<code>WEfOC</code>
|5
|
|
|<code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>F</code>
|-

!31
|<code>RunOC</code>
|3
|
|
|<code>h</code>
|-

!32
|<code>BarOC</code>
|5
|
|
|<code>5</code> <code>j</code> <code>n</code> <code>v</code>
|-

!33
|<code>CardC</code>
|5
|
|
|<code>2</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>2</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>VLAOC</code>
|3
|
|
|<code>j</code> <code>n</code>
|-

!36
|<code>ZeppC</code>
|3
|
|
|<code>j</code> <code>n</code> <code>v</code>
|-

!37
|<code>EgoOC</code>
|3
|
|
|<code>i</code> <code>u</code> <code>A</code>
|-

!38
|<code>SwAOC</code>
|3
|
|
|<code>i</code> <code>u</code>
|-

!39
|<code>MnVOC</code>
|3
|
|
|<code>i</code> <code>u</code>
|-

!40
|<code>DSmOC</code>
|3
|
|
|<code>i</code> <code>u</code> <code>A</code>
|-

!41
|<code>FlAOC</code>
|3
|
|
|<code>i</code> <code>u</code>
|-

!42
|<code>OcMiC</code>
|3
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!43
|<code>BikOC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!44
|<code>GullC</code>
|3
|
|
|<code>d</code> <code>p</code> <code>x</code> <code>D</code>
|-

!45
|<code>HaDOC</code>
|3
|
|
|<code>i</code>
|-

!46
|<code>StrkC</code>
|3
|
|
|<code>d</code> <code>p</code>
|-

!47
|<code>SharC</code>
|3
|
|
|<code>d</code> <code>D</code>
|-

!48
|<code>BLnFC</code>
|2
|
|
|<code>j</code> <code>n</code> <code>v</code>
|-

!49
|<code>CrAsC</code>
|3
|
|
|<code>d</code>
|-

!50
|<code>HRdOC</code>
|3
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!51
|<code>DonOC</code>
|5
|
|
|<code>Y</code>
|-

!52
|<code>TigOC</code>
|3
|
|
|<code>6</code>
|-

!53
|<code>MBaOC</code>
|5
|
|
|<code>b</code> <code>f</code>
|-

!54
|<code>AraOC</code>
|3
|
|
|<code>m</code> <code>q</code> <code>y</code>
|-

!55
|<code>BOMOC</code>
|3
|
|
|<code>n</code>
|-

!56
|<code>WaveC</code>
|5
|
|
|<code>o</code>
|-

!57
|<code>SarOC</code>
|3
|
|
|<code>u</code> <code>A</code>
|-

!58
|<code>ScpOC</code>
|3
|
|
|<code>m</code> <code>q</code>
|-

!59
|<code>GurOC</code>
|3
|
|
|<code>m</code> <code>q</code>
|-

!60
|<code>KfAOC</code>
|3
|
|
|<code>q</code> <code>y</code>
|-

!61
|<code>ArGOC</code>
|3
|
|
|<code>m</code> <code>y</code>
|-

!62
|<code>CpCOC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!63
|<code>RBrOC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!64
|<code>BiROC</code>
|5
|
|
|<code>k</code> <code>l</code> <code>w</code> <code>B</code>
|-

!65
|<code>VAsOC</code>
|3
|
|
|<code>m</code> <code>q</code> <code>y</code>
|-

!66
|<code>EntNC</code>
|2
|
|
|<code>5</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!67
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code>
|-

!68
|<code>NGinC</code>
|3
|
|
|<code>5</code>
|-

!69
|<code>WavOC</code>
|5
|
|
|<code>o</code>
|-

!70
|<code>VorOC</code>
|3
|
|
|<code>s</code>
|-

!71
|<code>ScarC</code>
|3
|
|
|<code>o</code>
|-

!73
|<code>ButOC</code>
|3
|
|
|<code>2</code>
|-

!74
|<code>FatLC</code>
|3
|
|
|<code>q</code> <code>y</code>
|-

!75
|<code>SheiC</code>
|3
|
|
|<code>o</code>
|-

!76
|<code>JGatC</code>
|3
|
|
|<code>o</code> <code>A</code>
|-

!77
|<code>FutOC</code>
|5
|
|
|<code>r</code> <code>z</code>
|-

!78
|<code>WStOC</code>
|2
|
|
|<code>2</code>
|-

!79
|<code>JumpC</code>
|3
|
|
|<code>r</code> <code>z</code>
|-

!81
|<code>GiaOC</code>
|3
|
|
|<code>t</code>
|-

!82
|<code>UfoOC</code>
|3
|
|
|<code>r</code> <code>z</code>
|-

!83
|<code>SpinC</code>
|3
|
|
|<code>r</code> <code>z</code>
|-

!84
|<code>CocoC</code>
|5
|
|
|<code>2</code>
|-

!85
|<code>StVOC</code>
|3
|
|
|<code>c</code> <code>g</code> <code>C</code>
|-

!86
|<code>WpSOC</code>
|5
|
|
|<code>2</code>
|-

!87
|<code>BaROC</code>
|3
|
|
|<code>v</code>
|-

!88
|<code>DingC</code>
|3
|
|
|<code>3</code>
|-

!89
|<code>NTroC</code>
|3
|
|
|<code>4</code>
|-

!90
|<code>NTrOC</code>
|5
|
|
|<code>4</code>
|-

!91
|<code>HUdOC</code>
|3
|
|
|<code>B</code>
|-

!92
|<code>RoboC</code>
|3
|
|
|<code>z</code>
|-

!93
|<code>FflOC</code>
|5
|
|
|<code>A</code>
|-

!94
|<code>NCorC</code>
|3
|
|
|<code>7</code>
|-

!95
|<code>ButFC</code>
|5
|
|
|<code>a</code> <code>b</code> <code>c</code> <code>f</code> <code>g</code> <code>l</code> <code>t</code> <code>w</code> <code>C</code> <code>E</code>
|-

!96
|<code>IntOC</code>
|5
|
|
|<code>E</code>
|-

!97
|<code>HeadC</code>
|5
|
|
|<code>W</code>
|-

!98
|<code>FakeC</code>
|3
|
|
|<code>b</code> <code>p</code>
|-

!99
|<code>WinOC</code>
|5
|
|
|<code>F</code> <code>G</code>
|-

!100
|<code>CredC</code>
|5
|
|
|<code>F</code> <code>G</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2024-05-26T14:50:41Z

Mddass:

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General purpose ASCII text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

== Crash 2 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="12"|0
|<code>WillC</code>
|rowspan="12"|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>Wil2C</code>
|
|rowspan="11"|<code>WillC</code>
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>WiliC</code>
|
|<code>7</code> <code>i</code> <code>q</code>
|-

|<code>Wil9C</code>
|
|<code>9</code>
|-

|<code>WilaC</code>
|
|<code>a</code> <code>d</code> <code>u</code> <code>z</code>
|-

|<code>WildC</code>
|
|<code>d</code> <code>z</code>
|-

|<code>WileC</code>
|
|<code>e</code> <code>h</code> <code>j</code> <code>r</code> <code>t</code> <code>w</code> <code>y</code> <code>z</code> <code>B</code>
|-

|<code>WilnC</code>
|
|<code>l</code> <code>A</code>
|-

|<code>WiloC</code>
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

|<code>WiltC</code>
|
|<code>n</code> <code>t</code> <code>y</code> <code>B</code>
|-

|<code>WilkC</code>
|
|<code>p</code> <code>w</code> <code>x</code>
|-

|<code>WilsC</code>
|
|<code>s</code>
|-

!1
|<code>WarpC</code>
|5
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!2
|<code>TurtC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!6
|<code>BirdC</code>
|3
|
|
|<code>u</code> <code>v</code>
|-

!7
|<code>FiFaC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!8
|<code>SwarC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!10
|<code>MonkC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!11
|<code>GoriC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!12
|<code>SeweC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!13
|<code>ScrbC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>h</code> <code>j</code> <code>l</code> <code>m</code> <code>p</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>C</code>
|-

!15
|<code>JunOC</code>
|5
|
|
|<code>c</code> <code>o</code> <code>p</code> <code>s</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>D</code> <code>F</code>
|-

!16
|<code>WeldC</code>
|3
|
|
|<code>a</code> <code>d</code>
|-

!17
|<code>CardC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!18
|<code>BeeOC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!19
|<code>RRooC</code>
|3
|
|
|<code>6</code>
|-

!20
|<code>ArmaC</code>
|3
|
|
|<code>n</code> <code>s</code> <code>u</code> <code>v</code> <code>A</code>
|-

!21
|<code>MecWC</code>
|3
|
|
|<code>d</code> <code>z</code>
|-

!22
|<code>CortC</code>
|3
|
|
|<code>7</code>
|-

!24
|<code>SealC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code> <code>t</code> <code>y</code>
|-

!25
|<code>PengC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!26
|<code>RPltC</code>
|6
|
|
|<code>f</code> <code>m</code>
|-

!27
|<code>PorcC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!28
|<code>RatOC</code>
|3
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>m</code> <code>z</code> <code>D</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!30
|<code>OstrC</code>
|3
|
|
|<code>u</code>
|-

!31
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code>
|-

!32
|<code>SmasC</code>
|5
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!33
|<code>ABanC</code>
|3
|
|
|<code>n</code> <code>A</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>3</code> <code>6</code> <code>8</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>SpaOC</code>
|5
|
|
|<code>i</code> <code>q</code>
|-

!36
|<code>CHeOC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!37
|<code>LenFC</code>
|2
|
|
|<code>2</code> <code>c</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!38
|<code>PlanC</code>
|3
|
|
|<code>l</code> <code>p</code> <code>w</code> <code>x</code> <code>A</code>
|-

!39
|<code>AlpOC</code>
|3
|
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

!41
|<code>BoudC</code>
|5
|
|
|<code>n</code> <code>o</code> <code>r</code>
|-

!42
|<code>SLabC</code>
|3
|
|
|<code>i</code> <code>q</code>
|-

!43
|<code>TazOC</code>
|6
|
|
|<code>3</code>
|-

!44
|<code>Taz3C</code>
|3
|
|
|<code>3</code>
|-

!45
|<code>LJckC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!46
|<code>DraFC</code>
|3
|
|
|<code>c</code> <code>D</code>
|-

!47
|<code>RivOC</code>
|5
|
|
|<code>p</code> <code>w</code> <code>x</code>
|-

!48
|<code>BerOC</code>
|5
|
|
|<code>2</code> <code>n</code> <code>t</code> <code>y</code> <code>B</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!50
|<code>IntOC</code>
|5
|
|
|<code>s</code>
|-

!51
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!53
|<code>FredC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!54
|<code>KimoC</code>
|3
|
|
|<code>8</code>
|-

!55
|<code>DynOC</code>
|5
|
|
|<code>g</code> <code>C</code>
|-

!56
|<code>APusC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!57
|<code>FflOC</code>
|5
|
|
|<code>c</code> <code>D</code>
|-

!58
|<code>NGinC</code>
|3
|
|
|<code>9</code>
|-

!60
|<code>LighC</code>
|9
|
|
|<code>f</code> <code>u</code>
|-

!61
|<code>WinOC</code>
|5
|
|
|<code>E</code> <code>F</code>
|-

!62
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-
|}
</div>

== Crash 3 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Class
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General purpose ASCII text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2024-03-13T15:44:39Z

Mddass:

GOOL Interpreter

2024-01-19T15:52:19Z

Mddass: fix SNDB (crash 1) format

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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:11px;">
{| 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
|<br>
|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
|LOOP
|00010011AAAAAAAAAAAABBBBBBBBBBBB
|(A),B
|R = 0x100
|[R,A]
|B = A >= 0 ? B + R : B - R
if (B > A && A > 0) B = -A + R*2
else if (B < A && A < 0) B = -A - R*2
P = A >= 0 ? abs(B) : -abs(B)
|P
|B
|loop around zero

|-
|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
|PUSH
|00010110AAAAAAAAAAAABBBBBBBBBBBB
|[A,[B]]
|
|
|[arg_buf = A]
I = A; J = B;
|[I,[J]]
|
|push value to stack

|-
|23/0x17
|NOTB
|00010111SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|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*grav) >> 10)
|S
|
|calculate speed

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

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

|-
|30/0x1E
|TICK
|00011110DDDDDDDDDDDDPPPPPPPPPPPP
|M,P
|
|
|O = (M + frameCount) % P
|O
|
|get game time

|-
|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
|DEGD
|00100001RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = degdist(L,R)
|
|
|angle between

|-
|34/0x22
|SEEK
|00100010RRRRRRRRRRRRLLLLLLLLLLLL
|L,(R)
|S = 0x100
|[R,S]
|O = seek(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
|00100100000IIIIIILLLCCCCCCCCCCCC
|C
|I,L
|
|obj.link[L].colors[I] = C
|
|
|color vector or matrix write

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

|-
|38/0x26
|PSHP
|00100110AAAAAAAAAAAABBBBBBBBBBBB
|[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
|ANIM
|10000011HHTTTTTTSSSSSSSSSFFFFFFF
|
|F,S,T,H
|
|
|W
|
|play animation at specified frame

|-
|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
|EVHR
|10001001TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|reject event

|-
|137/0x89
|EVHA
|10001000TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|<br>
|
|accept event
|-
|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
|SNDP
|10001100AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|
|
|
|
|play audio file at volume

|-
|141/0x8D
|SNDB
|10001101FFFFTTRRRRRRSSSSSSSSSSSS
|S
|F,T,R
|
|
|
|
|adjust voice parameters
|-
|142/0x8E
|VECB
|10001110CCCTTTBBBAAAVVVVVVVVVVVV
|V
|T,A,B,C
|
|
|
|<br>
|multi-purpose vector calcs

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

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

|-
|145/0x91
|CHLF
|10100000AAAATTTTTTTTSSSSSSCCCCCC
|
|C,T,S,A
|[C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
|O
|
|logical and
|-
|6/0x06
|ORL
|'''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
|O
|<br>
|logical or (same as ORB)
|-
|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
|LOOP
|'''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
|(A),B
|R = 0x100
|[R,A]
|B = A >= 0 ? B + R : B - R
if (B > A && A > 0) B = -A + R*2
else if (B < A && A < 0) B = -A - R*2
P = A >= 0 ? abs(B) : -abs(B)
|P
|B
|loop around zero
|-
|20/0x14
|LEA
|'''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = &S
|
|D
|load effective address
|-
|21/0x15
|SHA
|'''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
|O
|
|bit shift
|-
|22/0x16
|PUSH
|'''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
|A,[B]
|
|
|
I = A; J = B;
|I,[J]
|
|push value(s) to stack
|-
|23/0x17
|NOTB
|'''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
|D = ~S
|
|D
|bitwise not (nor)
|-
|24/0x18
|MOVC
|'''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
|R,E,I
|
|see docs
|O
|
|get code pointer
|-
|25/0x19
|ABS
|'''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = (S < 0) ? -S : S
|
|D
|absolute value
|-
|26/0x1A
|PAD
|'''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
|B,P,S,D,T
|
|O = testctrls(instr,0)
|O
|
|test controller buttons
|-
|27/0x1B
|SPD
|'''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
|V,B
|
|
|S = B + ((V*gvel) >> 10)
|S
|
|calculate speed
|-
|28/0x1C
|MSC
|'''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
|X
|P,S,L
|
|various
|
|
|multi-purpose
|-
|29/0x1D
|PSIN
|'''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
|P,D
|
|
|large calc; see docs
|
|
|driven sine wave
|-
|30/0x1E
|TICK
|'''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = (R + TICKS) % L
|O
|
|get ticks
|-
|31/0x1F
|RGL
|'''00011111'''101111100000IIIIIIIIIIII
|I
|
|
|O = globals[I]
|O
|
|read global variable
|-
|32/0x20
|WGL
|'''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
|I,S
|
|
|globals[I] = *S
|
|
|write global variable
|-
|33/0x21
|ANGD
|'''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
|R,L
|
|
|O = ((R << 20) - (L << 20)) >> 20
|O
|
|angle distance (note: shifts are for sign extension)
|-
|34/0x22
|APCH
|'''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,(R)
|
|
|O = approach(L,R,S)
|O
|
|approach a value
|-
|35/0x23
|CVMR
|'''00100011'''000IIIIIILLL000000000000
|
|I,L
|
|O = obj.link[L].colors[I]
|O
|
|color vector or matrix read
|-
|36/0x24
|CVMW
|'''00100100'''000IIIIIILLLCCCCCCCCCCCC
|C
|I,L
|
|obj.link[L].colors[I] = C
|
|
|color vector or matrix write
|-
|37/0x25
|ROT
|'''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
|(R),L
|
|[R,S]
|O = rotate(L,R,S,0)
|
|
|approach an angle
|-
|38/0x26
|PSHP
|'''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
|A,[B]
|
|
|I = &A; J = &B;
|I,[J]
|
|push pointer(s)
|-
|39/0x27
|ANIS
|'''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
|F
|
|
|D=&obj.global.anim[F>>8]
|
|D
|set animation
|-
|40/0x28
|EFLR
|'''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
|A,B
|
|
|O = GetFieldValue(obj->entity, field: A, row: B)
|O
|
|load entity field row data
|-
|41/0x29
|EFLV
|'''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = GetFieldValue(obj->entity, field: S)
|
|D
|get entity field data
|-
|42/0x2A
|ARRL
|'''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = *(L + R)
o = L[R]
|O
|
|load array value
|-
|43/0x2B
|SIN
|'''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = sin(S)
|
|D
|sine wave (output: -0x1000 to 0x1000)
|-
|44/0x2C
|COS
|'''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = cos(S)
D = sin(S + PI/2)
|
|D
|cosine wave (output: -0x1000 to 0x1000)
|-
|45/0x2D
|ATAN
|'''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
|X,Y
|
|
|o = atan2(X, Y)
|o
|
|arc-tangent2, angle to point (confirmation needed)
|-
|46/0x2E
|?
|'''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
|A
|
|
|
|
|D
|unknown
|-
|47/0x2F
|NOP
|'''00101111'''101111100000101111100000
|
|
|
|
|
|
|no operation
|-
|48/0x30
|DBG
|'''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
|(debug only) print gool fixed point values
|-
|49/0x31
|RET
|'''00110001'''100001100100000000000000
|
|R,I
|
|
|
|
|conditionally stop gool execution (R and I ignored)
|-
|50/0x32
|BRA
|'''00110010'''0000100101VVVVIIIIIIIIII
|
|R,V,I
|
|
|
|
|branch
|-
|51/0x33
|BNEZ
|'''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
|R,V,I
|
|
|
|
|branch not equal zero
|-
|52/0x34
|BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
|R,V,I
|
|
|
|
|branch equal zero
|-
|53/0x35
|CST
|'''00110101'''0100100101AAAASSSSSSSSSS
|
|R,A,S
|
|
|
|
|change object state
|-
|54/0x36
|CNEZ
|'''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
|R,A,S
|
|
|
|
|change state if not zero
|-
|55/0x37
|CEQZ
|'''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
|R,A,S
|
|
|
|
|change state if zero
|-
|56/0x38
|ANIM
|'''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
|F,S,T,H
|
|
|W
|
|set and play animation+frame
|-
|57/0x39
|ANIF
|'''00111001'''HHTTTTTT0000FFFFFFFFFFFF
|F
|H,T
|
|
|W
|
|set and play frame of animation
|-
|58/0x3A
|VECA
|'''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
|V
|C,T,B,A
|
|
|*
|**
|multi-purpose vector calcs
|-
|59/0x3B
|JAL
|'''00111011'''VVVV00000EIIIIIIIIIIIIII
|
|I,V
|
|
|
|
|jump and link
|-
|60/0x3C
|EVNT
|'''00111100'''LLLAAARRRRRREEEEEEEEEEEE
|E
|L,A,R
|
|
|
|
|send an event
|-
|61/0x3D
|EVHR
|'''00111101'''TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|event handler: reject event
|-
|62/0x3E
|EVHA
|'''00111110'''TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|event handler: accept event
|-
|63/0x3F
|CHLD
|'''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
|C,T,S,A
|[C],
arg[0 to A]
|
|
|
|spawn children objects
|-
|64/0x40
|NTRY
|'''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
|T,E
|
|
|
|
|
|multi-purpose page operation
|-
|65/0x41
|SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
|A,V
|
|
|
|
|
|play sound effect
|-
|66/0x42
|SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
|S
|V,F,R
|
|
|
|
|adjust voice parameters
|-
|67/0x43
|VECB
|'''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
|V
|C,T,B,A
|
|
|
|
|multi-purpose vector calcs
|-
|68/0x44
|EVNB
|'''01000101'''LLLAAARRRRRREEEEEEEEEEEE
|E
|L,A,R
|
|
|
|
|send an event to all objects
|-
|69/0x45
|EVNC
|'''01000100'''LLLAAARRRRRREEEEEEEEEEEE
|E
|L,A,R
|
|
|
|
|send an event, cascading
|-
|70/0x46
|CHLF
|'''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
|A,T,S,C
|[C],
arg[0 to A]
|
|
|
|spawn children objects; forcefully?
|-
|71/0x47
|JALR
|'''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
|P,A
|
|arg[0 to A]
|
|
|
|jump and link to instruction pointed at by P
|-
|72/0x48
|CMSG
|'''01001000'''AAAAAAAAAAAAMMMMMMMMMMMM
|M,A
|
|
|AddCamMessage(M, &A)
|
|
|add message to camera queue (if not full), cam-message is M, its operands (dependant on message) are pointed to by A
|-
|73/0x49
|NATIVE
|'''01001001'''101111100000101111100000
|
|
|
|
|
|
|begin native (psx mips) code
|-
|74/0x4A
|?
|'''01001010'''------------AAAAAAAAAAAA
|A
|
|
|
|O
|
|unknown VIDO operation
|-
|75/0x4B
|?
|'''01001011'''------------AAAAAAAAAAAA
|A
|
|
|
|
|
|unknown
|-
|76/0x4C
|?
|'''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|
|
|
|
|unknown
|-
|77/0x4D
|?
|'''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|P,T
|
|
|
|unknown
|-
|78/0x4E
|ARRS
|'''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|S
|*(L + R) = S
L[R] = S
|
|
|store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

User:Mddass/List of GOOL Executables

2024-01-05T01:02:37Z

Mddass:

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General purpose ASCII text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

== Crash 2 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="12"|0
|<code>WillC</code>
|rowspan="12"|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>Wil2C</code>
|
|rowspan="11"|<code>WillC</code>
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

|<code>WiliC</code>
|
|<code>7</code> <code>i</code> <code>q</code>
|-

|<code>Wil9C</code>
|
|<code>9</code>
|-

|<code>WilaC</code>
|
|<code>a</code> <code>d</code> <code>u</code> <code>z</code>
|-

|<code>WildC</code>
|
|<code>d</code> <code>z</code>
|-

|<code>WileC</code>
|
|<code>e</code> <code>h</code> <code>j</code> <code>r</code> <code>t</code> <code>w</code> <code>y</code> <code>z</code> <code>B</code>
|-

|<code>WilnC</code>
|
|<code>l</code> <code>A</code>
|-

|<code>WiloC</code>
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

|<code>WiltC</code>
|
|<code>n</code> <code>t</code> <code>y</code> <code>B</code>
|-

|<code>WilkC</code>
|
|<code>p</code> <code>w</code> <code>x</code>
|-

|<code>WilsC</code>
|
|<code>s</code>
|-

!1
|<code>WarpC</code>
|5
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!2
|<code>TurtC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!6
|<code>BirdC</code>
|3
|
|
|<code>u</code> <code>v</code>
|-

!7
|<code>FiFaC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!8
|<code>SwarC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!10
|<code>MonkC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!11
|<code>GoriC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!12
|<code>SeweC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!13
|<code>ScrbC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>h</code> <code>j</code> <code>l</code> <code>m</code> <code>p</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>C</code>
|-

!15
|<code>JunOC</code>
|5
|
|
|<code>c</code> <code>o</code> <code>p</code> <code>s</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>D</code> <code>F</code>
|-

!16
|<code>WeldC</code>
|3
|
|
|<code>a</code> <code>d</code>
|-

!17
|<code>CardC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!18
|<code>BeeOC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!19
|<code>RRooC</code>
|3
|
|
|<code>6</code>
|-

!20
|<code>ArmaC</code>
|3
|
|
|<code>n</code> <code>s</code> <code>u</code> <code>v</code> <code>A</code>
|-

!21
|<code>MecWC</code>
|3
|
|
|<code>d</code> <code>z</code>
|-

!22
|<code>CortC</code>
|3
|
|
|<code>7</code>
|-

!24
|<code>SealC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code> <code>t</code> <code>y</code>
|-

!25
|<code>PengC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!26
|<code>RPltC</code>
|6
|
|
|<code>f</code> <code>m</code>
|-

!27
|<code>PorcC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!28
|<code>RatOC</code>
|3
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>m</code> <code>z</code> <code>D</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!30
|<code>OstrC</code>
|3
|
|
|<code>u</code>
|-

!31
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code>
|-

!32
|<code>SmasC</code>
|5
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!33
|<code>ABanC</code>
|3
|
|
|<code>n</code> <code>A</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>3</code> <code>6</code> <code>8</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>SpaOC</code>
|5
|
|
|<code>i</code> <code>q</code>
|-

!36
|<code>CHeOC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!37
|<code>LenFC</code>
|2
|
|
|<code>2</code> <code>c</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!38
|<code>PlanC</code>
|3
|
|
|<code>l</code> <code>p</code> <code>w</code> <code>x</code> <code>A</code>
|-

!39
|<code>AlpOC</code>
|3
|
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

!41
|<code>BoudC</code>
|5
|
|
|<code>n</code> <code>o</code> <code>r</code>
|-

!42
|<code>SLabC</code>
|3
|
|
|<code>i</code> <code>q</code>
|-

!43
|<code>TazOC</code>
|6
|
|
|<code>3</code>
|-

!44
|<code>Taz3C</code>
|3
|
|
|<code>3</code>
|-

!45
|<code>LJckC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!46
|<code>DraFC</code>
|3
|
|
|<code>c</code> <code>D</code>
|-

!47
|<code>RivOC</code>
|5
|
|
|<code>p</code> <code>w</code> <code>x</code>
|-

!48
|<code>BerOC</code>
|5
|
|
|<code>2</code> <code>n</code> <code>t</code> <code>y</code> <code>B</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!50
|<code>IntOC</code>
|5
|
|
|<code>s</code>
|-

!51
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!53
|<code>FredC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!54
|<code>KimoC</code>
|3
|
|
|<code>8</code>
|-

!55
|<code>DynOC</code>
|5
|
|
|<code>g</code> <code>C</code>
|-

!56
|<code>APusC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!57
|<code>FflOC</code>
|5
|
|
|<code>c</code> <code>D</code>
|-

!58
|<code>NGinC</code>
|3
|
|
|<code>9</code>
|-

!60
|<code>LighC</code>
|9
|
|
|<code>f</code> <code>u</code>
|-

!61
|<code>WinOC</code>
|5
|
|
|<code>E</code> <code>F</code>
|-

!62
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2024-01-05T00:58:13Z

Mddass:

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General purpose ASCII text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

== Crash 2 ==

<div style="text-align:center">
{| class="wikitable sortable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!0
|<code>Wil2C</code>
|1
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!0
|<code>WillC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!0
|<code>WiliC</code>
|1
|
|
|<code>7</code> <code>i</code> <code>q</code>
|-

!0
|<code>Wil9C</code>
|1
|
|
|<code>9</code>
|-

!0
|<code>WilaC</code>
|1
|
|
|<code>a</code> <code>d</code> <code>u</code> <code>z</code>
|-

!0
|<code>WildC</code>
|1
|
|
|<code>d</code> <code>z</code>
|-

!0
|<code>WileC</code>
|1
|
|
|<code>e</code> <code>h</code> <code>j</code> <code>r</code> <code>t</code> <code>w</code> <code>y</code> <code>z</code> <code>B</code>
|-

!0
|<code>WilnC</code>
|1
|
|
|<code>l</code> <code>A</code>
|-

!0
|<code>WiloC</code>
|1
|
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

!0
|<code>WiltC</code>
|1
|
|
|<code>n</code> <code>t</code> <code>y</code> <code>B</code>
|-

!0
|<code>WilkC</code>
|1
|
|
|<code>p</code> <code>w</code> <code>x</code>
|-

!0
|<code>WilsC</code>
|1
|
|
|<code>s</code>
|-

!1
|<code>WarpC</code>
|5
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!2
|<code>TurtC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!3
|<code>FruiC</code>
|4
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!4
|<code>DispC</code>
|2
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!5
|<code>DoctC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!6
|<code>BirdC</code>
|3
|
|
|<code>u</code> <code>v</code>
|-

!7
|<code>FiFaC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!8
|<code>SwarC</code>
|3
|
|
|<code>n</code> <code>u</code> <code>v</code> <code>A</code>
|-

!9
|<code>PartC</code>
|9
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>E</code> <code>F</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code> <code>X</code> <code>Y</code>
|-

!10
|<code>MonkC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!11
|<code>GoriC</code>
|3
|
|
|<code>f</code> <code>m</code>
|-

!12
|<code>SeweC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!13
|<code>ScrbC</code>
|3
|
|
|<code>a</code> <code>d</code> <code>z</code>
|-

!14
|<code>PlatC</code>
|6
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>h</code> <code>j</code> <code>l</code> <code>m</code> <code>p</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>C</code>
|-

!15
|<code>JunOC</code>
|5
|
|
|<code>c</code> <code>o</code> <code>p</code> <code>s</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>D</code> <code>F</code>
|-

!16
|<code>WeldC</code>
|3
|
|
|<code>a</code> <code>d</code>
|-

!17
|<code>CardC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!18
|<code>BeeOC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!19
|<code>RRooC</code>
|3
|
|
|<code>6</code>
|-

!20
|<code>ArmaC</code>
|3
|
|
|<code>n</code> <code>s</code> <code>u</code> <code>v</code> <code>A</code>
|-

!21
|<code>MecWC</code>
|3
|
|
|<code>d</code> <code>z</code>
|-

!22
|<code>CortC</code>
|3
|
|
|<code>7</code>
|-

!24
|<code>SealC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code> <code>t</code> <code>y</code>
|-

!25
|<code>PengC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!26
|<code>RPltC</code>
|6
|
|
|<code>f</code> <code>m</code>
|-

!27
|<code>PorcC</code>
|3
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!28
|<code>RatOC</code>
|3
|
|
|<code>a</code> <code>c</code> <code>d</code> <code>f</code> <code>m</code> <code>z</code> <code>D</code>
|-

!29
|<code>ShadC</code>
|1
|
|
|<code>2</code> <code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!30
|<code>OstrC</code>
|3
|
|
|<code>u</code>
|-

!31
|<code>BosBC</code>
|2
|
|
|<code>3</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code>
|-

!32
|<code>SmasC</code>
|5
|
|
|<code>e</code> <code>h</code> <code>j</code>
|-

!33
|<code>ABanC</code>
|3
|
|
|<code>n</code> <code>A</code>
|-

!34
|<code>BoxsC</code>
|4
|
|
|<code>3</code> <code>6</code> <code>8</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>g</code> <code>h</code> <code>i</code> <code>j</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>D</code>
|-

!35
|<code>SpaOC</code>
|5
|
|
|<code>i</code> <code>q</code>
|-

!36
|<code>CHeOC</code>
|5
|
|
|<code>2</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!37
|<code>LenFC</code>
|2
|
|
|<code>2</code> <code>c</code> <code>D</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!38
|<code>PlanC</code>
|3
|
|
|<code>l</code> <code>p</code> <code>w</code> <code>x</code> <code>A</code>
|-

!39
|<code>AlpOC</code>
|3
|
|
|<code>l</code> <code>n</code> <code>o</code> <code>r</code> <code>A</code>
|-

!41
|<code>BoudC</code>
|5
|
|
|<code>n</code> <code>o</code> <code>r</code>
|-

!42
|<code>SLabC</code>
|3
|
|
|<code>i</code> <code>q</code>
|-

!43
|<code>TazOC</code>
|6
|
|
|<code>3</code>
|-

!44
|<code>Taz3C</code>
|3
|
|
|<code>3</code>
|-

!45
|<code>LJckC</code>
|3
|
|
|<code>l</code> <code>A</code>
|-

!46
|<code>DraFC</code>
|3
|
|
|<code>c</code> <code>D</code>
|-

!47
|<code>RivOC</code>
|5
|
|
|<code>p</code> <code>w</code> <code>x</code>
|-

!48
|<code>BerOC</code>
|5
|
|
|<code>2</code> <code>n</code> <code>t</code> <code>y</code> <code>B</code> <code>J</code> <code>K</code> <code>L</code> <code>M</code>
|-

!50
|<code>IntOC</code>
|5
|
|
|<code>s</code>
|-

!51
|<code>TitOC</code>
|5
|
|
|<code>Y</code>
|-

!53
|<code>FredC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!54
|<code>KimoC</code>
|3
|
|
|<code>8</code>
|-

!55
|<code>DynOC</code>
|5
|
|
|<code>g</code> <code>C</code>
|-

!56
|<code>APusC</code>
|3
|
|
|<code>g</code> <code>C</code>
|-

!57
|<code>FflOC</code>
|5
|
|
|<code>c</code> <code>D</code>
|-

!58
|<code>NGinC</code>
|3
|
|
|<code>9</code>
|-

!60
|<code>LighC</code>
|9
|
|
|<code>f</code> <code>u</code>
|-

!61
|<code>WinOC</code>
|5
|
|
|<code>E</code> <code>F</code>
|-

!62
|<code>GamOC</code>
|5
|
|
|<code>X</code> <code>Y</code>
|-
|}
</div>

Level ID

2023-04-06T01:10:44Z

Mddass: /* Crash 2 */

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<u>'''13'''</u>.NSD</code> and <code>S00000<u>'''13'''</u>.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>
| [[Lava Cave Level]]
|-
| <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]]
|-
| <code>2B</code>
| <code>H</code>
| (none)
|}

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. Level <code>H</code> (2B) is non-existent and is placed before "Fumbling in the Dark" in the proto map. 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)
|-
| <code>3F</code>
| <code>!</code>
| ''(none)''
| ''(none)''
|}

== Crash 3 ==
{{todo|Add gem ID's for [[Area 51?]], [[Rings of Power]].}}
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)''
| Coco's gem, from obtaining all 30 gold relics.
|}

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

Entry

2022-11-14T20:16:19Z

Mddass: /* Types */

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 frames of shaded vertex animation for an object
|-
|2
|Object Model Geometry
|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/Sort 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 single sound effect
|-
|13
|MIDI
|MIDI
|contains the MIDI sequence(s) for a level's background music (SEP) and/or a wavebank header (VH)
|-
|14
|Instruments
|INST
|describes instrument data used to play a MIDI (VB)
|-
|15
|Image Data (Crash 1)<br />Video? Collision (Crash 2/3)
|IMAG (Crash 1)<br />VCOL (Crash 2/3)
|contains raw image data (i.e. anti-piracy message, SCE screen)<sup>1</sup> (Crash 1)<br />contains special collision detection rules? (i.e. digging, chased by boulder) (Crash 2/3)
|-
|17
|Map Data (Crash 1)<br />Raw Data (Crash 3)
|MDAT (Crash 1)<br />RAWD (Crash 3)
|contains data describing how a 16-bit image should be displayed on-screen (Crash 1)<br />contains miscellaneous 3D terrain data (scenery in baron levels, water in levels with water) (Crash 3)
|-
|18
|Palettes
|IPAL
|describes a list of 256-color CLUTs used for IMAG and MDAT entries
|-
|19
|Demo playback
|PBAK
|contains a pre-recorded sequence of button presses for playback
|-
|20
|Colored Animation
Vertices/Animation (Crash 1)<br />Stream Audio (Crash 2/3)
|CVTX (Crash 1)<br />SDIO (Crash 2/3)
|contains frames of colored but non-shaded colored vertex animation for an object (Crash 1)<br />contains streamable 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)
|}
<sup>1</sup> - 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]]

GOOL Executable

2022-11-14T20:06:21Z

Mddass: /* Format */

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
|Is main executable
|4 bytes
|
|-
|0xC
|Initial Stack Frame Offset
|4 bytes
|
|-
|0x10
|Subtype->State Map Index<br />Max Interrupt Offset
|4 bytes
|s
|-
|0x14
|Static linked Entry count
|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
|(Static linked Entry count) x 4 bytes + * 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
|*
|}

Level ID

2020-11-30T05:39:04Z

Mddass: /* Crash 3 */

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<u>'''13'''</u>.NSD</code> and <code>S00000<u>'''13'''</u>.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>
| [[Lava Cave Level]]
|-
| <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]]
|-
| <code>2B</code>
| <code>H</code>
| (none)
|}

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. Level <code>H</code> (2B) is non-existent and is placed before "Fumbling in the Dark" in the proto map. 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]].}}
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)''
| Coco's gem, from obtaining all 30 gold relics.
|}

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

Level ID

2020-11-30T05:14:24Z

Mddass: /* Crash 3 */

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<u>'''13'''</u>.NSD</code> and <code>S00000<u>'''13'''</u>.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>
| [[Lava Cave Level]]
|-
| <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]]
|-
| <code>2B</code>
| <code>H</code>
| (none)
|}

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. Level <code>H</code> (2B) is non-existent and is placed before "Fumbling in the Dark" in the proto map. 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]].}}
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>
| Coco's gem, from obtaining all 30 gold relics.
|}

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

User:Mddass/List of GOOL Executables

2020-08-17T03:15:33Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-08-07T09:44:03Z

Mddass: /* Crash 1 */

Level ID

2020-08-01T00:41:30Z

Mddass: /* Prerelease Versions */

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<u>'''13'''</u>.NSD</code> and <code>S00000<u>'''13'''</u>.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>
| [[Lava Cave Level]]
|-
| <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]]
|-
| <code>2B</code>
| <code>H</code>
| (none)
|}

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. Level <code>H</code> (2B) is non-existent and is placed before "Fumbling in the Dark" in the proto map. 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.

User:Mddass/List of GOOL Executables

2020-07-29T03:55:42Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!44
|<code>MapOC</code>
|1
|Map objects (prototype)
|
|<code>p</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:09:37Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:08:56Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code> <code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code> <code>i</code> <code>o</code> <code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code> <code>b</code> <code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>p</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code> <code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code> <code>k</code> <code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code> <code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>F</code> <code>T</code> <code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code> <code>5</code> <code>6</code> <code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>e</code> <code>j</code> <code>l</code> <code>s</code> <code>t</code> <code>w</code> <code>y</code> <code>E</code> <code>G</code> <code>K</code> <code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code> <code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code> <code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code> <code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code> <code>b</code> <code>d</code> <code>i</code> <code>k</code> <code>l</code> <code>m</code> <code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code> <code>b</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>j</code> <code>l</code> <code>o</code> <code>A</code> <code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code> <code>k</code> <code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code> <code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code> <code>d</code> <code>i</code> <code>j</code> <code>l</code> <code>q</code> <code>s</code> <code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code> <code>n</code> <code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code> <code>2</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <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>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>v</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code> <code>a</code> <code>n</code> <code>r</code> <code>v</code> <code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code> <code>5</code> <code>6</code> <code>7</code> <code>9</code> <code>b</code> <code>c</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>m</code> <code>o</code> <code>q</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>w</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>I</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code> <code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code> <code>3</code> <code>4</code> <code>5</code> <code>6</code> <code>7</code> <code>8</code> <code>9</code> <code>a</code> <code>c</code> <code>d</code> <code>e</code> <code>f</code> <code>h</code> <code>i</code> <code>j</code> <code>k</code> <code>m</code> <code>n</code> <code>o</code> <code>q</code> <code>r</code> <code>s</code> <code>t</code> <code>u</code> <code>w</code> <code>x</code> <code>y</code> <code>z</code> <code>A</code> <code>B</code> <code>C</code> <code>E</code> <code>F</code> <code>G</code> <code>J</code> <code>K</code> <code>P</code> <code>Q</code> <code>T</code> <code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code> <code>l</code> <code>E</code> <code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code> <code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code> <code>i</code> <code>q</code> <code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code> <code>t</code> <code>w</code> <code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code> <code>s</code> <code>t</code> <code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code> <code>B</code> <code>C</code> <code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code> <code>y</code> <code>z</code> <code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code> <code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code> <code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code> <code>C</code> <code>J</code> <code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code> <code>E</code> <code>F</code> <code>G</code> <code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code> <code>y</code> <code>F</code> <code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code> <code>7</code> <code>f</code> <code>n</code> <code>o</code> <code>w</code> <code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code> <code>B</code> <code>C</code> <code>P</code> <code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code> <code>A</code> <code>C</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code> <code>c</code> <code>f</code> <code>i</code> <code>j</code> <code>k</code> <code>l</code> <code>q</code> <code>t</code> <code>E</code> <code>I</code> <code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code> <code>A</code> <code>J</code> <code>P</code> <code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code> <code>U</code> <code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:07:09Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code><code>b</code><code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code><code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code><code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code><code>b</code><code>d</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code><code>b</code><code>c</code><code>d</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code><code>k</code><code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code><code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code><code>d</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|rowspan="2"|1
|General purpose shadows
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>b</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>d</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code><code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code><code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code><code>U</code><code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:06:52Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|rowspan="3"|1
|Willy playable character
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code><code>b</code><code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code><code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code><code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code><code>b</code><code>d</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code><code>b</code><code>c</code><code>d</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code><code>k</code><code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code><code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code><code>d</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>b</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>d</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code><code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code><code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code><code>U</code><code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:06:28Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|1
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code><code>b</code><code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code><code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code><code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code><code>b</code><code>d</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code><code>b</code><code>c</code><code>d</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code><code>k</code><code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code><code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code><code>d</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>b</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>d</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code><code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code><code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code><code>U</code><code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:03:54Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!2
|<code>SkunC</code>
|3
|Skunk
|
|<code>2</code><code>b</code><code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code><code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code><code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code><code>b</code><code>d</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code><code>b</code><code>c</code><code>d</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code><code>k</code><code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code><code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code><code>d</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>b</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>d</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code><code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code><code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code><code>U</code><code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T03:03:36Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!1
|<code>SkunC</code>
|2
|Skunk
|
|<code>2</code><code>b</code><code>d</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!6
|<code>SnakC</code>
|3
|Snake
|
|<code>2</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>2</code><code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!13
|<code>PoCoC</code>
|5
|Power level continue point
|
|<code>b</code><code>d</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code><code>b</code><code>d</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code><code>b</code><code>c</code><code>d</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>b</code><code>k</code><code>m</code>
|-

!24
|<code>HyeaC</code>
|3
|Hyena
|
|<code>b</code><code>d</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code><code>d</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!26
|<code>CliOC</code>
|6
|Cliff objects
|
|<code>d</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|
|<code>1</code><code>2</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>b</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>1</code><code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>d</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>1</code><code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>1</code><code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code><code>U</code><code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T02:51:01Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|
|<code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|
|<code>6</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|
|<code>9</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|
|<code>9</code><code>c</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|
|<code>k</code><code>m</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|
|<code>c</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|
|<code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|
|<code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|
|<code>I</code><code>U</code><code>V</code>
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T02:50:26Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|N/A
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code><code>V</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|N/A
|<code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|N/A
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|N/A
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code><code>T</code><code>U</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|N/A
|<code>3</code><code>5</code><code>6</code><code>T</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code><code>G</code><code>K</code><code>T</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|N/A
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|N/A
|<code>6</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|N/A
|<code>6</code><code>T</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|N/A
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|N/A
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|N/A
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|N/A
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|N/A
|<code>9</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|N/A
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|N/A
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|N/A
|<code>9</code><code>c</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code><code>P</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|N/A
|<code>k</code><code>m</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|N/A
|<code>c</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|N/A
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|N/A
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|N/A
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|N/A
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|N/A
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>I</code><code>K</code><code>P</code><code>Q</code><code>T</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|N/A
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code><code>G</code><code>J</code><code>K</code><code>P</code><code>Q</code><code>T</code><code>U</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|N/A
|<code>c</code><code>l</code><code>E</code><code>G</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|N/A
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|N/A
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|N/A
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|N/A
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|N/A
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|N/A
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|N/A
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|N/A
|<code>s</code><code>t</code><code>G</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|N/A
|<code>x</code><code>B</code><code>C</code><code>Q</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|N/A
|<code>w</code><code>y</code><code>z</code><code>K</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|N/A
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|N/A
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|N/A
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|N/A
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|N/A
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|N/A
|<code>p</code><code>C</code><code>J</code><code>Q</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|N/A
|<code>y</code><code>E</code><code>F</code><code>G</code><code>K</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|N/A
|<code>y</code><code>F</code><code>K</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|N/A
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|N/A
|<code>A</code><code>B</code><code>C</code><code>P</code><code>Q</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|N/A
|<code>p</code><code>A</code><code>C</code><code>J</code><code>P</code><code>Q</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|N/A
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code><code>I</code><code>T</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|N/A
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|N/A
|<code>p</code><code>A</code><code>J</code><code>P</code><code>Q</code>
|-

!61
|<code>WinGC</code>
|3
|Game victory & cutscenes
|N/A
|<code>I</code><code>U</code><code>V</code>
|-

|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T02:33:29Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|N/A
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|N/A
|<code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|N/A
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|N/A
|<code>3</code><code>5</code><code>6</code><code>7</code><code>F</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|N/A
|<code>3</code><code>5</code><code>6</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code><code>w</code><code>y</code><code>E</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|N/A
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|N/A
|<code>6</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|N/A
|<code>6</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|N/A
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|N/A
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|N/A
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|N/A
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|N/A
|<code>9</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|N/A
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|N/A
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|N/A
|<code>9</code><code>c</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code><code>A</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|N/A
|<code>k</code><code>m</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|N/A
|<code>c</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|N/A
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|N/A
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!30
|<code>KonOC</code>
|3
|Kong boss objects
|N/A
|<code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|N/A
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|N/A
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code><code>w</code><code>w</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|N/A
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>w</code><code>x</code><code>y</code><code>z</code><code>A</code><code>B</code><code>C</code><code>E</code><code>F</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|N/A
|<code>c</code><code>l</code><code>E</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|N/A
|<code>r</code><code>F</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|N/A
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|N/A
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|N/A
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|N/A
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|N/A
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|N/A
|<code>s</code><code>t</code><code>w</code><code>z</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|N/A
|<code>s</code><code>t</code>
|-

!45
|<code>KongC</code>
|3
|Kong
|N/A
|<code>x</code><code>B</code><code>C</code>
|-

!46
|<code>RWaOC</code>
|6
|Ruins wall objects
|N/A
|<code>w</code><code>y</code><code>z</code>
|-

!47
|<code>LizaC</code>
|3
|Lizard
|N/A
|<code>w</code><code>z</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|N/A
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|N/A
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|N/A
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|N/A
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|N/A
|<code>p</code><code>C</code>
|-

!53
|<code>CasOC</code>
|5
|Castle objects
|N/A
|<code>y</code><code>E</code><code>F</code>
|-

!54
|<code>LabAC</code>
|3
|Lab assistant
|N/A
|<code>y</code><code>F</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|N/A
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code><code>w</code><code>z</code>
|-

!56
|<code>BonoC</code>
|3
|Bonus Round
|N/A
|<code>A</code><code>B</code><code>C</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|N/A
|<code>p</code><code>A</code><code>C</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|N/A
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code><code>E</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|N/A
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|N/A
|<code>p</code><code>A</code>
|-

|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T02:16:36Z

Mddass: /* Crash 1 */

== Crash 1 ==

<div style="text-align:center">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-

!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-

!1
|<code>MonkC</code>
|3
|Monkey
|N/A
|<code>2</code><code>i</code><code>o</code><code>q</code>
|-

!3
|<code>FruiC</code>
|4
|General fruit and pickups
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code>
|-

!4
|<code>DispC</code>
|2
|General values and icons display (i.e. HUD)
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>p</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code>
|-

!5
|<code>DoctC</code>
|1
|Witch doctor
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code>
|-

!7
|<code>WartC</code>
|3
|Warthog
|N/A
|<code>k</code><code>m</code>
|-

!8
|<code>PoDoC</code>
|5
|Power level doors
|N/A
|<code>3</code><code>5</code>
|-

!9
|<code>PoRoC</code>
|3
|Power level robot and general objects
|N/A
|<code>3</code><code>5</code><code>6</code><code>7</code>
|-

!10
|<code>PoREC</code>
|3
|Power level robot enemy
|N/A
|<code>3</code><code>5</code><code>6</code>
|-

!11
|<code>PoPlC</code>
|6
|Power level platforms/General purpose platforms
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>e</code><code>j</code><code>l</code><code>s</code><code>t</code>
|-

!12
|<code>MafiC</code>
|3
|Mafia enemy
|N/A
|<code>3</code><code>8</code>
|-

!13
|<code>Dog_C</code>
|3
|Guard dog
|N/A
|<code>6</code>
|-

!14
|<code>PoObC</code>
|5
|Power level obstacles
|N/A
|<code>6</code>
|-

!15
|<code>PinsC</code>
|3
|Pinstripe
|N/A
|<code>8</code>
|-

!16
|<code>BaraC</code>
|3
|Barrels
|N/A
|<code>7</code>
|-

!17
|<code>FatsC</code>
|3
|"Fat" enemy
|N/A
|<code>7</code>
|-

!18
|<code>PinOC</code>
|5
|Pinstripe boss objects
|N/A
|<code>8</code>
|-

!19
|<code>TurtC</code>
|3
|Turtle
|N/A
|<code>9</code><code>i</code><code>k</code><code>l</code><code>m</code><code>q</code>
|-

!20
|<code>ChefC</code>
|3
|Village chief
|N/A
|<code>a</code>
|-

!21
|<code>CheOC</code>
|5
|Chief boss objects
|N/A
|<code>a</code>
|-

!22
|<code>JunOC</code>
|5
|Jungle objects
|N/A
|<code>9</code><code>c</code><code>e</code><code>f</code><code>j</code><code>l</code><code>o</code>
|-

!23
|<code>BridC</code>
|5
|Bridge objects
|N/A
|<code>k</code><code>m</code>
|-

!25
|<code>PlanC</code>
|3
|Plant enemy
|N/A
|<code>c</code><code>i</code><code>j</code><code>l</code><code>q</code><code>s</code><code>t</code>
|-

!27
|<code>BeaOC</code>
|5
|Beach objects
|N/A
|<code>9</code>
|-

!28
|<code>RivOC</code>
|6
|River objects
|N/A
|<code>f</code><code>n</code><code>o</code>
|-

!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><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>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code><code>v</code><code>w</code><code>x</code><code>y</code><code>z</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-

!31
|<code>CrabC</code>
|3
|Crab
|N/A
|<code>9</code>
|-

!32
|<code>WarpC</code>
|5
|Warp objects
|N/A
|<code>3</code><code>5</code><code>6</code><code>7</code><code>9</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>l</code><code>m</code><code>o</code><code>q</code><code>s</code><code>t</code><code>u</code>
|-

!33
|<code>WalOC</code>
|6
|Wall level objects
|N/A
|<code>i</code><code>q</code>
|-

!34
|<code>BoxsC</code>
|4
|Boxes and smoke
|N/A
|<code>3</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>c</code><code>e</code><code>f</code><code>h</code><code>i</code><code>j</code><code>k</code><code>m</code><code>n</code><code>o</code><code>q</code><code>r</code><code>s</code><code>t</code><code>u</code>
|-

!35
|<code>PillC</code>
|3
|Pill enemies
|N/A
|<code>c</code><code>l</code>
|-

!36
|<code>frogC</code>
|3
|Frog enemy
|N/A
|<code>r</code>
|-

!37
|<code>RRooC</code>
|3
|Ripper Roo
|N/A
|<code>n</code>
|-

!38
|<code>SheNC</code>
|3
|Shield native
|N/A
|<code>h</code><code>i</code><code>q</code><code>u</code>
|-

!39
|<code>RooOC</code>
|5
|Ripper Roo boss objects
|N/A
|<code>n</code>
|-

!40
|<code>BrioC</code>
|3
|Brio
|N/A
|<code>r</code>
|-

!41
|<code>BriOC</code>
|5
|Brio boss objects
|N/A
|<code>r</code>
|-

!42
|<code>RuiOC</code>
|6
|Ruins objects
|N/A
|<code>s</code><code>t</code>
|-

!43
|<code>SpidC</code>
|3
|Spider
|N/A
|<code>s</code><code>t</code>
|-

!48
|<code>Opt0C</code>
|5
|Game options
|N/A
|<code>p</code>
|-

!49
|<code>CortC</code>
|3
|Cortex
|N/A
|<code>v</code>
|-

!50
|<code>CorOC</code>
|5
|Cortex boss objects
|N/A
|<code>v</code>
|-

!51
|<code>VilOC</code>
|5
|Village level objects
|N/A
|<code>h</code><code>u</code>
|-

!52
|<code>GamOC</code>
|3
|Game progress objects
|N/A
|<code>p</code>
|-

!55
|<code>WateC</code>
|5
|Water effects (splash and droplet)
|N/A
|<code>3</code><code>7</code><code>f</code><code>n</code><code>o</code>
|-

!57
|<code>CardC</code>
|5
|Memory card
|N/A
|<code>p</code>
|-

!58
|<code>GemsC</code>
|4
|Gem platforms
|N/A
|<code>3</code><code>c</code><code>f</code><code>i</code><code>j</code><code>k</code><code>l</code><code>q</code><code>t</code>
|-

!59
|<code>IsldC</code>
|1
|Map islands
|N/A
|<code>p</code>
|-

!60
|<code>AsciC</code>
|5
|General text display
|N/A
|<code>p</code>
|-

|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|}
</div>

User:Mddass/List of GOOL Executables

2020-07-29T01:52:47Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:50:35Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:48:38Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:44:42Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:42:32Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:35:22Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:23:37Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T01:18:45Z

Mddass: /* Crash 1 */

User:Mddass/List of GOOL Executables

2020-07-29T00:58:43Z

Mddass: Created page with "== Crash 1 == <div style="padding:0"> {| class="wikitable" !ID !Name !Category !Description !Dependency !Level Presence |- !rowspan="3"|0 |<code>WillC</code> |1 |Willy playab..."

== Crash 1 ==

<div style="padding:0">
{| class="wikitable"
!ID
!Name
!Category
!Description
!Dependency
!Level Presence
|-
!rowspan="3"|0
|<code>WillC</code>
|1
|Willy playable character
|N/A
|<code>1</code><code>2</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>b</code>
|-
|<code>Wil9C</code>
|1
|Willy beach cutscene
|<code>WillC</code>
|<code>9</code>
|-
|<code>WilhC</code>
|
|Willy village level
|<code>WillC</code>
|<code>h</code><code>u</code>
|-
!rowspan="2"|29
|<code>ShadC</code>
|1
|General purpose shadows
|N/A
|<code>1</code><code>2</code><code>4</code><code>5</code><code>6</code><code>7</code><code>8</code><code>9</code><code>a</code><code>b</code>
|-
|<code>ShabC</code>
|1
|Boss health meter
|<code>ShadC</code>
|<code>8</code><code>a</code><code>n</code><code>r</code><code>v</code><code>x</code>
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|-
|}
</div>

User:Mddass

2020-07-29T00:40:17Z

Mddass:

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest

[[User:Mddass/List of GOOL Executables]]

== Crash 2 Return/Error Codes ==
Engine assumes codes range from <code>0xFFFFFF01</code> to <code>0xFFFFFFFF</code>. A special return/error code, <code>0</code>, is used in certain GOOL interpretation functions (event, state change, animation change) to indicate that the function failed and/or that interpretation should continue.
{| border="1"
!Code
!Meaning
!Additional Notes
|-
|0xFFFFFF01 (-0xFF)
|No error.
|
|-
|0xFFFFFF02 (-0xFE)
|Error finding specified file.
|"File" includes entries and disc files.
|-
|
|
|
|-
|0xFFFFFFE5 (-0x1B)
|The specified object state is invalid.
|For example, when an object's subtype corresponds to state 255 (invalid).
|-
|0xFFFFFFE6 (-0x1A)
|Event failed? GOOL interpreter failed?
|
|-
|0xFFFFFFE7 (-0x19)
|GOOL stack frame update unsuccessful.
|
|-
|0xFFFFFFE8 (-0x18)
|Object linked list remove unsuccessful.
|
|-
|0xFFFFFFEA (-0x16)
|Object could not be spawned from entity, pools are full.
|
|-
|
|
|
|-
|0xFFFFFFEE (-0x12)
|Chunk load failed.
|Wrong magic, invalid page pointer, etc.
|-
|
|
|-
|0xFFFFFFF0 (-0x10)
|Unknown.
|Returned by FUN_80012ed0 and FUN_80013084. Chunk load success?
|-
|0xFFFFFFF1 (-0xF)
|Out of memory.
|
|-
|0xFFFFFFF2 (-0xE)
|Object is malformed.
Texture load success.
|Returned on state change if object status b-flag 0x10000000 is set or if state is 255 (invalid), etc.
|-
|
|
|
|-
|0xFFFFFFF6 (-0xA)
|Tried to find null entry.
|GetEntry was trying to find "NONE!".
|-
|}

== Crash 2 GOOL Interpretation Locations ==
<syntaxhighlight lang="c">
uint GoolChangeObjState(c2_object_s *obj,int newstate,int argc,int *argv)
{
...
// if hpc (hpc is reset to NULL before this, hpc used here is from before)
GOOLInterpret(obj,0x13,NULL); // hpc
...
// if tpc and is last updated object
GOOLInterpret(obj,0x3,NULL); // obj->tpc = state->tpc
...
}

uint FUN_8001c718(c2_object_s *obj,int unkflag) // some object update routine every frame
{
...
// if tpc
GOOLInterpret(obj,0x3,NULL); // tpc
...
// if wait is 0
GOOLInterpret(obj,0x4,NULL); // ??? pc
...
}

uint ObjSendEvent(c2_object_s *sender,c2_object_s *receiver,int event,int argc,uint *argv)
{
...
// if receiver->epc
GOOLInterpret(receiver,0x8,NULL); // tpc
...
// if previous interpretation was unsuccesful and interrupt is mapped to subroutine
GOOLInterpret(receiver,0x3,NULL); // interrupt-pc
...
GoolChangeObjState(receiver,eState,argc,argv);
...
}

void GoolInterrupt(c2_object_s *obj,uint newpc,int argc,uint *argv)
{
...
GOOLInterpret(obj,0x3,NULL); // newpc
...
}
</syntaxhighlight>

GOOL Interpreter

2020-06-30T09:25:05Z

Mddass: /* GOOLv2 Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
|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
|LOOP
|00010011AAAAAAAAAAAABBBBBBBBBBBB
|(A),B
|R = 0x100
|[R,A]
|B = A >= 0 ? B + R : B - R
if (B > A && A > 0) B = -A + R*2
else if (B < A && A < 0) B = -A - R*2
P = A >= 0 ? abs(B) : -abs(B)
|P
|B
|loop around zero

|-
|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
|PUSH
|00010110AAAAAAAAAAAABBBBBBBBBBBB
|[A,[B]]
|
|
|[arg_buf = A]
I = A; J = B;
|[I,[J]]
|
|push value to stack

|-
|23/0x17
|NOTB
|00010111SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|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*grav) >> 10)
|S
|
|calculate speed

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

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

|-
|30/0x1E
|TICK
|00011110DDDDDDDDDDDDPPPPPPPPPPPP
|M,P
|
|
|O = (M + frameCount) % P
|O
|
|get game time

|-
|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
|DEGD
|00100001RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = degdist(L,R)
|
|
|angle between

|-
|34/0x22
|SEEK
|00100010RRRRRRRRRRRRLLLLLLLLLLLL
|L,(R)
|S = 0x100
|[R,S]
|O = seek(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
|00100100000IIIIIILLLCCCCCCCCCCCC
|C
|I,L
|
|obj.link[L].colors[I] = C
|
|
|color vector or matrix write

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

|-
|38/0x26
|PSHP
|00100110AAAAAAAAAAAABBBBBBBBBBBB
|[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
|ANIM
|10000011HHTTTTTTSSSSSSSSSFFFFFFF
|
|F,S,T,H
|
|
|W
|
|play animation at specified frame

|-
|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
|EVHR
|10001001TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|reject event

|-
|137/0x89
|EVHA
|10001000TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|<br>
|
|accept event
|-
|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
|SNDP
|10001100AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|
|
|
|
|play audio file at volume

|-
|141/0x8D
|SNDB
|10001101FFFFRRRRRRSSSSSSSSSSSSSS
|S
|F,R
|
|
|
|
|adjust voice parameters
|-
|142/0x8E
|VECB
|10001110CCCTTTBBBAAAVVVVVVVVVVVV
|V
|T,A,B,C
|
|
|
|<br>
|multi-purpose vector calcs

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

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

|-
|145/0x91
|CHLF
|10100000AAAATTTTTTTTSSSSSSCCCCCC
|
|C,T,S,A
|[C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
|O
|
|logical and
|-
|6/0x06
|ORL
|'''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
|O
|<br>
|logical or (same as ORB)
|-
|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
|LOOP
|'''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
|(A),B
|R = 0x100
|[R,A]
|B = A >= 0 ? B + R : B - R
if (B > A && A > 0) B = -A + R*2
else if (B < A && A < 0) B = -A - R*2
P = A >= 0 ? abs(B) : -abs(B)
|P
|B
|loop around zero
|-
|20/0x14
|LEA
|'''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = &S
|
|D
|load effective address
|-
|21/0x15
|SHA
|'''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
|O
|
|bit shift
|-
|22/0x16
|PUSH
|'''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
|A,[B]
|
|
|
I = A; J = B;
|I,[J]
|
|push value(s) to stack
|-
|23/0x17
|NOTB
|'''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
|D = ~S
|
|D
|bitwise not (nor)
|-
|24/0x18
|MOVC
|'''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
|R,E,I
|
|see docs
|O
|
|get code pointer
|-
|25/0x19
|ABS
|'''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = (S < 0) ? -S : S
|
|D
|absolute value
|-
|26/0x1A
|PAD
|'''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
|B,P,S,D,T
|
|O = testctrls(instr,0)
|O
|
|test controller buttons
|-
|27/0x1B
|SPD
|'''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
|V,B
|
|
|S = B + ((V*gvel) >> 10)
|S
|
|calculate speed
|-
|28/0x1C
|MSC
|'''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
|X
|P,S,L
|
|various
|
|
|multi-purpose
|-
|29/0x1D
|PSIN
|'''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
|P,D
|
|
|large calc; see docs
|
|
|driven sine wave
|-
|30/0x1E
|TICK
|'''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = (R + TICKS) % L
|O
|
|get ticks
|-
|31/0x1F
|RGL
|'''00011111'''101111100000IIIIIIIIIIII
|I
|
|
|O = globals[I]
|O
|
|read global variable
|-
|32/0x20
|WGL
|'''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
|I,S
|
|
|globals[I] = *S
|
|
|write global variable
|-
|33/0x21
|ANGD
|'''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
|R,L
|
|
|O = ((R << 20) - (L << 20)) >> 20
|O
|
|angle distance (note: shifts are for sign extension)
|-
|34/0x22
|APCH
|'''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,(R)
|
|
|O = approach(L,R,S)
|O
|
|approach a value
|-
|35/0x23
|CVMR
|'''00100011'''000IIIIIILLL000000000000
|
|I,L
|
|O = obj.link[L].colors[I]
|O
|
|color vector or matrix read
|-
|36/0x24
|CVMW
|'''00100100'''000IIIIIILLLCCCCCCCCCCCC
|C
|I,L
|
|obj.link[L].colors[I] = C
|
|
|color vector or matrix write
|-
|37/0x25
|ROT
|'''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
|(R),L
|
|[R,S]
|O = rotate(L,R,S,0)
|
|
|approach an angle
|-
|38/0x26
|PSHP
|'''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
|A,[B]
|
|
|I = &A; J = &B;
|I,[J]
|
|push pointer(s)
|-
|39/0x27
|ANIS
|'''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
|F
|
|
|D=&obj.global.anim[F>>8]
|
|D
|set animation
|-
|40/0x28
|EFLR
|'''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
|A,B
|
|
|O = GetFieldValue(obj->entity, field: A, row: B)
|O
|
|load entity field row data
|-
|41/0x29
|EFLV
|'''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = GetFieldValue(obj->entity, field: S)
|
|D
|get entity field data
|-
|42/0x2A
|ARRL
|'''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = *(L + R)
o = L[R]
|O
|
|load array value
|-
|43/0x2B
|SIN
|'''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = sin(S)
|
|D
|sine wave (output: -0x1000 to 0x1000)
|-
|44/0x2C
|COS
|'''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|D = cos(S)
D = sin(S + PI/2)
|
|D
|cosine wave (output: -0x1000 to 0x1000)
|-
|45/0x2D
|ATAN
|'''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
|X,Y
|
|
|o = atan2(X, Y)
|o
|
|arc-tangent2, angle to point (confirmation needed)
|-
|46/0x2E
|?
|'''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
|A
|
|
|
|
|D
|unknown
|-
|47/0x2F
|NOP
|'''00101111'''101111100000101111100000
|
|
|
|
|
|
|no operation
|-
|48/0x30
|DBG
|'''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
|(debug only) print gool fixed point values
|-
|49/0x31
|RET
|'''00110001'''100001100100000000000000
|
|R,I
|
|
|
|
|conditionally stop gool execution (R and I ignored)
|-
|50/0x32
|BRA
|'''00110010'''0000100101VVVVIIIIIIIIII
|
|R,V,I
|
|
|
|
|branch
|-
|51/0x33
|BNEZ
|'''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
|R,V,I
|
|
|
|
|branch not equal zero
|-
|52/0x34
|BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
|R,V,I
|
|
|
|
|branch equal zero
|-
|53/0x35
|CST
|'''00110101'''0100100101AAAASSSSSSSSSS
|
|R,A,S
|
|
|
|
|change object state
|-
|54/0x36
|CNEZ
|'''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
|R,A,S
|
|
|
|
|change state if not zero
|-
|55/0x37
|CEQZ
|'''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
|R,A,S
|
|
|
|
|change state if zero
|-
|56/0x38
|ANIM
|'''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
|F,S,T,H
|
|
|W
|
|set and play animation+frame
|-
|57/0x39
|ANIF
|'''00111001'''HHTTTTTT0000FFFFFFFFFFFF
|F
|H,T
|
|
|W
|
|set and play frame of animation
|-
|58/0x3A
|VECA
|'''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
|V
|C,T,B,A
|
|
|*
|**
|multi-purpose vector calcs
|-
|59/0x3B
|JAL
|'''00111011'''VVVV00000EIIIIIIIIIIIIII
|
|I,V
|
|
|
|
|jump and link
|-
|60/0x3C
|EVNT
|'''00111100'''LLLAAARRRRRREEEEEEEEEEEE
|E
|L,A,R
|
|
|
|
|send an event
|-
|61/0x3D
|EVHR
|'''00111101'''TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|event handler: reject event
|-
|62/0x3E
|EVHA
|'''00111110'''TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|event handler: accept event
|-
|63/0x3F
|CHLD
|'''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
|C,T,S,A
|[C],
arg[0 to A]
|
|
|
|spawn children objects
|-
|64/0x40
|NTRY
|'''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
|T,E
|
|
|
|
|
|multi-purpose page operation
|-
|65/0x41
|SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
|A,V
|
|
|
|
|
|play sound effect
|-
|66/0x42
|SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
|S
|V,F,R
|
|
|
|
|adjust voice parameters
|-
|67/0x43
|VECB
|'''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
|V
|C,T,B,A
|
|
|
|
|multi-purpose vector calcs
|-
|68/0x44
|EVNB
|'''01000101'''LLLAAARRRRRREEEEEEEEEEEE
|E
|L,A,R
|
|
|
|
|send an event to all objects
|-
|69/0x45
|EVNC
|'''01000100'''LLLAAARRRRRREEEEEEEEEEEE
|E
|L,A,R
|
|
|
|
|send an event, cascading
|-
|70/0x46
|CHLF
|'''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
|A,T,S,C
|[C],
arg[0 to A]
|
|
|
|spawn children objects; forcefully?
|-
|71/0x47
|JALR
|'''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
|P,A
|
|arg[0 to A]
|
|
|
|jump and link to instruction pointed at by P
|-
|72/0x48
|CMSG
|'''01001000'''AAAAAAAAAAAAMMMMMMMMMMMM
|M,A
|
|
|AddCamMessage(M, &A)
|
|
|add message to camera queue (if not full), cam-message is M, its operands (dependant on message) are pointed to by A
|-
|73/0x49
|NATIVE
|'''01001001'''101111100000101111100000
|
|
|
|
|
|
|begin native (psx mips) code
|-
|74/0x4A
|?
|'''01001010'''------------AAAAAAAAAAAA
|A
|
|
|
|O
|
|unknown VIDO operation
|-
|75/0x4B
|?
|'''01001011'''------------AAAAAAAAAAAA
|A
|
|
|
|
|
|unknown
|-
|76/0x4C
|?
|'''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|
|
|
|
|unknown
|-
|77/0x4D
|?
|'''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|P,T
|
|
|
|unknown
|-
|78/0x4E
|ARRS
|'''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|S
|*(L + R) = S
L[R] = S
|
|
|store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

GOOL Interpreter

2020-06-30T09:16:48Z

Mddass: /* Main Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
|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
|LOOP
|00010011AAAAAAAAAAAABBBBBBBBBBBB
|(A),B
|R = 0x100
|[R,A]
|B = A >= 0 ? B + R : B - R
if (B > A && A > 0) B = -A + R*2
else if (B < A && A < 0) B = -A - R*2
P = A >= 0 ? abs(B) : -abs(B)
|P
|B
|loop around zero

|-
|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
|PUSH
|00010110AAAAAAAAAAAABBBBBBBBBBBB
|[A,[B]]
|
|
|[arg_buf = A]
I = A; J = B;
|[I,[J]]
|
|push value to stack

|-
|23/0x17
|NOTB
|00010111SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|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*grav) >> 10)
|S
|
|calculate speed

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

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

|-
|30/0x1E
|TICK
|00011110DDDDDDDDDDDDPPPPPPPPPPPP
|M,P
|
|
|O = (M + frameCount) % P
|O
|
|get game time

|-
|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
|DEGD
|00100001RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = degdist(L,R)
|
|
|angle between

|-
|34/0x22
|SEEK
|00100010RRRRRRRRRRRRLLLLLLLLLLLL
|L,(R)
|S = 0x100
|[R,S]
|O = seek(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
|00100100000IIIIIILLLCCCCCCCCCCCC
|C
|I,L
|
|obj.link[L].colors[I] = C
|
|
|color vector or matrix write

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

|-
|38/0x26
|PSHP
|00100110AAAAAAAAAAAABBBBBBBBBBBB
|[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
|ANIM
|10000011HHTTTTTTSSSSSSSSSFFFFFFF
|
|F,S,T,H
|
|
|W
|
|play animation at specified frame

|-
|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
|EVHR
|10001001TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|reject event

|-
|137/0x89
|EVHA
|10001000TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|<br>
|
|accept event
|-
|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
|SNDP
|10001100AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|
|
|
|
|play audio file at volume

|-
|141/0x8D
|SNDB
|10001101FFFFRRRRRRSSSSSSSSSSSSSS
|S
|F,R
|
|
|
|
|adjust voice parameters
|-
|142/0x8E
|VECB
|10001110CCCTTTBBBAAAVVVVVVVVVVVV
|V
|T,A,B,C
|
|
|
|<br>
|multi-purpose vector calcs

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

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

|-
|145/0x91
|CHLF
|10100000AAAATTTTTTTTSSSSSSCCCCCC
|
|C,T,S,A
|[C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
| NSEK
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
| R = 0x100
| [R,A]
| varies
| P
| B
| fast approximate seek
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000100101VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100100101AAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 69/0x45
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| CMSG
| '''01001000'''AAAAAAAAAAAAMMMMMMMMMMMM
| M,A
|
|
| AddCamMessage(M, &A)
|
|
| add message to camera queue (if not full), cam-message is M, its operands (dependant on message) are pointed to by A
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

GOOL Interpreter

2020-06-30T09:16:02Z

Mddass: /* Main Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
|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
|LOOP
|00010011AAAAAAAAAAAABBBBBBBBBBBB
|(A),B
|R = 0x100
|[R,A]
|B = A >= 0 ? B + R : B - R
if (B > A && A > 0) B = -A + R*2
else if (B < A && A < 0) B = -A - R*2
P = A >= 0 ? abs(P) : -abs(P)
|P
|B
|loop around zero

|-
|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
|PUSH
|00010110AAAAAAAAAAAABBBBBBBBBBBB
|[A,[B]]
|
|
|[arg_buf = A]
I = A; J = B;
|[I,[J]]
|
|push value to stack

|-
|23/0x17
|NOTB
|00010111SSSSSSSSSSSSDDDDDDDDDDDD
|S
|
|
|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*grav) >> 10)
|S
|
|calculate speed

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

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

|-
|30/0x1E
|TICK
|00011110DDDDDDDDDDDDPPPPPPPPPPPP
|M,P
|
|
|O = (M + frameCount) % P
|O
|
|get game time

|-
|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
|DEGD
|00100001RRRRRRRRRRRRLLLLLLLLLLLL
|L,R
|
|
|O = degdist(L,R)
|
|
|angle between

|-
|34/0x22
|SEEK
|00100010RRRRRRRRRRRRLLLLLLLLLLLL
|L,(R)
|S = 0x100
|[R,S]
|O = seek(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
|00100100000IIIIIILLLCCCCCCCCCCCC
|C
|I,L
|
|obj.link[L].colors[I] = C
|
|
|color vector or matrix write

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

|-
|38/0x26
|PSHP
|00100110AAAAAAAAAAAABBBBBBBBBBBB
|[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
|ANIM
|10000011HHTTTTTTSSSSSSSSSFFFFFFF
|
|F,S,T,H
|
|
|W
|
|play animation at specified frame

|-
|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
|EVHR
|10001001TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|
|
|reject event

|-
|137/0x89
|EVHA
|10001000TTCCRRRRRR**************
|
|R,C,T,*
|**
|
|<br>
|
|accept event
|-
|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
|SNDP
|10001100AAAAAAAAAAAABBBBBBBBBBBB
|A,B
|
|
|
|
|
|play audio file at volume

|-
|141/0x8D
|SNDB
|10001101FFFFRRRRRRSSSSSSSSSSSSSS
|S
|F,R
|
|
|
|
|adjust voice parameters
|-
|142/0x8E
|VECB
|10001110CCCTTTBBBAAAVVVVVVVVVVVV
|V
|T,A,B,C
|
|
|
|<br>
|multi-purpose vector calcs

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

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

|-
|145/0x91
|CHLF
|10100000AAAATTTTTTTTSSSSSSCCCCCC
|
|C,T,S,A
|[C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
| NSEK
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
| R = 0x100
| [R,A]
| varies
| P
| B
| fast approximate seek
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000100101VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100100101AAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 69/0x45
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| CMSG
| '''01001000'''AAAAAAAAAAAAMMMMMMMMMMMM
| M,A
|
|
| AddCamMessage(M, &A)
|
|
| add message to camera queue (if not full), cam-message is M, its operands (dependant on message) are pointed to by A
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

GOOL Interpreter

2020-06-28T20:00:12Z

Mddass: /* GOOLv2 Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
| 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
| S
|
|
| 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
| 00100100000IIIIIILLLCCCCCCCCCCCC
| 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
| 00100110AAAAAAAAAAAABBBBBBBBBBBB
| [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
| RSTF
| 10001001TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
|state return guard = false variant

|-
|137/0x89
| RSTT
| 10001000TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|<br>
|
|state return guard = true 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
| 10001101VVVVRRRRRRSSSSSSSSSSSSSS
| S
| V,R
|
|
|
|<br>
|play sound<br>effect

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

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

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

|-
|145/0x91
| CHLF
| 10100000AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
| [C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
| NSEK
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
| R = 0x100
| [R,A]
| varies
| P
| B
| fast approximate seek
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000100101VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100100101AAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 69/0x45
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| ?
| '''01001000'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

Level ID

2020-06-15T22:02:14Z

Mddass: /* Crash 1 */ ocd

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<u>'''13'''</u>.NSD</code> and <code>S00000<u>'''13'''</u>.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>
| [[Lava Cave Level]]
|-
| <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]]
|-
| <code>2B</code>
| <code>H</code>
| (none)
|}

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. Level <code>H</code> (2B) is non-existent and is placed before "Fumbling in the Dark" in the map. 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.

Object

2020-05-09T20:46:03Z

Mddass: /* Free and Existing Objects */

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
|Diffuse Color LR1
|2 bytes
|*
|-
|0x4A
|Diffuse Color LG1
|2 bytes
|*
|-
|0x4C
|Diffuse Color LB1
|2 bytes
|*
|-
|0x4E
|Diffuse Color LR2
|2 bytes
|*
|-
|0x50
|Diffuse Color LG2
|2 bytes
|*
|-
|0x52
|Diffuse Color LB2
|2 bytes
|*
|-
|0x54
|Diffuse Color LR3
|2 bytes
|*
|-
|0x56
|Diffuse Color LG3
|2 bytes
|*
|-
|0x58
|Diffuse Color LB3
|2 bytes
|*
|-
|0x5A
|Ambient Color R
|2 bytes
|*
|-
|0x5C
|Ambient Color G
|2 bytes
|*
|-
|0x5E
|Ambient Color 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
|*
|}

=== Crash 2 ===
All objects in Crash 2, with the exception of the player object, are 572 (0x23C) bytes in size. The player object, 828 (0x33C) 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
|Current Animation Entry
|4 bytes
|*
|-
|0xC
|Source GOOL Executable
|4 bytes
|*
|-
|0x10
|Main GOOL Executable
|4 bytes
|*
|-
|0x14
|External GOOL Executable
|4 bytes
|*
|-
|0x18
|Parent Zone
|4 bytes
|*
|-
|0x1C
|State
|4 bytes
|*
|-
|0x20
|Color Modifier 1
|2 bytes
|*
|-
|0x22
|Color Modifier 2
|2 bytes
|*
|-
|0x24
|Color Modifier 3
|2 bytes
|*
|-
|0x26
|Color Modifier 4
|2 bytes
|*
|-
|0x28
|Color Matrix LR1
|2 bytes
|*
|-
|0x2A
|Color Matrix LG1
|2 bytes
|*
|-
|0x2C
|Color Matrix LB1
|2 bytes
|*
|-
|0x2E
|Color Matrix LR2
|2 bytes
|*
|-
|0x30
|Color Matrix LG2
|2 bytes
|*
|-
|0x32
|Color Matrix LB2
|2 bytes
|*
|-
|0x34
|Color Matrix LR3
|2 bytes
|*
|-
|0x36
|Color Matrix LG3
|2 bytes
|*
|-
|0x38
|Color Matrix LB3
|2 bytes
|*
|-
|0x3A
|Color Vector AR
|2 bytes
|*
|-
|0x3C
|Color Vector AG
|2 bytes
|*
|-
|0x3E
|Color Vector AB
|2 bytes
|*
|-
|0x40
|Self Link
|4 bytes
|this
|-
|0x44
|Parent
|4 bytes
|*
|-
|0x48
|Sibling
|4 bytes
|*
|-
|0x4C
|Children (head child)
|4 bytes
|*
|-
|0x50
|Creator
|4 bytes
|*
|-
|0x54
|Player
|4 bytes
|*
|-
|0x58
|Collider
|4 bytes
|*
|-
|0x5C
|Interrupter
|4 bytes
|*
|-
|0x60
|Trans X
|4 bytes
|*
|-
|0x64
|Trans Y
|4 bytes
|*
|-
|0x68
|Trans Z
|4 bytes
|*
|-
|0x6C
|Rotation X
|4 bytes
|*
|-
|0x70
|Rotation Y
|4 bytes
|*
|-
|0x74
|Rotation Z
|4 bytes
|*
|-
|0x78
|Scale X
|4 bytes
|*
|-
|0x7C
|Scale Y
|4 bytes
|*
|-
|0x80
|Scale Z
|4 bytes
|*
|-
|0x84
|Velocity X
|4 bytes
|*
|-
|0x88
|Velocity Y
|4 bytes
|*
|-
|0x8C
|Velocity Z
|4 bytes
|*
|-
|0x90
|Target Rotation X
|4 bytes
|*
|-
|0x94
|Target Rotation Y
|4 bytes
|*
|-
|0x98
|Target Rotation Z
|4 bytes
|*
|-
|0x9C
|Multi-Purpose Vector X
|4 bytes
|*
|-
|0xA0
|Multi-Purpose Vector Y
|4 bytes
|*
|-
|0xA4
|Multi-Purpose Vector Z
|4 bytes
|*
|-
|0xA8
|Status Flags A
|4 bytes
|*
|-
|0xAC
|Status Flags B
|4 bytes
|*
|-
|0xB0
|Status Flags C
|4 bytes
|*
|-
|0xB4
|Subtype/Initial State
|4 bytes
|*
|-
|0xB8
|ID
|4 bytes
|*
|-
|0xBC
|Stack Pointer
|4 bytes
|*
|-
|0xC0
|Program Counter (ins. pointer)
|4 bytes
|*
|-
|0xC4
|Frame Pointer
|4 bytes
|*
|-
|0xC8
|Trans Block Program Counter
|4 bytes
|*
|-
|0xCC
|Event Block Program Counter
|4 bytes
|*
|-
|0xD0
|Head Block Program Counter
|4 bytes
|*
|-
|0xD4
|Various
|4 bytes
|*
|-
|0xD8
|Unknown
|4 bytes
|*
|-
|0xDC
|Frame Change Timestamp
|4 bytes
|*
|-
|0xE0
|State Change Timestamp
|4 bytes
|*
|-
|0xE4
|Animation Lag Counter
|4 bytes
|*
|-
|0xE8
|Animation Sequence
|4 bytes
|*
|-
|0xEC
|Animation Frame
|4 bytes
|*
|-
|0xF0
|Entity Spawned From
|4 bytes
|*
|-
|0xF4
|Path Progress
|4 bytes
|*
|-
|0xF8
|Path Length (point count)
|4 bytes
|*
|-
|0xFC
|Ground y
|4 bytes
|*
|-
|0x100
|State Flags
|4 bytes
|*
|-
|0x104
|Speed
|4 bytes
|*
|-
|0x108
|Display Mode
|4 bytes
|*
|-
|0x10C
|Unknown
|4 bytes
|*
|-
|0x110
|Timestamp of Most Recent Landing
|4 bytes
|*
|-
|0x114
|Velocity y at Most Recent Landing
|4 bytes
|*
|-
|0x118
|Z-Index
|4 bytes
|*
|-
|0x11C
|Event Received
|4 bytes
|*
|-
|0x120
|Camera Zoom Factor
|4 bytes
|*
|-
|0x124
|Target Rotation Angle YZ plane
|4 bytes
|*
|-
|0x128
|Collision Hot-Spot Clip Amount
|4 bytes
|*
|-
|0x12C
|Unknown
|4 bytes
|*
|-
|0x130
|Unknown
|4 bytes
|*
|-
|0x134
|Unknown
|4 bytes
|*
|-
|0x138
|Collision Node
|4 bytes
|*
|-
|0x13C
|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<br />0x1
| object has been stopped by solid ground
|<br>

|-
|2<br />0x2
| ?
|<br>

|-
|3<br />0x4
|0 = object is progressing forward along its path

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

|-
|4<br />0x8
|0 = object was rotating counter-clockwise

1 = object was rotating clockwise
|rotating objects only

|-
|5<br />0x10
| object is transitioning from travelling forward to backward/vice versa along its path
|path travelling objects only

|-
|6<br />0x20
| object has changed animation [i.e. first frame of animation]
|state change also assumes change in animation by setting this

|-
|7<br />0x40
|?
|<br>

|-
|8<br />0x80
| object has been hit from the bottom
| set when collision check does not pass?

|-
|9<br />0x100
| object is moving and not stopped by a wall
|<br>

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

|-
|11<br />0x400
| set when colliding with an octree node and it triggers event
|<br>

|-
|12<br />0x800
| cleared when spinning or changing direction, reset by sub_243A0
|<br>

|-
|13<br />0x1000
| 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<br />0x2000
| object is hitting a bounce box (for setting a higher acceleration)
|<br>

|-
|15<br />0x4000
| collider is crash
|

|-
|16<br />0x8000
| object's bounding box needs recalculating
|<br>

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

|-
|18<br />0x20000
| object has changed state
|<br>

|-
|19<br />0x40000
| object is on the ground
|<br>

|-
|20<br />0x80000
| ?
|boxes set this at the end of their init routine

|-
|21<br />0x100000
| set right after bounce from box/enemy?
|<br>

|-
|22<br />0x200000
| object is a solid object (or supported by a solid object?)
|

|-
|23 to 32
| ?
|<br>

|}

=== 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<br />0x1
| object rotates in XZ plane based on target rot angle (cleared during spin?)
|

|-
|2<br />0x2
| 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<br />0x4
| 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<br />0x8
| 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<br />0x10
| object is collide-able (records space occupied by object and pointer to object in a pair during this frame)
|

|-
|6<br />0x20
| object y velocity is affected by gravity
|

|-
|7<br />0x40
| 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<br />0x80
| object [speed, velocity, and angular velocity] is controlled with the controller
|

|-
|9<br />0x100
| object does not render
|ex. HUD offscreen, dying in water

|-
|10<br />0x200
| object is 2 dimensional
|

|-
|11<br />0x400
| text object has a backdrop
|

|-
|12<br />0x800
| object auto banks along path curves
|path traveling objects only

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

|-
|14<br />0x2000
| object rotates in YZ plane to approach its target rot angle
|

|-
|15<br />0x4000
| object treats XZ plane at Y given by field groundy as solid ground
|

|-
|16<br />0x8000
| 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<br />0x10000
| object is solid at the sides
|

|-
|18<br />0x20000
| object is solid at the top?
|

|-
|19<br />0x40000
| disable frustum culling?
|

|-
|20<br />0x80000
| object optionally rotates in XZ plane to approach its target rot angle
|

|-
|21<br />0x100000
| object is shaded based on its parent zone, using the zone's color matrices
|

|-
|22<br />0x200000
|?
|

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

|-
| 24<br />0x800000
|?
|

|-
|25<br />0x1000000
| object can not be terminated
|

|-
|26<br />0x2000000
| always display and animate object
|

|-
|27<br />0x4000000
|?
|

|-
|28<br />0x8000000
|?
|

|-
|29<br />0x10000000
| 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<br />0x20000000
|?
|

|-
|31<br />0x40000000
|
|

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

|}

Object

2020-04-20T16:49:34Z

Mddass: /* Free and Existing Objects */ Fix color fields-

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
|Diffuse Color LR1
|2 bytes
|*
|-
|0x4A
|Diffuse Color LG1
|2 bytes
|*
|-
|0x4C
|Diffuse Color LB1
|2 bytes
|*
|-
|0x4E
|Diffuse Color LR2
|2 bytes
|*
|-
|0x50
|Diffuse Color LG2
|2 bytes
|*
|-
|0x52
|Diffuse Color LB2
|2 bytes
|*
|-
|0x54
|Diffuse Color LR3
|2 bytes
|*
|-
|0x56
|Diffuse Color LG3
|2 bytes
|*
|-
|0x58
|Diffuse Color LB3
|2 bytes
|*
|-
|0x5A
|Ambient Color R
|2 bytes
|*
|-
|0x5C
|Ambient Color G
|2 bytes
|*
|-
|0x5E
|Ambient Color 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
|*
|}

=== Crash 2 ===
All objects in Crash 2, with the exception of the player object, are 572 (0x23C) bytes in size. The player object, 828 (0x33C) 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
|Current Animation Entry
|4 bytes
|*
|-
|0xC
|Source GOOL Executable
|4 bytes
|*
|-
|0x10
|Main GOOL Executable
|4 bytes
|*
|-
|0x14
|External GOOL Executable
|4 bytes
|*
|-
|0x18
|Parent Zone
|4 bytes
|*
|-
|0x1C
|State
|4 bytes
|*
|-
|0x20
|Color Modifier 1
|2 bytes
|*
|-
|0x22
|Color Modifier 2
|2 bytes
|*
|-
|0x24
|Color Modifier 3
|2 bytes
|*
|-
|0x26
|Color Modifier 4
|2 bytes
|*
|-
|0x28
|Color Matrix LR1
|2 bytes
|*
|-
|0x2A
|Color Matrix LG1
|2 bytes
|*
|-
|0x2C
|Color Matrix LB1
|2 bytes
|*
|-
|0x2E
|Color Matrix LR2
|2 bytes
|*
|-
|0x30
|Color Matrix LG2
|2 bytes
|*
|-
|0x32
|Color Matrix LB2
|2 bytes
|*
|-
|0x34
|Color Matrix LR3
|2 bytes
|*
|-
|0x36
|Color Matrix LG3
|2 bytes
|*
|-
|0x38
|Color Matrix LB3
|2 bytes
|*
|-
|0x3A
|Color Vector AR
|2 bytes
|*
|-
|0x3C
|Color Vector AG
|2 bytes
|*
|-
|0x3E
|Color Vector AB
|2 bytes
|*
|-
|0x40
|Self Link
|4 bytes
|this
|-
|0x44
|Parent
|4 bytes
|*
|-
|0x48
|Sibling
|4 bytes
|*
|-
|0x4C
|Children (head child)
|4 bytes
|*
|-
|0x50
|Creator
|4 bytes
|*
|-
|0x54
|Player
|4 bytes
|*
|-
|0x58
|Collider
|4 bytes
|*
|-
|0x5C
|Interrupter
|4 bytes
|*
|-
|0x60
|Trans x
|4 bytes
|*
|-
|0x64
|Trans y
|4 bytes
|*
|-
|0x68
|Trans z
|4 bytes
|*
|-
|0x6C
|Rotation y
|4 bytes
|*
|-
|0x70
|Rotation x
|4 bytes
|*
|-
|0x74
|Rotation z
|4 bytes
|*
|-
|0x78
|Scale x
|4 bytes
|*
|-
|0x7C
|Scale y
|4 bytes
|*
|-
|0x80
|Scale z
|4 bytes
|*
|-
|0x84
|Velocity x
|4 bytes
|*
|-
|0x88
|Velocity y
|4 bytes
|*
|-
|0x8C
|Velocity z
|4 bytes
|*
|-
|0x90
|Target Rotation y
|4 bytes
|*
|-
|0x94
|Target Rotation x
|4 bytes
|*
|-
|0x98
|Target Rotation z
|4 bytes
|*
|-
|0x9C
|Multi-Purpose Vector X
|4 bytes
|*
|-
|0xA0
|Multi-Purpose Vector Y
|4 bytes
|*
|-
|0xA4
|Multi-Purpose Vector Z
|4 bytes
|*
|-
|0xA8
|Status Flags A
|4 bytes
|*
|-
|0xAC
|Status Flags B
|4 bytes
|*
|-
|0xB0
|Status Flags C
|4 bytes
|*
|-
|0xB4
|Subtype/Initial State
|4 bytes
|*
|-
|0xB8
|ID
|4 bytes
|*
|-
|0xBC
|Stack Pointer
|4 bytes
|*
|-
|0xC0
|Program Counter (ins. pointer)
|4 bytes
|*
|-
|0xC4
|Frame Pointer
|4 bytes
|*
|-
|0xC8
|Trans Block Program Counter
|4 bytes
|*
|-
|0xCC
|Event Block Program Counter
|4 bytes
|*
|-
|0xD0
|Head Block Program Counter
|4 bytes
|*
|-
|0xD4
|Various
|4 bytes
|*
|-
|0xD8
|Unknown
|4 bytes
|*
|-
|0xDC
|Frame Change Timestamp
|4 bytes
|*
|-
|0xE0
|State Change Timestamp
|4 bytes
|*
|-
|0xE4
|Animation Lag Counter
|4 bytes
|*
|-
|0xE8
|Animation Sequence
|4 bytes
|*
|-
|0xEC
|Animation Frame
|4 bytes
|*
|-
|0xF0
|Entity Spawned From
|4 bytes
|*
|-
|0xF4
|Path Progress
|4 bytes
|*
|-
|0xF8
|Path Length (point count)
|4 bytes
|*
|-
|0xFC
|Ground y
|4 bytes
|*
|-
|0x100
|State Flags
|4 bytes
|*
|-
|0x104
|Speed
|4 bytes
|*
|-
|0x108
|Display Mode
|4 bytes
|*
|-
|0x10C
|Unknown
|4 bytes
|*
|-
|0x110
|Timestamp of Most Recent Landing
|4 bytes
|*
|-
|0x114
|Velocity y at Most Recent Landing
|4 bytes
|*
|-
|0x118
|Z-Index
|4 bytes
|*
|-
|0x11C
|Event Received
|4 bytes
|*
|-
|0x120
|Camera Zoom Factor
|4 bytes
|*
|-
|0x124
|Target Rotation Angle YZ plane
|4 bytes
|*
|-
|0x128
|Collision Hot-Spot Clip Amount
|4 bytes
|*
|-
|0x12C
|Unknown
|4 bytes
|*
|-
|0x130
|Unknown
|4 bytes
|*
|-
|0x134
|Unknown
|4 bytes
|*
|-
|0x138
|Collision Node
|4 bytes
|*
|-
|0x13C
|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<br />0x1
| object has been stopped by solid ground
|<br>

|-
|2<br />0x2
| ?
|<br>

|-
|3<br />0x4
|0 = object is progressing forward along its path

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

|-
|4<br />0x8
|0 = object was rotating counter-clockwise

1 = object was rotating clockwise
|rotating objects only

|-
|5<br />0x10
| object is transitioning from travelling forward to backward/vice versa along its path
|path travelling objects only

|-
|6<br />0x20
| object has changed animation [i.e. first frame of animation]
|state change also assumes change in animation by setting this

|-
|7<br />0x40
|?
|<br>

|-
|8<br />0x80
| object has been hit from the bottom
| set when collision check does not pass?

|-
|9<br />0x100
| object is moving and not stopped by a wall
|<br>

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

|-
|11<br />0x400
| set when colliding with an octree node and it triggers event
|<br>

|-
|12<br />0x800
| cleared when spinning or changing direction, reset by sub_243A0
|<br>

|-
|13<br />0x1000
| 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<br />0x2000
| object is hitting a bounce box (for setting a higher acceleration)
|<br>

|-
|15<br />0x4000
| collider is crash
|

|-
|16<br />0x8000
| object's bounding box needs recalculating
|<br>

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

|-
|18<br />0x20000
| object has changed state
|<br>

|-
|19<br />0x40000
| object is on the ground
|<br>

|-
|20<br />0x80000
| ?
|boxes set this at the end of their init routine

|-
|21<br />0x100000
| set right after bounce from box/enemy?
|<br>

|-
|22<br />0x200000
| object is a solid object (or supported by a solid object?)
|

|-
|23 to 32
| ?
|<br>

|}

=== 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<br />0x1
| object rotates in XZ plane based on target rot angle (cleared during spin?)
|

|-
|2<br />0x2
| 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<br />0x4
| 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<br />0x8
| 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<br />0x10
| object is collide-able (records space occupied by object and pointer to object in a pair during this frame)
|

|-
|6<br />0x20
| object y velocity is affected by gravity
|

|-
|7<br />0x40
| 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<br />0x80
| object [speed, velocity, and angular velocity] is controlled with the controller
|

|-
|9<br />0x100
| object does not render
|ex. HUD offscreen, dying in water

|-
|10<br />0x200
| object is 2 dimensional
|

|-
|11<br />0x400
| text object has a backdrop
|

|-
|12<br />0x800
| object auto banks along path curves
|path traveling objects only

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

|-
|14<br />0x2000
| object rotates in YZ plane to approach its target rot angle
|

|-
|15<br />0x4000
| object treats XZ plane at Y given by field groundy as solid ground
|

|-
|16<br />0x8000
| 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<br />0x10000
| object is solid at the sides
|

|-
|18<br />0x20000
| object is solid at the top?
|

|-
|19<br />0x40000
| disable frustum culling?
|

|-
|20<br />0x80000
| object optionally rotates in XZ plane to approach its target rot angle
|

|-
|21<br />0x100000
| object is shaded based on its parent zone, using the zone's color matrices
|

|-
|22<br />0x200000
|?
|

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

|-
| 24<br />0x800000
|?
|

|-
|25<br />0x1000000
| object can not be terminated
|

|-
|26<br />0x2000000
| always display and animate object
|

|-
|27<br />0x4000000
|?
|

|-
|28<br />0x8000000
|?
|

|-
|29<br />0x10000000
| 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<br />0x20000000
|?
|

|-
|31<br />0x40000000
|
|

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

|}

GOOL Interpreter

2020-04-18T21:18:50Z

Mddass: /* GOOLv2 Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
| 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
| S
|
|
| 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
| 00100100000IIIIIILLLCCCCCCCCCCCC
| 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
| 00100110AAAAAAAAAAAABBBBBBBBBBBB
| [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
| RSTF
| 10001001TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
|state return guard = false variant

|-
|137/0x89
| RSTT
| 10001000TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|<br>
|
|state return guard = true 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
| 10001101VVVVRRRRRRSSSSSSSSSSSSSS
| S
| V,R
|
|
|
|<br>
|play sound<br>effect

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

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

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

|-
|145/0x91
| CHLF
| 10100000AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
| [C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
| NSEK
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
| R = 0x100
| [R,A]
| varies
| P
| B
| fast approximate seek
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000100101VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100100101AAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| R
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 69/0x45
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| ?
| '''01001000'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

GOOL Interpreter

2020-04-16T04:04:48Z

Mddass: /* GOOLv2 Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
| 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
| S
|
|
| 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
| 00100100000IIIIIILLLCCCCCCCCCCCC
| 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
| 00100110AAAAAAAAAAAABBBBBBBBBBBB
| [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
| RSTF
| 10001001TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
|state return guard = false variant

|-
|137/0x89
| RSTT
| 10001000TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|<br>
|
|state return guard = true 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
| 10001101VVVVRRRRRRSSSSSSSSSSSSSS
| S
| V,R
|
|
|
|<br>
|play sound<br>effect

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

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

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

|-
|145/0x91
| CHLF
| 10100000AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
| [C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
| NSEK
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
| R = 0x100
| [R,A]
| varies
| P
| B
| fast approximate seek
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000000000VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| R
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 69/0x45
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| ?
| '''01001000'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

Entity

2020-04-14T22:57:53Z

Mddass: /* Type */

:''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
|Parent Zone Pointer (reserved)
|4 bytes
|*
|-
|0x8
|Parent Entity Pointer (reserved)
|4 bytes
|*
|-
|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
|Group count
|2 bytes
|rc
|-
!colspan="4"|''Field Data Structure''
|-
|0x0
|Element count
|2 bytes * rc
|ec
|-
|0x0 + rc * 2
|Metavalues (not present if flag 32 not set)
|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?
|-
|0x29
|Camera Mode
|Determines the behavior of the camera trail - similar to ''Crash 1'' camera mode
|UInt8 (''Crash 2'')<br />Int32 (''Crash 3'')
|No
|-
|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
|-
|0x32
|Depth modifier
|Modifier optionally applied to the object, usually to correct bad automatic depth sorting (i.e. force objects to appear behind certain scenery)
|Int32
|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, and other miscellaneous behavior
|Int32'''<sup>1</sup>'''
|No
|-
|0xA4
|Arguments
|List of values that affect an object's behavior (i.e. flags, timings, speed, etc.). These are the arguments pushed to GOOL stack before the object's appropriate spawn code runs.
|Int32
|No
|-
|0xA9
|Type
|Type of the entity (index of GOOL entry in GOOL entry list in the [[NSD]])
|Int32
|No
|-
|0xAA
|Subtype
|Variant of the entity - used as an index to the subtype table when spawning the object
|Int32
|No
|-
|0xC9
|Camera movement unit
|Specifies the amount of "distance" between two camera points. This "distance" translates to a multiplication of the direction vector for Crash-linked camera modes, is not necessary on automatic trails
|Int32
|No
|-
|0x103
|SLST EID
|EID of the SLST [[entry]] to be used by this camera trail
|Int32
|No
|-
|0x109
|Neighbor camera trails
|Contains information about neighboring camera trails. If one position contains multiple trails, special collision nodes may determine which to use. Trail settings are same as ''Crash 1'', in reverse order.
|Int32
|Yes
|-
|0x118
|Misc Settings 1
|???
|Int32
|No
|-
|0x130
|Field-of-View timeline
|Determines the field of view. A value of 288 is the "normal" field of view. The end result is interpolated between the "keyframes" of this property. It is unknown if multiple FOV values can be used on the same position.
|Int32
|Yes
|-
|0x13B
|Draw List A
|List of values that determine which entities should despawn while the camera is in this zone - includes zone index and entity index'''<sup>2</sup>'''
|Int32
|Yes
|-
|0x13C
|Draw List B
|List of values that determine which entities should spawn while the camera is in this zone - includes zone index and entity index'''<sup>2</sup>'''
|Int32
|Yes
|-
|0x173
|Camera index
|Specifies the index of this entity within the zone's list of cameras
|Int32
|No
|-
|0x174
|Camera sub-index
|Specifies the index of this entity within the camera's list of entities (i.e. values should be 0, 1 or 2)
|Int32
|No
|-
|0x208
|Load List A
|List of EIDs to load when the camera is in this zone'''<sup>2</sup>'''
|Int32
|Yes
|-
|0x209
|Load List B
|List of EIDs to deload when the camera is in this zone'''<sup>2</sup>'''
|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
|Victims
|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;<br>Only used by obj_willy
|Int32
|No
|-
|0x2A0
|Parent box ID
|Parent box ID, passed to spawned fruit from a box
|Int32
|No
|-
|0x30E
|Scale modifier
|Indicates the scale of the object. ''Crash 3''-only;<br/>0 = Position/4 in-game; 1 = Position/2 in-game; 2 = Normal; 3 = Position*2 in-game; etc.
|Int32
|No
|-
|0x336
|Time Trial reward
|Affects what the crate will reward (and consequentially turn into) during time trial mode. ''Crash 3''-only
|Int32
|No
|-
|0x337
|Bonus box count
|Number of boxes in the level's bonus;<br>Only used by obj_willy. ''Crash 3''-only
|Int32
|No
|}
'''<sup>1</sup>''' Should fall within Int16 boundaries, as it is the common type used for entity ID-related operations.

'''<sup>2</sup>''' The roles of these 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.

GOOL Interpreter

2020-04-12T23:21:29Z

Mddass: /* GOOLv2 Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
| 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
| S
|
|
| 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
| 00100100000IIIIIILLLCCCCCCCCCCCC
| 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
| 00100110AAAAAAAAAAAABBBBBBBBBBBB
| [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
| RSTF
| 10001001TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
|state return guard = false variant

|-
|137/0x89
| RSTT
| 10001000TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|<br>
|
|state return guard = true 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
| 10001101VVVVRRRRRRSSSSSSSSSSSSSS
| S
| V,R
|
|
|
|<br>
|play sound<br>effect

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

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

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

|-
|145/0x91
| CHLF
| 10100000AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
| [C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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/0x0
| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
| NSEK
| '''00010011'''AAAAAAAAAAAABBBBBBBBBBBB
| (A),B
| R = 0x100
| [R,A]
| varies
| P
| B
| fast approximate seek
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000000000VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| R
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 69/0x45
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| ?
| '''01001000'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD

GOOL Interpreter

2020-04-09T02:39:04Z

Mddass: /* GOOLv2 Instruction Table */

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, ANIF/ANIS, which change the object's current frame of animation, CST/CNEZ/CEQZ, which change the object's state, or EVNT/EVNB/EVNU, which send an event to one or multiple objects.)

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 <i>threads</i> 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 <i>field</i> 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 <i>trans</i> thread, an <i>event</i> thread, and a <i>head</i> 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 <i>code</i> 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 <i>replaced</i> 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 <i>code</i> thread.
[[File:Goolinterp1.png|thumb|236x236px]]
For the sake of explanation, <i>handles</i> blocks are viewed as being equivalent to <i>event</i> blocks, so <i>handles</i> 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 <i>restored</i> 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
|<br>
| 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
| S
|
|
| 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
| 00100100000IIIIIILLLCCCCCCCCCCCC
| 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
| 00100110AAAAAAAAAAAABBBBBBBBBBBB
| [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
| RSTF
| 10001001TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
|state return guard = false variant

|-
|137/0x89
| RSTT
| 10001000TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|<br>
|
|state return guard = true 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
| 10001101VVVVRRRRRRSSSSSSSSSSSSSS
| S
| V,R
|
|
|
|<br>
|play sound<br>effect

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

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

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

|-
|145/0x91
| CHLF
| 10100000AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
| [C],
arg[0 to A]
|
|
|<br>
|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>

=== Crash 2 ===
The GOOL Interpreter in Crash 2 recognizes a total of 79 GOOL instructions, including two duplicates. Many of the instructions are known. 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:11px;">
{| 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/0x0
| 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 = (R ? L : R)
| O
|
| logical and
|-
| 6/0x06
| ORL
| '''00000110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
|<nowiki>O = (L || R)</nowiki>
<nowiki>O = L | R</nowiki>
| O
|<br>
| logical or (same as ORB)
|-
| 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
|-
| 20/0x14
| LEA
| '''00010100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = &S
|
| D
| load effective address
|-
| 21/0x15
| SHA
| '''00010101'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = ((R < 0) ? (L >> -R)
<nowiki>:</nowiki> (L << R))
| O
|
| bit shift
|-
| 22/0x16
| PUSH
| '''00010110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
|
I = A; J = B;
| I,[J]
|
| push value(s) to stack
|-
| 23/0x17
| NOTB
| '''00010111'''SSSSSSSSSSSSDDDDDDDDDDDD
|
|
|
| D = ~S
|
| D
| bitwise not (nor)
|-
| 24/0x18
| MOVC
| '''00011000'''RRRRRR000EIIIIIIIIIIIIII
|
| R,E,I
|
| see docs
| O
|
| get code pointer
|-
| 25/0x19
| ABS
| '''00011001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = (S < 0) ? -S : S
|
| D
| absolute value
|-
| 26/0x1A
| PAD
| '''00011010'''000TDDDDSSPPBBBBBBBBBBBB
|
| B,P,S,D,T
|
| O = testctrls(instr,0)
| O
|
| test controller buttons
|-
| 27/0x1B
| SPD
| '''00011011'''VVVVVVVVVVVVBBBBBBBBBBBB
| V,B
|
|
| S = B + ((V*gvel) >> 10)
| S
|
| calculate speed
|-
| 28/0x1C
| MSC
| '''00011100'''PPPPSSSSSLLLXXXXXXXXXXXX
| X
| P,S,L
|
| various
|
|
| multi-purpose
|-
| 29/0x1D
| PSIN
| '''00011101'''PPPPPPPPPPPPDDDDDDDDDDDD
| P,D
|
|
| large calc; see docs
|
|
| driven sine wave
|-
| 30/0x1E
| TICK
| '''00011110'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = (R + TICKS) % L
| O
|
| get ticks
|-
| 31/0x1F
| RGL
| '''00011111'''101111100000IIIIIIIIIIII
| I
|
|
| O = globals[I]
| O
|
| read global variable
|-
| 32/0x20
| WGL
| '''00100000'''SSSSSSSSSSSSIIIIIIIIIIII
| I,S
|
|
| globals[I] = *S
|
|
| write global variable
|-
| 33/0x21
| ANGD
| '''00100001'''RRRRRRRRRRRRLLLLLLLLLLLL
| R,L
|
|
| O = ((R << 20) - (L << 20)) >> 20
| O
|
| angle distance (note: shifts are for sign extension)
|-
| 34/0x22
| APCH
| '''00100010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,(R)
|
|
| O = approach(L,R,S)
| O
|
| approach a value
|-
| 35/0x23
| CVMR
| '''00100011'''000IIIIIILLL000000000000
|
| I,L
|
| O = obj.link[L].colors[I]
| O
|
| color vector or matrix read
|-
| 36/0x24
| CVMW
| '''00100100'''000IIIIIILLLCCCCCCCCCCCC
| C
| I,L
|
| obj.link[L].colors[I] = C
|
|
| color vector or matrix write
|-
| 37/0x25
| ROT
| '''00100101'''RRRRRRRRRRRRLLLLLLLLLLLL
| (R),L
|
| [R,S]
| O = rotate(L,R,S,0)
|
|
| approach an angle
|-
| 38/0x26
| PSHP
| '''00100110'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,[B]
|
|
| I = &A; J = &B;
| I,[J]
|
| push pointer(s)
|-
| 39/0x27
| ANIS
| '''00100111'''FFFFFFFFFFFFDDDDDDDDDDDD
| F
|
|
| D=&obj.global.anim[F>>8]
|
| D
| set animation
|-
| 40/0x28
| EFLR
| '''00101000'''BBBBBBBBBBBBAAAAAAAAAAAA
| A,B
|
|
| O = GetFieldValue(obj->entity, field: A, row: B)
| O
|
| load entity field row data
|-
| 41/0x29
| EFLV
| '''00101001'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = GetFieldValue(obj->entity, field: S)
|
| D
| get entity field data
|-
| 42/0x2A
| ARRL
| '''00101010'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
|
| O = *(L + R)
o = L[R]
| O
|
| load array value
|-
| 43/0x2B
| SIN
| '''00101100'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = sin(S)
|
| D
| sine wave (output: -0x1000 to 0x1000)
|-
| 44/0x2C
| COS
| '''00101101'''SSSSSSSSSSSSDDDDDDDDDDDD
| S
|
|
| D = cos(S)
D = sin(S + PI/2)
|
| D
| cosine wave (output: -0x1000 to 0x1000)
|-
| 45/0x2D
| ATAN
| '''00101110'''YYYYYYYYYYYYXXXXXXXXXXXX
| X,Y
|
|
| o = atan2(X, Y)
| o
|
| arc-tangent2, angle to point (confirmation needed)
|-
| 46/0x2E
| ?
| '''00101110'''SSSSSSSSSSSSDDDDDDDDDDDD
| A
|
|
|
|
| D
| unknown
|-
| 47/0x2F
| NOP
| '''00101111'''101111100000101111100000
|
|
|
|
|
|
| no operation
|-
| 48/0x30
| DBG
| '''00110000'''BBBBBBBBBBBBAAAAAAAAAAAA
|
|
|
|
|
|
| (debug only) print gool fixed point values
|-
| 49/0x31
| RET
|'''00110001'''100001100100000000000000
|
| R,I
|
|
|
|
| conditionally stop gool execution (R and I ignored)
|-
| 50/0x32
| BRA
| '''00110010'''0000000000VVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch
|-
| 51/0x33
| BNEZ
| '''00110011'''0001RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch not equal zero
|-
| 52/0x34
| BEQZ
|'''00110100'''0010RRRRRRVVVVIIIIIIIIII
|
| R,V,I
|
|
|
|
| branch equal zero
|-
| 53/0x35
| CST
| '''00110101'''0100RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change object state
|-
| 54/0x36
| CNEZ
| '''00110110'''0101RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if not zero
|-
| 55/0x37
| CEQZ
| '''00110111'''0110RRRRRRAAAASSSSSSSSSS
|
| R,A,S
|
|
|
|
| change state if zero
|-
| 56/0x38
| ANIM
| '''00111000'''HHTTTTTTSSSSSSSSSFFFFFFF
|
| F,S,T,H
|
|
| W
|
| set and play animation+frame
|-
| 57/0x39
| ANIF
| '''00111001'''HHTTTTTT0000FFFFFFFFFFFF
| F
| H,T
|
|
| W
|
| set and play frame of animation
|-
| 58/0x3A
| VECA
| '''00111010'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
| *
| **
| multi-purpose vector calcs
|-
| 59/0x3B
| JAL
| '''00111011'''VVVV00000EIIIIIIIIIIIIII
|
| I,V
|
|
|
|
| jump and link
|-
| 60/0x3C
| EVNT
| '''00111100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event
|-
| 61/0x3D
| EVHR
| '''00111101'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: reject event
|-
| 62/0x3E
| EVHA
| '''00111110'''TTCCRRRRRR**************
|
| R,C,T,*
| **
|
|
|
| event handler: accept event
|-
| 63/0x3F
| CHLD
| '''00111111'''AAAATTTTTTTTSSSSSSCCCCCC
|
| C,T,S,A
|[C],
arg[0 to A]
|
|
|
| spawn children objects
|-
| 64/0x40
| NTRY
| '''01000000'''TTTTTTTTTTTTEEEEEEEEEEEE
| T,E
|
|
|
|
|
| multi-purpose page operation
|-
| 65/0x41
| SNDP
|'''01000001'''VVVVVVVVVVVVAAAAAAAAAAAA
| A,V
|
|
|
|
|
| play sound effect
|-
| 66/0x42
| SNDA
|'''01000010'''VVVVFFRRRRRRSSSSSSSSSSSS
| S
| V,F,R
|
|
|
|
| adjust voice parameters
|-
| 67/0x43
| VECB
| '''01000011'''CCCTTTBBBAAAVVVVVVVVVVVV
| V
| C,T,B,A
|
|
|
|
| multi-purpose vector calcs
|-
| 68/0x44
| EVNC
| '''01000100'''LLLAAARRRRRREEEEEEEEEEEE
| E
| L,A,R
|
|
|
|
| send an event, cascading
|-
| 69/0x45
| EVNB
| '''01000101'''LLLAAARRRRRREEEEEEEEEEEE
| R
| L,A,R
|
|
|
|
| send an event to all objects
|-
| 70/0x46
| CHLF
| '''01000110'''AAAATTTTTTTTSSSSSSCCCCCC
|
| A,T,S,C
| [C],
arg[0 to A]
|
|
|
| spawn children objects; forcefully?
|-
| 71/0x47
| JALR
| '''01000111'''AAAAAAAAAAAAPPPPPPPPPPPP
| P,A
|
| arg[0 to A]
|
|
|
| jump and link to instruction pointed at by P
|-
| 72/0x48
| ?
| '''01001000'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 73/0x49
| NATIVE
| '''01001001'''101111100000101111100000
|
|
|
|
|
|
| begin native (psx mips) code
|-
| 74/0x4A
| ?
| '''01001010'''------------AAAAAAAAAAAA
| A
|
|
|
| O
|
| unknown VIDO operation
|-
| 75/0x4B
| ?
| '''01001011'''------------AAAAAAAAAAAA
| A
|
|
|
|
|
| unknown
|-
| 76/0x4C
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown
|-
| 77/0x4D
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
| P,T
|
|
|
| unknown
|-
| 78/0x4E
| ARRS
| '''00101011'''RRRRRRRRRRRRLLLLLLLLLLLL
| L,R
|
| S
| *(L + R) = S
L[R] = S
|
|
| store array value
|-
|}
</div>

==== GOOLv3 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 added in ''Crash 3''.
<div style="font-family:monospace;font-size:11px;">
{| 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
|-
| 79/0x4F
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 80/0x50
| ?
| '''01001101'''AAAAAAAAAAAABBBBBBBBBBBB
| B
|
|
|
|
| A
| unknown
|-
| 81/0x51
| ?
| '''01001100'''AAAAAAAAAAAABBBBBBBBBBBB
| A,B
|
|
|
|
|
| unknown matrix math
|-
|}
</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 <i>implied</i> 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 <i>translate</i> 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 <i>implied</i> 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 <i>results</i> to the object's stack. That is-it is <i>implied</i> 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 256 (range: -32768 - 32512)
|-
|1010IIIIFFFF
|Frac Ref
|constant mult of 16 (range: -8192 - 8176)
|-
|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.)

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

{| 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)
|E (Crash 2 MOVC)
|
|-
!Name
|Entry
|Event
|External Executable Flag
|
|-
!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>

=== GOOL Instruction Operations ===
TBD