I think it is, if we want to be scalable at higher framerates. As it is, we're running physics every frame, so getting 60 fps means 60 physics updates per second. If you want to get 120 to 140 fps (or more, considering g-sync and the like), that means we're doing that many physics updates per second, which besides being completely overkill, could harm the simulation as movement sizes shrink and we start running into the lower bounds of fp precision. We could cap the physics to 60 updates per second, but then we're effectively capping the framerate at 60; even if we render more, nothing will have moved.scrawl wrote:Logic depending on framerate is something we'll just have to accept for the time being, until a bigger refactoring comes along to decouple all game logic from rendering, decouple physics from logic and rendering, etc (and I'm not convinced that would be a good idea, either).
The better option would be to use Bullet's simulation loop with the appropriate character controllers/callbacks, which I believe does 30 updates per second and applies interpolation when in between updates, effectively decoupling the physics from the logic and rendering. This makes sure the update period is long enough to prevent slow moving objects from rounding to a 0 delta, while also being able to efficiently move objects more than 60 times per second.