Step order

Optional

You don’t need this for most games. This page helps when something happens “one step late” and you want to know why.

Fixed step

Brasa runs the game logic in fixed steps of 1/60 of a second, independent of the speed of the computer. If a frame takes long, it runs more steps to catch up (at most 5 per frame). That’s why speeds in “pixels per step” and timers in “steps” behave the same on any machine.

Inside a step

For all the instances, in this order:

1. Timers: the after/every that are due are run.
2. onUpdate of each instance, in the order in which they were created.
3. Movement: gravity and friction adjust the speed, hspeed/vspeed move the instance (unless moveAndStop has already moved it on this step) and the animation advances.
4. Collisions: the onCollide of whoever is touching.
5. Destructions: the instances with destroy() leave, and their onDestroy is called.
6. New instances: the ones created during the step join the list. Their onSpawn already ran at the time of the spawn, but the first onUpdate only happens on the next step.
7. Camera: the room’s camera moves one step behind the target, with the smoothing and the dead zone. Since it moves on the fixed step, the smoothing is the same on any monitor, 60 Hz or 144 Hz.

After the steps, the frame is drawn: all the visible instances run onRender (the layers at the back first) and, on top of everything, onRenderGui. The position of the camera is rounded to a whole pixel at drawing time, so the character and the scenery change pixels together.

Practical consequences

• A position changed in onUpdate already applies to the collisions of the same step.
• destroy() doesn’t remove right away: the instance finishes the step and leaves at the end of it. Use isDestroyed() so you don’t act twice.
• goTo and restart happen at the end of the frame, after the current step finishes.