Zone

From Crash Bandicoot Hacking Wiki
Revision as of 01:44, 1 March 2020 by Mddass (talk | contribs) (→‎Item 3+n: Camera Path)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

Description

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

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

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

Format

Item 1: Header

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

Prototype Header

Unplayably old versions of Crash 1 (circa 1995) have a slightly different format for this item.

Offset Field Size Value
0x0 World Count 4 bytes w
0x4 Reserved for World Models 8 x 0x40 bytes *
0x204 Index of First Camera Path Item 4 bytes h
0x208 Camera Path Count 4 bytes c
0x20C Entity Count 4 bytes e
0x210 Neighbor Zone Count 4 bytes n
0x214 Neighbor Zone EIDs 5 x 4 bytes *
0x228 Texture Page Entry Count 4 bytes p
0x22C "Obligatory" Chunk CID Count 4 bytes t
0x230 Texture Page Entry EIDs 8 x 4 bytes *
0x250 Chunk CIDs 32 x 4 bytes *
0x2D0 Zone Spawn Flags 4 bytes *
0x2D4 VRAM Fill Height for clearing draw buffer 4 bytes
0x2D8 unknown 4 bytes *
0x2DC unknown 4 bytes *
0x2E0 unknown 4 bytes *
0x2E4 unknown 4 bytes *
0x2E8 unknown 4 bytes *
0x2EC Object Light Source Matrix L11 2 bytes *
0x2EE Object Light Source Matrix L12 2 bytes *
0x2F0 Object Light Source Matrix L13 2 bytes *
0x2F2 Object Light Source Matrix L21 2 bytes *
0x2F4 Object Light Source Matrix L22 2 bytes *
0x2F6 Object Light Source Matrix L23 2 bytes *
0x2F8 Object Light Source Matrix L31 2 bytes *
0x2FA Object Light Source Matrix L32 2 bytes *
0x2FC Object Light Source Matrix L33 2 bytes *
0x2FE Object Background Color R 2 bytes *
0x300 Object Background Color G 2 bytes *
0x302 Object Background Color B 2 bytes *
0x304 Object Light Color Matrix LR1 2 bytes *
0x306 Object Light Color Matrix LR2 2 bytes *
0x308 Object Light Color Matrix LR3 2 bytes *
0x30A Object Light Color Matrix LG1 2 bytes *
0x30C Object Light Color Matrix LG2 2 bytes *
0x30E Object Light Color Matrix LG3 2 bytes *
0x310 Object Light Color Matrix LB1 2 bytes *
0x312 Object Light Color Matrix LB2 2 bytes *
0x314 Object Light Color Matrix LB3 2 bytes *
0x316 Object Background Color Intensity R 2 bytes *
0x318 Object Background Color Intensity G 2 bytes *
0x31A Object Background Color Intensity B 2 bytes *
0x31C Player Light Source Matrix L11 2 bytes *
0x31E Player Light Source Matrix L12 2 bytes *
0x320 Player Light Source Matrix L13 2 bytes *
0x322 Player Light Source Matrix L21 2 bytes *
0x324 Player Light Source Matrix L22 2 bytes *
0x326 Player Light Source Matrix L23 2 bytes *
0x328 Player Light Source Matrix L31 2 bytes *
0x32A Player Light Source Matrix L32 2 bytes *
0x32C Player Light Source Matrix L33 2 bytes *
0x32E Player Background Color R 2 bytes *
0x330 Player Background Color G 2 bytes *
0x332 Player Background Color B 2 bytes *
0x334 Player Light Color Matrix LR1 2 bytes *
0x336 Player Light Color Matrix LR2 2 bytes *
0x338 Player Light Color Matrix LR3 2 bytes *
0x33A Player Light Color Matrix LG1 2 bytes *
0x33C Player Light Color Matrix LG2 2 bytes *
0x33E Player Light Color Matrix LG3 2 bytes *
0x340 Player Light Color Matrix LB1 2 bytes *
0x342 Player Light Color Matrix LB2 2 bytes *
0x344 Player Light Color Matrix LB3 2 bytes *
0x346 Player Background Color Intensity R 2 bytes *
0x348 Player Background Color Intensity G 2 bytes *
0x34A Player Background Color Intensity B 2 bytes *

Item 2: Dimensions/Collision Octree

Offset Field Size Value
0x0 Zone Location X 4 bytes *
0x4 Zone Location Y 4 bytes *
0x8 Zone Location Z 4 bytes *
0xC Zone Width 4 bytes *
0x10 Zone Height 4 bytes *
0x14 Zone Depth 4 bytes *
0x18 unknown 4 bytes *
Collision Octree
0x1C Root Node Index 2 bytes *
0x1E Maximum Depth X 2 bytes *
0x20 Maximum Depth Y 2 bytes *
0x22 Maximum Depth Z 2 bytes *
0x24 Octree Nodes * x 2 bytes *

Item 3+n: Camera Path

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

Item 3+c+n: Entity

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

Structure

TBD: zonecollisions, entity 

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

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

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

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

Zone Dimensions/Collision Octree

Collision Octree

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

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

In relation to its corresponding node's parent's associated region of space, a subdivision can be any region resulting from an even partitioning by any combination of 1 to 3 coordinate axis-aligned hyperplanes:

  • Upper left front, upper left back, lower left front, lower left back, upper right front, upper right back, lower right front, or lower right back octant
  • Upper left, Lower left, Upper right, Lower right, Front left, Back left, Front right, Back right, Upper front, Upper back, Lower front, or Lower back quadrant
  • Left, right, top, bottom, front, or back half

Thus, if a node's parent's associated region of space were split in half along a line parallel to either the x, y, or z axis, then optionally split in half along a line parallel to either one of the remaining axes, and then optionally split in half along a line parallel to the remaining axis, the node's associated region of space could be any of either the resulting halves, quadrants, or octants. In these terms, 3 factors determine the location and dimensions of a subdivision: the number of split lines (1 to 3), the respective axes/axis parallel to those/that split line(s) (x and/or y and/or z), and the number/index of the resulting half, quadrant, or octant that encompasses its space.

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

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

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

Octree Node Format

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

Internal/parent nodes

Internal/parent nodes are indicated by a cleared LSB (least significant bit); consequently, their [nonzero] value refers to the relative offset of [the first of] their children in the item. Child nodes are stored contiguously as groups of 8, 4, or 2. The cardinality and arrangement of a parent's group of child nodes depends on its depth in relation to the axis associated maximum depths:

Parent Depth Condition Children Group [format/arrangement] A B C D E F G H
(d < min) && max AA AA BB BB CC CC DD DD EE EE FF FF GG GG HH HH ULF ULB DLF DLB URF URB DRF DRB
cond = (d >= min && d < min2 && min != min2)
cond && min == maxx AA AA BB BB CC CC DD DD UL UR DL DR n/a n/a n/a n/a
cond && min == maxy AA AA BB BB CC CC DD DD LF LB RF RB n/a n/a n/a n/a
cond && min == maxz AA AA BB BB CC CC DD DD UF UB DF DB n/a n/a n/a n/a
cond = (d >= min2 && (min != min2 || min2 != max)) [|| (d >= min && (min == min2 || min2 == max)) ]
cond && min2 == maxx AA AA BB BB L R n/a n/a n/a n/a n/a n/a
cond && min2 == maxy AA AA BB BB top bot n/a n/a n/a n/a n/a n/a
cond && min2 == maxz AA AA BB BB F B n/a n/a n/a n/a n/a n/a
  • The Parent Depth Condition column lists conditions under which a parent node's contiguous group of children have the associated formats. Only the bolded conditions are relevant if max depths are unique. The following symbols are used for brevity:
    • d = parent node depth
    • max* = max depth *
    • M = {max*} (for *=x,y,z)
    • min = min(M)
    • min2 = min(M - {min})
    • max = max(M)
  • The Children Group column lists the arrangement or byte format of the parent's group of child nodes; depending on conditions, there are either 8 children [A-H], 4 children [A-D], or 2 children [A-B] in the group.
  • Each of the A-H columns identifies that child's corresponding subdivision with an abbreviation:
    • L = left, R = right, U = upper, D = lower, F = front, B = back

Non-existent nodes

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

Leaf nodes

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

UUUUUUSSSSSSTTT1

  • T = Node type
  • S = Node subtype
  • U = Unknown/unused?

Node type and subtype refer to type and subtype of the node's corresponding collidable subdivision of 3 space.

Node Type

Node type determines the primary type of corresponding collidable space:

Type Description
0 Solid and Interactive
1 Solid Floor/Ground
2 Level Boundary Wall
3 Pit Area
4 Trigger Misc Death on Collision
Node Subtype

Solid and Interactive, Pit Area, and Trigger Misc Death on Collision type nodes (types 0, 3, and 4) may optionally specify a node subtype. This subtype determines a specific event sent to the player upon collision with the node:

Subtype Description Event
0 ? ?
1 ? ?
2 Spin, Fall Over, and Die (death sequence) 0x700
3 ? 0xC00
4 Drown 0x2100
5 Burn to Ash 0x1F00
6 Explode 0x1E00
7 ? 0xD00
8 ? 0x1200
9 ? 0x1200
10 ? 0x1200
11 ? 0x1200
12 Fall in a Hole and Die 0x900
13 ? 0x2300

It is yet to be determined whether there are additional subtypes with other purposes.

Camera Paths

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

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

Path Points

Each path is composed of a number of closely positioned points that typically trace out an approximate line or smooth curve. Each point corresponds to a position of the camera, and is also associated with a camera orientation. The line or curve traced by a path connects its points in sequence, where points in the path are stored sequentially. Path points are commonly referred to as progress points.

  • When the camera is at a point in a path, it is positioned at the location of that point and oriented according to the point's associated orientation.
  • After the camera moves from the point that it is currently at to another point in the path, it will be at that other point.
  • To move along a path, or move further into its trail, the camera moves from one point on the path to the next, and so on, until it reaches [is at] some desired destination point.

Path Progression

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

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

Path Retrogression

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

Retrogressing too close - problem

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

Progressing too far - problem

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

Neighbor Paths - solution

Even unextended, the path still actually does continue past its last point. Recall that several paths in a zone can be connected: a single path may reference one or more connected neighboring paths. A path's neighboring paths may be:

  • any path in its parent zone, other than itself 
  • any path in any of its parent's neighboring zones 

Each of a path's neighboring paths contain either points that continue the path past its last point, or points that retrogress before its first point. The path's own points are a retrogression of the neighbor path [points] that continue past its last point, and are a continuation of the neighbor path [points] that retrogress before its first point. 

Progressing too far - solution

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

Retrogressing too close - solution

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

Specification

A path specifies up to 4 neighboring paths by including the following information for each path:

  1. The zone that contains the neighboring path
  2. The index of the neighboring path within that zone
  3. Whether the neighboring path, in relation to this path, is a continuation or a retrogression
    • A continuation indicates that the neighboring path is closer to the goal than this path
    •  A retrogression indicates that the neighboring path is further from the goal than this path
  4. Whether the neighboring path, from the perspective of the player as it faces in the direction of the goal, is:
    • In front of the path
    • Behind the path
    • Above/Below the path

Divergence and Convergence

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

Additional Parameters

Each camera path includes the following additional information:

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

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

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

Retrieved from "https://wiki.cbhacks.com/index.php?title=Zone&oldid=353"