Resource file format

Stunts game data are stored in a common container format. Files of this format can hold multiple resources, blocks of data that may be of various types - text, bitmaps, sounds, etc. Resources are uniquely identified within each file solely by a 4-byte name. A resource container file can be encapsulated by compression.

This document focuses on BB Stunts 1.1, but details described here may still—partly or wholly—cover other versions, or even other games developed by DSI at the time.

File names

Different file name extensions are used to indicate the content of the files. Compressed files has "P" (packed) as the first letter of their extensions. Whether the game prefers raw or compressed files varies based on file type.

File contents	Raw	Compressed	Preferred
Text and misc. settings	RES	PRE	Raw
Bitmap images	VSH	PVS	Compressed
Icons	ESH	PES	Compressed
3d shapes	3SH	P3S	Compressed
Music tracks	KMS	PKM	Raw
Instrument samples	VCE	PVC	Raw
Sound effects	SFX	PSF	Raw

Structure

The resource file header consists of two integer fields denoting the total length of the file and the number of resources contained. The following table of contents has a list of ids and a corresponding list of offsets into the remaining data section.

// Header
uint32 fileLength
uint16 numResources

// Table of contents
char   ids[numResources][4]
uint32 offsets[numResources]

// Resource data
char   data[]

Types

Resource type can be determined by looking at the resource's id string and/or the source file name.

Plain text

Text resources are null-terminated C strings found in RES/PRE files. Strings can contain non-alphanumeric codes used by the game to achieve certain effects. Most prominent is the "]" (right square bracket) used to represent newline in multi-line text.

Bitmap images

VGA palette used by bitmap images. Value 255 is transparency.

Bitmaps are images with 8-bit color depth using a fixed palette in VGA mode. Special bitmaps using the naming scheme !cg_ and !eg_ provides color mapping for graphics modes with fewer available colors.

uint16 width
uint16 height
uint16 unknown1[4]
uint8  unknown2[4]

uint8  image[width * height]

Parts of this structure are not fully understood. unknown1 appears to be related to Stunts' internal memory management. unknown2 seems to affect how image pixels are organized in compressed resource files, likely to gain more effective run-length compression. Images with pixel data stored as continuous horizontal lines has unknown2 set to { 0x1, 0x2, 0x4, 0x8 }.

3d shapes

Shapes are composed of a vertex list and a list of primitives. Primitives are basic shapes that can have different types, such as polygons or wheels. Depending on the type it contains a number of indices into the vertex list needed to draw the shape, color variations and some rendering hints. Stunts' coordinate system use 16-bit signed integers, making the resolution relative to the scale of the model. Shapes presented in the car selection screen are more detailed than in-game shapes, thus requiring larger scaling. By comparing the car shapes to their real-life originals 1 meter in-game corresponds to 20 units, making each track tile roughly 50 meters wide.

Due to the counter header fields being stored in single bytes, the total amount of vertices and primitives are limited to 255 per shape.

Main strcture

uint8     numVertices
uint8     numPrimitives
uint8     numPaintJobs
uint8     reserved // Always == 0

VERTEX    vertices[numVertices]
uint32    cullFront[numPrimitives]
uint32    cullBack[numPrimitives]
PRIMITIVE primitives[numPrimitives]

uint8     terminate[...] // 1-3 NULL-bytes for data alignment

Additional structures

struct VERTEX {
  int16 x
  int16 y
  int16 z
}

struct PRIMITIVE {
  uint8 type
  uint8 flags
  uint8 materials[numPaintJobs]
  uint8 indices[...] // Size depends on type.
}

Primitive types

Primitive type	Vertex indices needed	Description
1	1	Particle, 1 pixel
2	2	Line segment, 1 pixel width
3–10	3–10	Polygon, n sides
11	2	Sphere (center + ~(radius / 2)
12	6	Wheel
*	0	Ignored

Primitive flags

Flag	Name
0x01	Two-sided
0x02	Z-Bias
*	Ignored

Culling data masks

Flag	Description
0xFFFE0000	Horizontal angle ranges, positive direction
0x0001FFFC	Horizontal angle ranges, negative direction
0x00000001	High vertical angle flag, positive direction
0x00000002	High vertical angle flag, negative direction

For car body and track element shapes the first eight vertices are reserved for the corner vertices of the shape's bound box, used to cull entire shapes located outside the view frustum.

Anatomy of a wheel shape primitive.

The first three vertices in a wheel primitive marks the center, tire radius and rim radius for the inner wheel-half facing the vehicle. The last three vertices does the same, in the same order, for the outer half of the wheel. Directions may not matter, the vertex locations are used to measure distances. This rule applies to the sphere primitive as well.

Wheel transformations are performed on fixed vertex positions. Since the first eight vertices of car[0-2] shapes are occupied by the bound box, vertices 9-14 and 15-20 are front wheels. Misplaced wheel vertices will lead to corrupted shape rendering.

The flags in the PRIMITIVE structure are used for two-sided polygons (disable back-face culling) and to enable Z-bias in order to resolve Z-fighting.

Materials are indices into a permanent, internal game structure and are assigned per-primitive. Cars can have multiple paint jobs, every primitive in the shape must set a material for each color scheme.

Each primitive has two 32-bit culling data fields to determine visibility. A culling data field holds angular visibility in positive and negative direction using 15 bits each. One bit corresponds to 1/15th of a full circle and the bits can be set in any combination. The two least significant bits are used as flags for visibility at near-vertical viewing angles.

A shape resource must be terminated with NULL-bytes. The number of bytes needed is not known, but padding three NULL-bytes has proven to work regardless of resource size or byte alignment. Failing to meet this requirement will lead to obscure rendering artifacts.

Car parameters

Numerical car*.res parameters are stored in a 776 bytes sized resource identified as simd. Most data in simd is stored as signed 16-bit integers. Noteworthy exceptions include number of gears, gear ratios, torque curve data and bitmap coordinates for dashboard instruments - which are unsigned 8-bit integers. Organization and function of the parameters are outside the scope of this article; the reader should consult the main article on the topic for further information.

Tools

• stressed - Stunts/4D [Sports] Driving resource editor [1].