RenderWare

Origins and early versions (1993–1997)

RenderWare was born at Criterion Software Ltd, a company founded in 1993 in Guildford, England. At that time, game developers wrote virtually all their own graphics engines from scratch — a costly and time-consuming process. Criterion Software's ambition was to offer a general-purpose 3D engine as a reusable software library, letting studios focus on game design rather than low-level graphics programming.

The first version of RenderWare targeted DOS and then Windows PCs, at a time before consumer 3D acceleration hardware existed. The engine operated entirely in software rendering mode, handling rasterization, depth buffering, and texture mapping entirely on the CPU. This approach was standard before the arrival of dedicated 3D cards like the 3dfx Voodoo in 1996.

Early titles such as TrickStyle (1999) and Dave Mirra Freestyle BMX (2000) represent this first generation, where RenderWare was primarily a PC and Dreamcast engine.

The golden age: the PlayStation 2 era (2000–2004)

The launch of the PlayStation 2 in 2000 proved a decisive turning point. Its hardware architecture, centred on the Emotion Engine CPU and the Graphics Synthesizer (GS), was notoriously difficult to program efficiently. Criterion Software adapted RenderWare for this complex architecture and released RenderWare 3, which quickly became the reference middleware of the era.

In 2001, Rockstar Games adopted RenderWare to develop Grand Theft Auto III, the first fully three-dimensional open-world entry in the series. The game's worldwide success brought the engine unprecedented recognition. Grand Theft Auto: Vice City (2002) and Grand Theft Auto: San Andreas (2004) continued this collaboration, demonstrating the engine's ability to handle large urban environments, on-the-fly area streaming, and a high number of simultaneous entities.

Between 2000 and 2004, Criterion Software claimed over 50% market share among third-party engines on the PlayStation 2, with hundreds of licensed titles shipped worldwide.

Acquisition by Electronic Arts and decline (2004–2007)

In August 2004, Electronic Arts acquired Criterion Software for an amount estimated at approximately £48 million. The industry reacted with considerable concern: EA, a direct competitor to many of the studios using RenderWare, had suddenly become the owner of the engine underpinning their games in development.

Those concerns were quickly borne out. EA ceased active development of RenderWare as a commercial third-party product and redirected Criterion's engineering teams toward the Burnout franchise. Third-party studios, deprived of meaningful support, turned to alternatives such as Unreal Engine, Havok for physics, or invested in proprietary in-house solutions.

The final official release, RenderWare 3.7, shipped in 2007. It remained in use on a handful of ongoing projects but was no longer distributed to new licensees. The official website renderware.com was progressively abandoned.

Design philosophy

RenderWare is built around one central principle: hardware abstraction. The engine exposes a single, consistent API to developers regardless of the target platform. Internally, the low-level layers (backends) are platform-specific: rendering on the PlayStation 2 goes through the Graphics Synthesizer, while on PC it can target DirectX or OpenGL. The developer is shielded from these differences entirely.

The entire engine is written in C (with some C++ in tooling), ensuring maximum portability and near-metal performance. All public symbols follow a systematic prefix naming convention:

• The prefix Rw identifies core engine objects (RenderWare Core): RwTexture, RwCamera, RwFrame…
• The prefix Rp identifies plugin objects (RenderWare Plugin): RpWorld, RpClump, RpAtomic…
• The prefix Rt identifies utility toolkit objects (RenderWare Toolkit): RtBMP, RtTOC…

The scene graph

RenderWare organises 3D objects in a hierarchical scene graph structured around two key concepts:

• An RwFrame is a transformation node in the hierarchy. Each frame holds a 4×4 matrix describing its position, orientation, and scale relative to its parent. Frames can be chained to form skeletons or object hierarchies (a car with rotating wheels, a character with articulated limbs).

• An RpAtomic is the fundamental rendering unit: it binds a RpGeometry (the 3D mesh) to an RwFrame (its position in the world). The atomic is the object ultimately submitted to the render pipeline.

• An RpClump is a container grouping multiple RpAtomic objects and their associated frames. It typically represents a complete object (a vehicle, a character) with all its constituent parts.

• An RpWorld represents the static environment (the level, the city), optimised via a spatial partitioning structure based on a BSP tree (Binary Space Partitioning). This structure enables efficient frustum culling: only the zones visible within the camera's view frustum are submitted for rendering.

The render pipeline

RenderWare's render pipeline follows a modular, extensible model based on chained processing pipelines:

1. Visibility determination: The RpWorld BSP tree is traversed to identify the sectors (WorldSectors) that intersect the camera frustum. An optional occlusion culling pass can further reduce geometry load depending on configuration.

1. Atomic collection: Visible RpAtomic objects are collected into a render list.

1. Sorting: Objects can be sorted by distance to the camera, chiefly for correct transparency ordering (back-to-front, painter's algorithm) or to minimise redundant render state changes (state sorting).

1. Hardware submission: Each atomic is passed to its assigned render pipeline. RenderWare provides a system of customisable pipelines: an atomic pipeline is a sequence of processing nodes (pipeline nodes) that transform geometry data into primitives submitted to the GPU or software rasteriser.

This pipeline node system allows developers to modify or extend rendering at any stage: inserting a vertex pre-processing step for skeletal skinning, adding a normal mapping calculation, or implementing proprietary special effects.

File formats

RenderWare defines its own binary formats, organised as typed chunks (TLV structure: Type, Length, Value):

These formats are read and written via RenderWare's stream system, which handles serialisation and deserialisation through a generic stream abstraction compatible with disk files, memory buffers, and network sockets.

Textures and compression

Texture management in RenderWare revolves around RwTexDictionary objects (TXD files), shared containers referenced by multiple scene objects. This architecture allows video memory to be pooled: several models referencing the same textures load only a single instance into VRAM.

On the PlayStation 2, textures are stored in a proprietary format targeting the Graphics Synthesizer, with support for palettised textures (4 or 8 bits per pixel with a colour lookup table) to conserve the console's limited 4 MB of VRAM. On PC, the engine supports DXT1, DXT3, and DXT5 (S3TC) compressed formats as well as uncompressed 32-bit RGBA.

Companion systems

From version 3.x onward, RenderWare was structured as a suite of modular products:

• RenderWare Graphics: The 3D graphics engine described above, the core of the suite.
• RenderWare Audio: An integrated audio engine handling sound playback, 3D positional mixing, and DSP effects. Based on Sensaura technology.
• RenderWare Physics: A physics simulation module covering rigid body dynamics, joints, and collision detection. A direct competitor to Havok for projects already using RenderWare Graphics.
• RenderWare AI: An experimental artificial intelligence module covering navigation and agent behaviours.

RenderWare Studio

To streamline content creation, Criterion Software shipped RenderWare Studio, an integrated development environment enabling artists and game designers to:

• Assemble scenes from assets exported via dedicated 3ds Max or Maya plug-ins.
• Preview rendering in real time within the target environment, emulating the characteristics of the intended platform.
• Configure render pipelines, materials, and physics properties through a graphical interface.
• Generate final data files (DFF, BSP, TXD) ready for integration into the project build.

This toolchain was one of RenderWare's strongest commercial selling points: it narrowed the gap between artists and engine code, enabling faster iteration on visuals without requiring programmer intervention for every asset change.

Per-title licensing

Criterion Software distributed RenderWare under a per-title licensing model common in middleware of the era. Studios paid:

• An upfront fee to access the SDK, tools, and technical support.
• A royalty on sales, typically calculated as a percentage of the revenue generated by each shipped title using the engine.

This model allowed small independent studios to access state-of-the-art technology without investing years of engineering time in an in-house engine.

The RenderWare SDK

The SDK (Software Development Kit) was delivered as:

• Compiled libraries (.lib on Windows, archives on console platforms) specific to each target platform.
• C header files exposing the complete public API.
• Technical documentation (several thousand pages in HTML or PDF format).
• Code samples illustrating key engine features.
• Exporter plug-ins for 3ds Max and Maya, enabling export of assets in native RenderWare formats.

Criterion Software provided dedicated technical support to licensed studios through a private web portal (RWZone), giving access to updates, patches, and a technical knowledge base.

Cross-platform portability

One of RenderWare's primary sales arguments was its ability to target multiple platforms simultaneously from a single codebase. A given title could be ported from PlayStation 2 to Xbox or GameCube with minimal rewriting, since platform-specific hardware backends were managed by the engine itself. While this promise was never entirely frictionless in practice — memory architectures and relative performance profiles differ significantly between platforms — it represented a substantial productivity gain for multi-platform publishers and became a decisive factor in large-scale adoption.