Open fallenatlas opened 2 weeks ago
I think if you have movement based on a time delta based on the clock you will always have collision problems (at least if collision is just checking if two boxes are intersecting) because there's no upper limit to the distance covered in a single tick.
If you base distance covered on frames instead of time delta, the collision problems should stop varying with performance right? And if you try to "fix the framerate" the movement should be less variable with performance (movement will be even worse for computers that can't handle that framerate but otherwise it should be the same)
I think if you have movement based on a time delta based on the clock you will always have collision problems (at least if collision is just checking if two boxes are intersecting) because there's no upper limit to the distance covered in a single tick.
If you base distance covered on frames instead of time delta, the collision problems should stop varying with performance right? And if you try to "fix the framerate" the movement should be less variable with performance (movement will be even worse for computers that can't handle that framerate but otherwise it should be the same)
In theory, we have movement based on a 'fixed delta time', which means all simulation steps use the same exact delta time. So that should not be a problem. The way it is implemented is pretty much the standard way to approach it, which is:
Maybe some of the physics systems are not repeating correctly and thus we get the weird behavior, but i'm not sure
Exactly, at the moment the physics simulation is set to run at 30 fps.
What should happen is on PCs where the game runs at 60fps on the 'graphics frame' we should have 1 physics update every 2 frames so we get 30fps, this is the easy part, and should be working although it seems like it doesn't in some ocasions.
When the framerate is lower than 30, we should execute multiple physics updates in one frame, which is counter intuitive since if the PC is slower it's going to get stuck doing this infinitely, since we don't have a failsafe yet. This is why our current target is a conservative 30 updates per second, it can handle it dropping a couple of times below that, but not for a long time. However, even like this, it always steps the same amount of time.
The current explosive behavior on lower frame rates, from my understanding, indicates an overcompensation which should only happen when the collision of objects is detected only when they already too much inside of each other, which shouldn't happen if the multiple updates per one frame part was working. If the problem lies exactly in this part, I'm not sure, but it's a good starting point, and it's good to make sure the fixed delta is working well.
I assigned myself to this issue, since I'm the one who added repeatWhile to systems :fearful:. If that is the problem this is gonna be more of a core issue then.
I think it doesn't make sense for this to be an issue with the ECS: the only way, I think, for us to get the behavior we are getting, would be for different PCs to have somehow have different step times. If the problem was on the ECS, some PCs would run faster/slower, but with the same step. The step time should be fixed... is it possible there's some system which affects the physics simulation which is using the standard DeltaTime
instead?
Problem
Currently, in slower pcs, the simulation seems to explode, stability is really poor and the objects go through each other. On another hand, on fast pcs, all movement looks faster. This seems to indicate that the fixed delta time has an issue, and is not executing the systems a fixed number of times per second. We should further investigate this.
Note: for more robust testing we might need a way to fix the framerate to a certain number