TrinyxEngine Wiki

TrinyxEngine is a C++20, data-oriented game engine built for competitive multiplayer games where determinism, rollback netcode, and input latency are first-class design constraints. It targets 100,000+ dynamic entities at 512Hz fixed update (1.95ms/frame budget) while exposing a familiar OOP-style API to gameplay authors.

Navigation

Getting Started

PageDescription
InstallationClone, build, and run the testbed
Build OptionsAll CMake flags and common build configurations
ConfigurationEngineConfig reference and presets

Architecture

PageDescription
OverviewDesign philosophy and the three load-bearing decisions
Threading ModelSentinel/Brain/Encoder trinity + job system
ECS & StorageTiered SoA storage, partition layout, the "spreadsheet" model
Component SystemFieldProxy, registration macros, schema validation
Entity LifecycleSpawn, despawn, handle spaces, defragmentation

Gameplay Layer

PageDescription
Constructs & ViewsConstruct<T>, Owned<T>, ConstructView<TEntity>, tick dispatch
Game FlowFlowManager, FlowState, GameMode, Soul/Body pattern, travel
PhysicsJolt integration, JoltCharacter, constraint system
AudioAudioManager, voice pool, GPU Physics-Based Audio roadmap

Networking

PageDescription
OverviewVocabulary, GNS, authority model, PIE loopback
Connection FlowHandshake → clock sync → level load → spawn (4 phases)
Entity ReplicationServerClientChannel, spawn replication, state corrections
Rollback NetcodeRollback design, Jolt snapshots, resimulation
Despawn ProtocolFour-phase networked entity despawn

Rendering

PageDescription
OverviewVizBuffer architecture, current state vs roadmap
GPU Compute Pipeline3-pass predicate/prefix_sum/scatter, Buffer Device Address
Dirty-Bit UploadSelective GPU upload, 5 InstanceBuffers, SIMD OR path

Editor

PageDescription
Overview8 panels, PIE, undo/redo, asset database
Debugging & ToolingSlab heatmap, spatial debug, profiling suite

Math & Determinism

PageDescription
Fixed-Point MathFixed32, coordinate system, SimFloat alias
Determinism ModeBuild options, MetaRegistry, validation harness

Reference

PageDescription
Performance TargetsBenchmarks, budgets, scalability targets
Status & RoadmapCurrent milestone status and upcoming work
Design DecisionsWhy key architectural decisions were made
Known IssuesCurrent technical debt and known bugs
Schema Error ReferenceComponent validation error messages

Engine at a Glance

┌─────────────────────────────────────────────────────────────────┐
│  Sentinel (1000Hz)  │  Brain (512Hz)  │  Encoder (variable)    │
│  Input polling      │  Fixed logic    │  GPU upload + render    │
│  Vulkan lifetime    │  Job dispatch   │  Job dispatch           │
└─────────────────────────────────────────────────────────────────┘
           │                  │                    │
           └──────────────────┴────────────────────┘
                        Worker Pool (N-3 cores)
                  Logic Queue / Render Queue / Physics Queue

┌─────────────────────────────────────────────────────────────────┐
│  Gameplay Layer                                                  │
│  Construct<T> (singular OOP)  |  Entity (SoA horde, SIMD swept) │
│  Owned<T> composition         |  TNX_REGISTER_ENTITY            │
│  ConstructView<TEntity>       |  PrePhysics(dt), PostPhysics(dt) │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│  ECS Storage Tiers                                               │
│  Cold (chunks, AoS)  │  Volatile (3-frame SoA)                  │
│  Static (read-only)  │  Temporal (N-frame rollback ring)        │
└─────────────────────────────────────────────────────────────────┘

Three Design Constraints

The entire architecture derives from three interlocking decisions:

  1. Fixed 512Hz logic update. Enables deterministic rollback, precise input timestamps, and consistent physics integration. Not configurable during a session — everything downstream assumes a known tick rate.
  2. Tiered SoA storage with rollback as a first-class citizen. Hot component data lives in SoA ring buffers (Temporal: N-frame rollback, Volatile: triple-buffer). Cold data lives in archetype chunks. The tier is declared per-component, not per-entity.
  3. OOP API over a data-oriented substrate. Construct<T> gives gameplay authors familiar OOP patterns. ConstructView<TEntity> decomposes them into SoA field arrays transparently. Gameplay authors write transform.PosX += vel.VelX * dt; the engine sweeps it 8-wide with AVX2.

Quick Start

# Clone with submodules
git clone --recursive https://github.com/X64Tyko/TrinyxEngine.git
cd TrinyxEngine

# Build (RelWithDebInfo recommended for profiling)
cmake -B cmake-build-relwithdebinfo -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build cmake-build-relwithdebinfo

# Run the testbed
./cmake-build-relwithdebinfo/Testbed/Testbed

See Installation for full setup, IDE integration, and troubleshooting.

Status

Current phase (2026-05): Foundation Stage — Replication reliability fix + Animation

StageMilestoneStatus
FoundationEditorComplete
FoundationConstruct/View OOPComplete
FoundationNetworkingIn Progress
FoundationAudioComplete
FoundationCamera SystemComplete
FoundationGame FlowIn Progress
FoundationAnimationPlanned
HardeningHot-path audit, constraint system, static tierPlanned

Full details: Status & Roadmap