calebbennetts - sure.
Animmaniac - I really am not very persuaded by other time stepping algorithms. Sure, someone wrote a blog post saying "this is the best way to do it!" but that doesn't mean I agree. The way I see it is you either end up stepping more than the rendered framerate, which means you're burning CPU simulating stuff that isn't displayed, or you step less than the rendered framerate, which means there's nothing new to draw at the next rendered frame.
Also people are very sensitive to jank/juddering/uneven movement. If the logic is running at a different rate to the rendering, the motion becomes uneven. For example logic at 45 Hz with rendering at 60 Hz means every rendered frame shows alternating step distances, e.g. 10px, 15px, 10px, 15px... given how sensitive people are to this (particularly when scrolling), I think the only solution would be to go for an integer multiple/divisor of the framerate to guarantee every rendered step moves the same distance. E.g. logic at 2x, 3x, or 1/2, 1/3.
This means then that if you want faster logic than the display rate, it will have to go at least twice as fast, to 120Hz. This also means if your current CPU usage is 60%, you don't have enough overhead to do that, and your game will start lagging. It also will use more battery, make phones hotter, and significantly lower your headroom to do interesting stuff with the CPU.
If you want slower logic than the display rate, it'd probably have to be 30 Hz. What I don't really get about this is if you only step the game at 30 Hz, there is nothing new to draw in between logic frames. I think some devs propose a "lite" step in between which just advances motion without doing anything else, but this worsens tunnelling problems (new scenario: object actually seen colliding, but no collision registered!), and could still use a bunch of CPU e.g. if it's a large physics game. Also, to reliably schedule at half-display-rate we need browser support.
Finally the really obvious problem with fixed timesteps is systems which have different display rates. VR is making rates like 90 Hz more common, with plans to make it even higher. Gaming displays that run at 120Hz have already existed for a while. Variable-rate gaming displays like G-sync are now available too. Maybe Apple or Samsung will decide their next big differentiator is to run their next phone at 120Hz to make everything even smoother. It's naive to think everyone runs 60 Hz and will always do so, and then if you only run logic at an integer multiple/divisor, there is no solution - you can't choose a logic rate that covers all these display rates with smooth motion. And don't forget on weak systems fixed-step games go in to slo-mo instead of stepping further to compensate.
So IMO the existing approach of variable steps has a lot of benefits:
- with accurate v-sync, motion is perfectly smooth
- all display rates are accommodated equally (which is also good future-proofing)
- CPU usage is matched to the framerate and is no higher than necessary
- slowdowns on weak systems are compensated for
The downsides include tunnelling with large steps, but this can be mitigated in the main cases, e.g. the bullet behavior in Classic had a special stepping feature specifically to solve that problem, which I always intended to (but never quite got round to) port to C2, or there could be a stepping behavior to handle it. Then this CPU-intensive stepping only applies to things that really need it, rather than the whole game globally.
The other downside is non-deterministic gameplay. To some extent we can improve this with better maths, as this thread shows. However I've always thought of this like floating point rounding errors: the calculations are never going to be exactly correct, so you always build in a tolerance instead of expecting exact answers. For example even with fixed steps, you can never assume your platform behavior will land at Y = 100, because floating point errors (literally occurring in the CPU circuitry) mean it will probably land at something more like Y = 99.9999999978. Given you need this kind of tolerant approach for that, I always thought this was wise to apply to motion as well, doubly so for the errors in time step. So instead of expecting the player to make a jump within 0.1px, make sure it works with say a 2px threshold (assuming we fix the math), and so on. There are ways to work around other problems as well, for example a record/replay feature could simply record the sequence of actual measured delta-times, and replay them for the purposes of making a deterministic replay.
So my focus has always been on variable timestep, and then add features to help work around tunnelling and non-determinism if they pose a problem. So my approach for C3 is to add some of those mentioned features. The way I see it, changing the way the stepping works itself has worse downsides.