API reference

Every public class, method, and event in @codexo/exojs. Generated from source.

I

interfaceSystemMethods

@codexo/exojs / core / stable

The five scheduler phases a System may participate in, one per dispatch stage of the Application frame loop: pre-simulation sync, fixed-timestep simulation, variable-rate update, rendering, and post-flush work. Every phase must be synchronous. The registry dispatches them on the frame path and never awaits a result, so an `async` phase is a compile error (see Synchronous) and, for callers the type system cannot reach, a thrown error in every build. Asynchronous work belongs in the owning scene's Scene.load.

0
props
5
methods
0
events
Import
import { SystemMethods } from '@codexo/exojs'

The five scheduler phases a System may participate in, one per dispatch stage of the Application frame loop: pre-simulation sync, fixed-timestep simulation, variable-rate update, rendering, and post-flush work.

Every phase must be synchronous. The registry dispatches them on the frame path and never awaits a result, so an `async` phase is a compile error (see Synchronous) and, for callers the type system cannot reach, a thrown error in every build. Asynchronous work belongs in the owning scene's Scene.load.

Methods5
Act on a frame that is already out of the application's hands. Called once per frame, after the backend has flushed and the frame-time statistic has been written - a diagnostic overlay reporting true frame cost, a network system sending state once the frame is drawn, work that wants whatever time the frame has left. budget reports the time remaining before the frame reaches its target duration; see FrameBudget. It is the only phase handed one, because it is the only point in the frame at which the figure is meaningful. Scene-graph mutation is allowed here and is picked up by the next frame's consumers rather than this one's.
Advance by the variable frame delta, *before* this frame's fixed steps. Called once per frame, ahead of every other phase. This is where per-frame state has to be brought in sync with the incoming frame so the simulation sees it: the engine's own input, interaction, audio, tween and rendering systems all run here. Anything that must be current *before* physics runs belongs in this phase - a system reading input in SystemMethods.update would see the previous frame's snapshot, because update runs after the fixed steps.
Source