you can solve this by not running at a fixed timestep

Variable-length time-steps are an option -- pretty much all of the commercial games that I've worked on have actually used variable-length time-steps -- however, they do have some downsides.

* The delta-time value that you're using for this frame is actually the amount of time that it took to process the previous frame. You're using this as a guess for how long this frame will take, but this guess is wrong in the case where the frame-rate changes.
If your frame-rate isn't constant, then when it jumps up and down, your animation will become jittery. This is because your estimation was wrong, so you presented an image to the screen where the virtual distance moved doesn't actually match up with the physical time passed. You can alleviate this somewhat by smoothing your delta-time measurements.

* Numerical integration techniques (such as pos += velocity * delta) gives different results depending on your time-step. This means that, for example, you may be able to jump a particular obstacle at 60FPS, but not at 30FPS, or vice versa! You can actually see this in some COD games, where you can jump to supposedly inaccessible places if you boost your frame-rate to 500FPS...
You can alleviate this by using better integration techniques, such as RK4 instead of Euler's method. However, if you're doing accurate physics, you pretty much have to choose a fixed time-step in order to get reliable results...

IIRC Bullet supports variable time-steps, but sternly warns against using them. However, it's possible to have some parts of your game run at a variable time-step, and other parts (such as your physics) run at some fixed time-step.

you can solve this by not running at a fixed timestep

Variable-length time-steps are an option -- pretty much all of the commercial games that I've worked on have actually used variable-length time-steps -- however, they do have some downsides.

* The delta-time value that you're using for this frame is actually the amount of time that it took to process the previous frame. You're using this as a guess for how long this frame will take, but this guess is wrong in the case where the frame-rate changes.
If your frame-rate isn't constant, then when it jumps up and down, your animation will become jittery. This is because your estimation was wrong, so you presented an image to the screen where the virtual distance moved doesn't actually match up with the physical time passed. You can alleviate this somewhat by smoothing your delta-time measurements.

* Numerical integration techniques (such as pos += velocity * delta) gives different results depending on your time-step. This means that, for example, you may be able to jump a particular obstacle at 60FPS, but not at 30FPS! You can actually see this in some COD games, where you can jump to supposedly inaccessible places if you boost your frame-rate to 500FPS...
You can alleviate this by using better integration techniques, such as RK4 instead of Euler's method. However, if you're doing accurate physics, you pretty much have to choose a fixed time-step in order to get reliable results...

IIRC Bullet supports variable time-steps, but sternly warns against using them. However, it's possible to have some parts of your game run at a variable time-step, and other parts (such as your physics) run at some fixed time-step.

you can solve this by not running at a fixed timestep

Variable-length time-steps are an option -- pretty much all of the commercial games that I've worked on have actually used variable-length time-steps -- however, they do have some downsides.

* The delta-time value that you're using for this frame is actually the amount of time that it took to process the previous frame. You're using this as a guess for how long this frame will take, but this guess is wrong in the case where the frame-rate changes.
If your frame-rate isn't constant, then when it jumps up and down, your animation will become jittery. This is because your estimation was wrong, so you presented an image to the screen where the virtual distance moved doesn't actually match up with the physical time passed. You can alleviate this somewhat by smoothing your delta-time measurements.

* Numerical integration techniques (such as pos += velocity * delta) gives different results depending on your time-step. This means that, for example, you may be able to jump a particular obstacle at 60FPS, but not at 30FPS!
You can alleviate this by using better integration techniques, such as RK4 instead of Euler's method. However, if you're doing accurate physics, you pretty much have to choose a fixed time-step in order to get reliable results...

IIRC Bullet supports variable time-steps, but sternly warns against using them. However, it's possible to have some parts of your game run at a variable time-step, and other parts (such as your physics) run at some fixed time-step.