There's no "*may*" about it, and it doesn't depend on what you're doing with it, or how it's written. If you try to do integration ( and if you know of a physics engine which doesn't, then please mention it, because I don't know any ) with a variable timestep, you will get unpredictable, unstable results which will lead to serious physics errors.
Doing almost fixed logic is like having an almost-vegetarian ham sandwich because the bread, butter, mayo and lettuce are all vegetarian. The whole purpose of fixed-rate logic is to ensure that your logic is *always* run with a fixed timestep, in order that the physics can be reliable and stable. There's no near, you either do or don't.
Take that fixed step away and what you have is delta timing. Delta timing which is decoupled from the rendering for a higher update frequency, but still delta timing. Delta timing is, of course, smoother than fixed rate logic *without* tweening, because fixed rate logic is not supposed to be smooth. Fixed rate logic is not about smooth visual updates, it's about consistent behaviour across machines. That's why it's almost always combined with tweening.
Doing almost fixed logic is like having an almost-vegetarian ham sandwich because the bread, butter, mayo and lettuce are all vegetarian. The whole purpose of fixed-rate logic is to ensure that your logic is *always* run with a fixed timestep, in order that the physics can be reliable and stable. There's no near, you either do or don't.
Take that fixed step away and what you have is delta timing. Delta timing which is decoupled from the rendering for a higher update frequency, but still delta timing. Delta timing is, of course, smoother than fixed rate logic *without* tweening, because fixed rate logic is not supposed to be smooth. Fixed rate logic is not about smooth visual updates, it's about consistent behaviour across machines. That's why it's almost always combined with tweening.