News for hackers. Stuff that matters.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by Keyframe on Sunday April 19, 2026 @04:36AM (#47822759)
not framerate of rendering but physics running at (its own) fixed frame rate.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by nottorp on Sunday April 19, 2026 @05:01AM (#47822871)
Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate.

The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by JoshTriplett on Sunday April 19, 2026 @01:26PM (#47825938)
> i.e. old generation consoles, before they started to make "pro" upgrades.

And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by bregma on Sunday April 19, 2026 @06:05AM (#47823139)
I think you mean timestep. The video frames get updated on one timestep (the so-called "frame rate" because it is the rate at which video frames get redrawn, the inverse of its timestep), physics gets updated on a separate timestep, and gameplay or input or network polling can be updated on its own timestep.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by Keyframe on Sunday April 19, 2026 @10:43AM (#47824685)
pretty much, over the dozen or so game and rendering engines I made over the decades name mutated from tick to timestep to frame (rate) to refresh rate (hz) to tick again.. it doesn't matter as long as every system is decoupled and rendering is unbounded (if hardware/display combo supports it). This needs thinking from day one. Cool stuff you can do then is determinism, you can do independent timers which go forward, halt, backward in time, different speed multipliers over those (so some things run slower, faster, everything goes slower / faster), etc.