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
| Page | Description |
|---|---|
| Installation | Clone, build, and run the testbed |
| Build Options | All CMake flags and common build configurations |
| Configuration | EngineConfig reference and presets |
| First Steps with GG-UI | A first HUD: an asset in the widget designer, its widget class, and showing it on a player's screen |
Architecture
| Page | Description |
|---|---|
| Overview | Design philosophy and the three load-bearing decisions |
| Threading Model | Sentinel/Brain/Encoder trinity + job system |
| ECS & Storage | Tiered SoA storage, partition layout, the "spreadsheet" model |
| Component System | FieldProxy, registration macros, schema validation |
| Entity Lifecycle | Spawn, despawn, handle spaces, defragmentation |
| Simulation Time (draft) | Falling behind and catching up: pacing, quiet frames, variable step, resync, shared slowdown |
| Projects | The editor as its own program; projects, templates, and packaging |
| Code Reload | Game code as a module the editor loads again after a build |
Gameplay Layer
| Page | Description |
|---|---|
| Constructs & Views | Construct<T>, Owned<T>, ConstructView<TEntity>, tick dispatch |
| Game Flow | FlowManager, FlowState, GameMode, Soul/Body pattern, travel |
| Physics | Jolt integration, JoltCharacter, constraint system |
| Audio | AudioManager, voice pool, GPU Physics-Based Audio roadmap |
Networking
| Page | Description |
|---|---|
| Overview | Vocabulary, GNS, authority model, PIE loopback |
| Connection Flow | Handshake → clock sync → level load → spawn (4 phases) |
| Entity Replication | ServerClientChannel, spawn replication, state corrections |
| Rollback Netcode | Rollback design, Jolt snapshots, resimulation |
| Despawn Protocol | Four-phase networked entity despawn |
| Host, Join, and Solo | One build that plays alone, hosts, or joins: a world's role at run time, sessions in the flow manager |
Rendering
| Page | Description |
|---|---|
| Overview | VizBuffer architecture, current state vs roadmap |
| GPU Compute Pipeline | Predicate → prefix_sum → scatter → build_draws → sort_instances, GPU skinning, Buffer Device Address |
| Dirty-Bit Upload | Selective GPU upload, 5 InstanceBuffers, SIMD OR path |
| Presentation & Latency | Present modes, --latency Input-to-Photon measurement, frame pacing plan |
Editor
| Page | Description |
|---|---|
| Overview | 8 panels, PIE, undo/redo, asset database |
| Debugging & Tooling | Slab heatmap, spatial debug, profiling suite |
| Building an Editor Panel | Adding a dock panel: reading on Encoder, acting through Do, registering, strings and looks |
| Edit Timeline | Slab history for editing, undo/redo, and PIE time travel |
UI
| Page | Description |
|---|---|
| GG-UI Foundations | Start here: documents, the builder, re-runs and bindings, text, looks, testing |
| Using GG-UI | Hosting GG-UI as a library, and GG-UI in Trinyx: the host, game data, HUDs and widget classes, the designer |
| GG-UI Design | Retained-mode UI for editor and game: memory model, threading, GPU world UI, Wayland |
| GG-UI Core | Authoring, bindings, data views, panels, docking, layout, snapshots |
| GG-UI Rendering | Primitives, paint, the UI pass, text, images, the engine host |
| GG-UI Interaction | Input routing, focus, value widgets, popups, text, localisation, input actions, console, inspector |
| GG-UI Styling | Widget definitions, tokens, rules, transitions, style sheets and hot reload, the engine theme |
| GG-UI Widget Assets | Game UI as assets: inputs, slots, contexts, actions, style scopes, animation, the designer |
Math & Determinism
| Page | Description |
|---|---|
| Fixed-Point Math | Fixed32, coordinate system, SimFloat alias |
| Determinism Mode | Build options, MetaRegistry, validation harness |
Reference
| Page | Description |
|---|---|
| Performance Targets | Benchmarks, budgets, scalability targets |
| Status & Roadmap | Current milestone status and upcoming work |
| Design Decisions | Why key architectural decisions were made |
| Code Structure | Headers declare, sources define — where implementations live and why |
| Known Issues | Current technical debt and known bugs |
| Schema Error Reference | Component 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:
- 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.
- 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.
- 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 writetransform.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-09): Foundation Stage — Animation and networking in progress; Edit Timeline and GG-UI designed
| Stage | Milestone | Status |
|---|---|---|
| Foundation | Editor | Complete |
| Foundation | Construct/View OOP | Complete |
| Foundation | Networking | In Progress |
| Foundation | Audio | Complete |
| Foundation | Camera System | Complete |
| Foundation | Game Flow | In Progress |
| Foundation | Animation | In Progress |
| Foundation | GG-UI | Editor built in it; game UI (widget assets) in progress |
| Foundation | Edit Timeline | Designed |
| Hardening | Hot-path audit, constraint system, static tier | Planned |
Full details: Status & Roadmap