Game development
Frame budget calculator
Turns a target frame rate into the milliseconds available per frame, subtracts the headroom you choose to reserve, and checks your measured render, simulation and other costs against what is left — including which of the three is worth optimising first.
The question this answers: “I am targeting 60 fps. How much time is that per frame, and does what I just profiled actually fit inside it?”
Result
- Frame period
- 16.67 ms
- The whole of one frame at 60 fps. A definition, not an estimate.
- Budget after headroom
- 15 ms
- Measured frame time
- 13.5 ms
- Left in the frame
- 1.5 ms
- Unspent working budget.
- Working budget used
- 90%
- Rate these frame times sustain
- 74.1 fps
- Ignoring headroom and assuming every frame costs what you measured.
Worth knowing about this answer
- A budget, not a prediction. It says whether the frame times you measured fit inside the period you are targeting; it has no view on what your frame times will be on hardware you have not measured.
- Frame time is not the average of frame times. A build that averages comfortably inside budget and misses one frame in sixty is visible as a stutter, and an average hides exactly that. Profile the worst frames, not the mean.
- The allocation between render, simulation and everything else is yours. This tool suggests no split, because a typical one does not exist across engines and genres — and a default printed here would be read as a recommendation.
Show the working
- Frame period from the target rate
1000 ms ÷ 60 fps16.67 ms - Headroom reserved
16.67 ms × 10%1.67 ms - Measured work
9 ms render + 3 ms simulation + 1.5 ms other13.5 ms - Against the working budget
15 ms − 13.5 ms1.5 ms
Frame period: 16.67 ms. Budget after headroom: 15 ms. Measured frame time: 13.5 ms. Left in the frame: 1.5 ms. Working budget used: 90%. Rate these frame times sustain: 74.1 fps
The frame period is a thousand milliseconds divided by the target rate — a definition rather than an estimate. The headroom percentage is taken off it to give a working budget. Your three measured costs are added and compared against that working budget, and the same total is inverted to give the frame rate those costs actually sustain. The largest of the three is reported as a share of the total, because that is what decides where optimisation is worth spending.
- That the three figures you enter are measured on the hardware you are targeting. Frame time is a property of a build on a machine, and a number from a development workstation does not transfer to a console or a phone.
- That the costs are serial. On a multi-threaded engine with overlapped render and simulation the sum overstates the frame time, and the useful reading becomes the longest single stage rather than the total.
- That the reserve is yours to set. This tool proposes no default headroom and no split between the three costs, because typical values differ by engine and genre and a figure printed here would be read as a recommendation.
- It is a budget, not a prediction. It says whether what you measured fits; it has no view on what your frame times will be on hardware you have not measured, and none at all on whether a design is achievable.
- Averages hide the frames that matter. A build comfortably inside budget on the mean and missing one frame in sixty reads as a stutter, and this arithmetic cannot see that — profile the worst frames.
- Nothing here concerns the platform certification requirements that some storefronts and console programmes apply. Those are published by the platform holder and are the only authority on them.
- It says nothing about whether a game will sell, hold players or be finished on time. Those are not arithmetic and a tool that offered a number for them would be inventing one.
Runs entirely in your browser — nothing you type is sent anywhere. Last reviewed 2026-08-19. More on Game development.