Pixscape is currently in public pre-release.

The runtime and documentation are already usable, but some APIs, workflows, and editor behavior may still evolve before a stable 1.0 release.

Architecture & Performance

How Pixscape Runtime reduces frame work while keeping rendering predictable and portable.

On this page

Pixscape Runtime is built around a simple idea: avoid doing work during a frame unless something actually changed.

Pixscape Runtime frame pipeline from dirty tracking and simulation through synchronization, culling, sorting, and rendering.
High-level frame pipeline used by Pixscape Runtime.

Batch compatible rendering

Pixscape groups compatible rendering work so the GPU can draw more objects with fewer state changes. Atlas pages, texture arrays, and sorting help reduce texture binds and draw calls while preserving visual order. The result depends on a game’s assets, shaders, materials, blend modes, and scene composition.

Pixscape keeps gameplay data in ECS while preparing compact render data for the frame. This avoids repeatedly walking large object graphs during rendering without exposing the internal render layout as a gameplay API.

Update only changed data

When something changes, Pixscape updates the affected Runtime and render data instead of rebuilding the whole scene. The normal APIs and entity facades signal these changes automatically; direct component mutation must follow the rules described in Expert ECS Access.

Skip off-screen work

Camera visibility checks allow off-screen content to be skipped before final submission. Large Tiled maps are handled in chunks instead of treating every tile as independent work every frame.

Reduce frame allocations

Pixscape reuses frame data, buffers, and Runtime structures where practical. This helps reduce garbage-collection pressure and aims to keep frame times stable without claiming that every game frame is allocation-free.

Keep 2.5D ordering deterministic

Spatial adds deterministic front/behind ordering only on layers where it is enabled. Other content keeps the normal layer and z-order rules.

Remain portable

Core Runtime systems are designed with Desktop, Android, and HTML / WebGL2 in mind. Platform GPU behavior and performance can still differ, so profile the actual target builds of your game.

In practice, static content can stay cheap, compatible work can be batched, off-screen work can be skipped, large maps can be chunked, changed data can be updated selectively, and frame allocations can be reduced. These strategies are designed to improve performance; they do not replace profiling a real game.

For custom frame phases or render submission, see Advanced Runtime Integration.