This document describes the RWS format. The source code to read this data can be downloaded from the project page. Thanks to Alastair Burr for his decsription of the DFF format that this work have been based on.
This file format is actually the same as the .dff, .bsp and other formats used by RenderWare. All of them are RenderWare Binary Streams. The .rws extension is used for streams that can contain multiple objects or to hide what kind of data it contains.
The data types used in this document are given in C style and arrays of these can appear. Data is stored in the stream in little endian format. This means that if you happen to have an Intel compatible PC you can just type cast some bytes from the stream to any type and it will be turn out correct.
"if"-statements appears in the object definitions. If the conditional is true it means that the variable or chunk to the right of it is included in the stream.
Objects are stored in streams as chunks. Each chunk are divided in two parts, header and data.
The chunk header always have the following layout.
Type can be one of the following object id:s. Only types relevant to this document are included.
Length is the size of the data part in bytes. When parsing a data section this number is actually not needed. Use it to skip a chunk that you don't want or can not read. One exeption from this rule seems to be the String chunks where the length data can be useful..
BuildNum is the build number of the RenderWare libararies.
Versions is the version of the RenderWare engine. The most significant three nibbles represent the first three numbers in the SDK version. The least significant nibble is the binary revision which is the fourth number.
The Data part contains the contents of an object. Most of the time it is made up of more chunks.
If the object can be extended with plugins the chunk ends with an extension chunk. Plugins extends objects with more data and this data is saved in the extension. The extension chunk always exists for these objects even if it is empty.
After the Struct chunk a number of child objects can appear. The classes of the objects and how many objects there are is determined by the parent object and the contents of the Struct chunk.
The following headings describe the different objects that can apperar in the stream. Only the Data part of each chunk is shown as all headers have the same structure anyway. When streaming an object it does not need to know the size of the data chunk. The size will become clear by the contents of the data. The string chunk may be an exeption.
Used in the beginning of most objects. The Struct chunk contains the attributes for the object. The contents of a Struct is different for each kind of object.
A '\0' terminated string. Note that up to three bytes extra can exist after '\0' to align it to a 4 byte boundary. As will all chunks the size of the data is given in the header.
Used in objects that can have plugins. The extension contains other chunks. Extensions are not absent even if they are empty.
Frames only appear here if they are childed to each other. This should always be the case(?). The first frame is for the Clump, the rest are for the Atomics and plugins.
Frames only appear here if they are childed to each other. This should always be the case(?). The first frame is for the Clump, the rest are for the Atomics and plugins.
Number of texture coordinate sets are stored in the third byte of the flags. NumTexCoordSets = (Flags & 0x00ff0000) >> 16.