FRD Limit: Expanding Track Limits in NFS4

A knockdown cone might seem like a minor track detail. But in Need for Speed: High Stakes, it's more than just a polygon. The game needs to maintain its state, calculate collisions, and determine which sections of the track should be visible.

The original engine uses fixed-size arrays for some of this data. As a result, creators building large, object-rich tracks encounter not only performance and loading-time limitations, but also hardcoded limits built directly into the game.

frd_limit removes several of these restrictions by replacing fixed-size storage with dynamically allocated memory. The patch validates the FRD structure before loading, calculates the required storage sizes, and commits memory according to the actual contents of each track. Once the track is unloaded, the committed pages are released.

To demonstrate the changes, a special version of the GT1 track was prepared. It features a seven-level pyramid made of 140 crates, surrounded by three rings containing 336 cones.

That's 476 dynamic physics objects in total, approximately 3.72 times the original limit of 128.

What Has Been Expanded?

Storage	Original Fixed Capacity	Default Patch Safety Limit
Track blocks	300	32,768
Dynamic bodies, such as knockdown cones	128	32,768
Object impact states	512	32,768

The patch also relocates the visible-block lookup table and adjusts the collision list capacity according to the number of dynamic bodies.

A separate safety limit of 32,768 entries is also applied to global FRD objects.

Important: These values are validation and address-reservation limits. They do not guarantee that every track containing this many objects will load successfully or run at an acceptable frame rate.

How It Works

At startup, FRD Limit reserves five regions of virtual address space.

Reserving address space does not immediately allocate the corresponding amount of physical memory. Instead, it establishes virtual address ranges that can later be used to store track data.

Fixed base addresses are necessary because references in the original game code are redirected to the new memory regions. These addresses must remain stable when switching between tracks.

The loading process works as follows:

1. The patch reads the FRD file before the original game loader begins processing it.
2. It validates the file structure, sizes, counters, and selected internal references.
3. It calculates the required memory based on the actual number of track blocks, dynamic bodies, and object states.
4. It commits memory pages within the previously reserved virtual address regions.
5. The validated FRD data is passed to the original loader without reading the file again.
6. After normal scene cleanup, the committed pages are released while the virtual address ranges remain reserved for the next track.

If validation fails or there is insufficient memory, loading is aborted and the reason is recorded in n4patch.log.

The preliminary validation can detect various malformed or truncated FRD files. However, it is not a complete validation of geometry, textures, animations, or every secondary reference.

Unexpected Dependencies Inside the Engine

More Dynamic Bodies Also Require a Larger Collision List

One particularly interesting limitation turned out to be the collision list used during each physics step.

In the original game, this list has room for 154 pointers:

• 128 dynamic bodies.
• 26 car slots.

However, writes to this list do not include bounds checking.

Simply increasing the dynamic body array while leaving the collision list unchanged would cause the 155th entry to overwrite adjacent memory containing a counter.

To address this, FRD Limit relocates the collision list separately and allocates enough space for the track's dynamic bodies, plus another 16 pointers for the racing car pool.

This is a good example of a hidden dependency: expanding one array isn't enough when other parts of the engine still assume its original capacity.

Practical Test: 476 Physics Objects in One Scene

A modified GT1 track containing the crate pyramid and cone rings was used for testing.

All 476 objects are loaded as dynamic bodies and participate in the game's physics calculations.

A fragment from the loading log:

[frd_limit] blocks=104 global=0 bodies=476 impact-states=5
[frd_limit] FRD=1491303 committed=434176 vertices=38249 polygons=34059 references=95

The bodies=476 value confirms the number of loaded dynamic bodies.

These are not decorative copies of models or objects added purely for visual effect.

What Remains Limited?

FRD Limit expands several important internal storage areas, but it does not remove every limitation of the original engine.

Visible Neighbor Table

The format still provides 300 visibility-neighbor entries per track block.

However, the total number of track blocks can exceed 300, and neighboring block IDs can also be greater than 299.

The patch limits iteration to the actual table capacity without rejecting valid block IDs above 299.

Index Width Limitations

Some structures still use signed 16-bit indices, with -1 indicating a missing reference.

Certain references also remain limited to 8 bits.

Therefore, a capacity of 32,768 elements corresponds to valid indices from 0 through 32,767. It does not mean that index 32,768 is valid.

Memory and Performance Limitations

The game remains a 32-bit application with a limited virtual address space.

Temporary rendering buffers, the effects system, and the performance of the physics engine also impose practical limits.

Track Validity

Passing structural FRD validation does not guarantee that all geometry, textures, animations, and other track data are correct.

It also does not guarantee that the track is suitable for an actual race.

Download

Download FRD Limit for n4patch