From Capcom to the Backend: High-Performance Data Streaming in .NET (Part 1)

Rui Aparecido de Moraes — Tue, 06 Oct 2026 17:39:48 +0000

From MT Framework and RE Engine to REX: Building Zero-Allocation Telemetry Pipelines with Lessons from Capcom's Next-Gen Architecture

1. The Prelude: The Lineage of Capcom's Engines (MT Framework → RE Engine → REX)

To understand why a library like REDox matters to software engineering at large, one must understand Capcom's unique engineering philosophy over the past two decades.

The MT Framework Era (2006)

During the transition to the PS3 and Xbox 360 era, Capcom broke away from fragmented, game-specific codebases and engineered MT Framework (Multi-Target Framework). Debuting with titles like Dead Rising and Lost Planet, MT Framework established Capcom's reputation for squeezing maximum concurrency and multi-threading efficiency out of complex hardware architectures (such as the Cell Broadband Engine).

The RE Engine Revolution (2017)

A decade later, photorealism and sub-millisecond input response became paramount. Capcom unveiled the RE Engine (Reach for the Moon Engine) alongside Resident Evil 7: Biohazard. RE Engine was groundbreaking not only for its rendering and modular C# scripting layer, but also for its internal pipeline orchestration: fast hot-reloading, deterministic memory management, and cross-platform scalability spanning Monster Hunter Rise, Devil May Cry 5, and Street Fighter 6.

The Next Frontier: REX and REDox (2026)

As hardware demands advanced toward exponential asset scale, AI-driven simulations, and cross-platform streaming, Capcom introduced REX (RE neXt ENGINE). REX is engineered to scale beyond existing RE Engine constraints, focusing heavily on modern modularity, extreme throughput, and data serialization efficiency.

In October 2026, Capcom's R&D division reached a historic milestone by open-sourcing REDox (CAPCOM-TD-OSS/REDox) under the Apache 2.0 license. Defined as a "high-performance, token-based structured data engine for .NET," REDox is not an isolated experiment—it is a core architectural pillar of the REX engine itself.

2. When Game Engine Architecture Meets Backend Engineering

Software engineers outside the gaming industry might initially assume that engine-level code is too esoteric for general-purpose applications. In reality, modern game engines and distributed cloud backends share an identical core problem: how to serialize, transmit, and parse massive volumes of structured data with ultra-low latency and zero memory allocations.

Whether maintaining 60 frames per second on a modern console or ingesting millions of telemetry signals per second across a distributed cloud cluster, the physical constraints of computing are identical:

CPU branch mispredictions and text-conversion overhead consume valuable clock cycles.
Continuous memory allocations on the managed heap induce Garbage Collector (GC) pressure, triggering non-deterministic latency spikes.
Verbose payloads strain network bandwidth and storage I/O.

By adopting the same architectural principles that power REX—continuous token streaming, contiguous memory views (Span<T>), and stack-only lifecycle guarantees (ref struct)—backend engineers can build dramatically faster, leaner distributed systems.

3. The Real-World Scenario: Continuous GPS Telemetry

Consider a large-scale logistics, fleet management, or shared-mobility platform. Vehicles, delivery couriers, and IoT edge devices continuously stream breadcrumb coordinates back to ingestion gateways:

Breadcrumb = { timestampUtc, latitude, longitude, speedKmh }

When ingesting updates at high frequencies (e.g., 10 Hz across tens of thousands of active nodes), payloads accumulate rapidly:

public readonly record struct GeoLocationPoint(
    long TimestampUtc,
    double Latitude,
    double Longitude,
    float SpeedKmh
);

The Latent Cost of the JSON Standard

In modern enterprise architectures, JSON over HTTP or WebSockets remains the default standard due to its ubiquity and human-readable format. However, high-frequency JSON pipelines exhibit notable architectural bottlenecks:

Floating-Point Formatting Penalty: Converting a native 64-bit IEEE 754 floating-point number (double) into an ASCII/UTF-8 string representation (e.g., -23.435512) requires repeated string slicing and decimal formatting algorithms.
Bandwidth Inflation: A single coordinate triplet and metadata in formatted JSON typically requires between 120 and 160 bytes. In raw binary form, that identical payload requires less than 30 bytes—an immediate ~75% footprint reduction.
Garbage Collection Churn: Traditional deserializers allocate intermediary object graphs, arrays, or string instances on the managed heap, forcing Gen0 and Gen1 garbage collections under sustained ingestion loads.

4. The Core Concept: Token-Based Sequential Engines

Instead of constructing an entire Document Object Model (DOM) in memory or generating temporary strings, a token-based engine structures data as a flat stream of markers and contiguous primitive payloads:

[StartTrack] -> [StartPoint] -> [Timestamp] (8B) -> [Latitude] (8B) -> [Longitude] (8B) -> [Speed] (4B) -> [EndPoint] -> ... -> [EndTrack]

Why Tokens?

Stream Processing: Consumers can inspect tokens sequentially on the fly, performing calculations (such as boundary checks or aggregate speeds) without deserializing subsequent fields.
Predictable Memory Layout: Binary sizes are deterministic and fixed, allowing developers to write directly into pre-allocated memory pools or stack-allocated buffers.

5. Modern .NET Primitives: The Secret Behind Zero-Allocation

To replicate the performance characteristics demonstrated by engines like REDox, three features in the modern .NET type system are essential:

1. `Span<T>` and `ReadOnlySpan<T>`

Introduced as fundamental building blocks in .NET, a Span<T> provides a type-safe, contiguous window over arbitrary memory—whether that memory lives on the managed heap, the execution stack (stackalloc), or unmanaged native buffers.

Slicing a Span<T> via .Slice(start, length) performs a pure pointer/length offset calculation: $0$ heap allocations and $O(1)$ complexity.

2. `ref struct`

A ref struct is restricted by the C# compiler to live exclusively on the stack. Because it cannot be boxed, captured in asynchronous state machines (async/await), or assigned as a field of a regular heap class, it guarantees that its lifecycle is bounded strictly to the local execution frame.

This makes ref struct the ideal construct for building high-speed parsers and serializers:

// Stack-only Token Reader: completely invisible to the Garbage Collector
public ref struct GeoTokenReader
{
    private ReadOnlySpan<byte> _data;
    private int _cursor;

    public GeoTokenReader(ReadOnlySpan<byte> data)
    {
        _data = data;
        _cursor = 0;
    }

    public bool ReadNextToken(out byte tokenType)
    {
        if (_cursor >= _data.Length)
        {
            tokenType = 0;
            return false;
        }

        tokenType = _data[_cursor++];
        return true;
    }
}

3. `System.Buffers.Binary.BinaryPrimitives`

Rather than relying on legacy BitConverter calls that allocate byte arrays, BinaryPrimitives provides static methods to read and write little-endian and big-endian scalars directly to and from spans:

// Encodes a 64-bit float directly into a span with zero memory allocation
BinaryPrimitives.WriteDoubleLittleEndian(destinationSpan, latitude);

6. What's Next in Part 2?

In this first part, we examined Capcom's lineage from MT Framework through RE Engine to REX, the architectural motivation behind token-based data engines, and the core memory mechanics that make zero-allocation processing achievable in .NET.

In Part 2, we will roll up our sleeves and implement:

A fully functional TokenStreamWriter and TokenStreamReader tailored for high-density GPS coordinates.
A formal BenchmarkDotNet harness comparing JSON (System.Text.Json) against tokenized binary streaming across 100, 1,000, and 10,000 coordinates.
Cold-hard metrics: payload sizes, execution latency, and heap allocation graphs.

Stay tuned, and get ready to benchmark your pipelines!

7. References & Further Reading

Capcom Research & Development. (2026). REDox: High-performance, token-based structured data engine for .NET. GitHub Repository: CAPCOM-TD-OSS/REDox
Capcom Co., Ltd. (2023). Capcom R&D / REX Engine Technology Presentation. Capcom Investor Relations & Technology Highlights.
Microsoft Learn. (2024). Memory and Span Usage Guidelines. Microsoft Documentation: learn.microsoft.com/dotnet/standard/memory-and-spans
Watson, Ben. (2018). Writing High-Performance .NET Code (2nd Edition). DBC Press.
Toure, Stephen & Microsoft Docs. (2023). How to use Utf8JsonReader and Utf8JsonWriter in C#. Microsoft Learn Documentation.
Apache Software Foundation. Apache License, Version 2.0. apache.org/licenses/LICENSE-2.0

DEV Community: Rui Aparecido de Moraes

From Capcom to the Backend: High-Performance Data Streaming in .NET (Part 1)

1. The Prelude: The Lineage of Capcom's Engines (MT Framework → RE Engine → REX)

The MT Framework Era (2006)

The RE Engine Revolution (2017)

The Next Frontier: REX and REDox (2026)

2. When Game Engine Architecture Meets Backend Engineering

3. The Real-World Scenario: Continuous GPS Telemetry

The Latent Cost of the JSON Standard

4. The Core Concept: Token-Based Sequential Engines

Why Tokens?

5. Modern .NET Primitives: The Secret Behind Zero-Allocation

1. Span<T> and ReadOnlySpan<T>

2. ref struct

3. System.Buffers.Binary.BinaryPrimitives

6. What's Next in Part 2?

7. References & Further Reading

1. `Span<T>` and `ReadOnlySpan<T>`

2. `ref struct`

3. `System.Buffers.Binary.BinaryPrimitives`