Collision Data

Collision data is loaded from a segmented pointer using the level script command 0x2E for levels, and behavior command 0x2A for objects. Special 3D objects and water box collision are also loaded in the level collision loading routine.

1.) The collision data always starts with the two bytes: [ 00 40 ]

2.) The next two bytes define the number of vertices in the collision data. The vertices follow after this.

    For each vertex: 
    
        a.) 6 bytes will follow defining the XYZ position: [ XX XX YY YY ZZ ZZ ] 
            (All XYZ positions are signed shorts)

3.) The next two bytes define the collision type: [ 00 CC ]
    
    The two bytes after that is the number of triangles for that type.
    
    For each following triangle:
    
        a.) Either 6 or 8 bytes will follow depending on if the collision type has 
        special parameters (see collision type list below).
      
        b.) The first 6 bytes define the three indices used to draw the triangles.
        Example: [ 00 00 ] [ 00 01 ] [ 00 02 ], will draw a triangle with the first, second, 
        and third vertex in the vertices list above.
      
        c.) If the collision type has special parameters, then the next 2 bytes define them. 
        What they do is dependent on the collision type.
    
    (Keep looping step 3 until [ 00 41 ] is reached for collision type)

4.) (Only for level collision data)
      
    If the two bytes [ 00 43 ] are encountered, then special macro objects will be defined.
    
    The two bytes after the [ 00 43 ] define the number of special objects to be added.
    
    For each following special macro object:
    
        a.) Either 8, 10, or 12 bytes will follow depending on the object's special preset.
        
        b.) The first 2 bytes are the special preset. This corresponds to an entry in the special
        3d objects preset list, where the Model ID and behavior is defined. This list starts at
        ROM address 0xED350 in the US ROM. More info can be found here: https://pastebin.com/raw/BwzUVeq0
        
        c.) The next 6 bytes define the XYZ position of the object: [ XX XX YY YY ZZ ZZ ]
        
        d.) If the object is 10 or 12 bytes, then the next 2 bytes will define the Y rotation.
        
        e.) If the object is 12 bytes, then the last 2 bytes define extra parameters

5.) (Only for level collision data)
      
    If the two bytes [ 00 44 ] are encountered, then water box collision will be defined.
    
    The two bytes after the [ 00 44 ] define the number of water boxes to be added.
    
    For each following water box:
    
        a.) Each water box will be 12 bytes long.
        
        b.) The first 2 bytes define the id of the water box (signed short). This id also 
            seems to define what the water box will do. 
            * If the id is smaller than 0x32 (including negative numbers), then it will be water. 
            * If the id is equal to 0x32 or 0xF0, then it will be toxic haze. 
            * If its greater than 0x32 and is not a toxic haze value like 0xF0, then it 
              will have no effect on Mario.
        
        c.) The next 4 bytes define the XZ coordinates for the first end-point of the water box:
            [X1 X1] [Z1 Z1] (Both signed shorts)
            
        c.) The next 4 bytes define the XZ coordinates for the second end-point of the water box:
            [X2 X2] [Z2 Z2] (Both signed shorts)
            
        d.) The last 2 bytes define the Y coordinate, representing how tall the water box should be:
            [YY YY] (Signed short)

6.) The collision data ends with the final two bytes: [ 00 42 ]