JoeJ said:
Edit: Looking more closely i see you have no smaller timestep, because you ignore the reminder of dt/someVerySmallValue.

I'm not sure of what remainder there would be: I'm not using division, and even if I was, it would be floating-point division, and thus include the remainder.

(There might be some loss to floating-point precision, but that should be minimal, and be accounted for in subsequent steps due to the target-distance being slightly higher or lower than it should be.)

JoeJ said:
Yes, if you subdivide timestep, you should apply this to all variables affected from this timestep.

One thing that I'll note here is that I'm not applying the division to all objects. For example, enemies do not use the divided time-step. It's currently only used for the player's (and thus the target's) position and velocity-handling (excluding player-control), and for the camera's position.

Thus far I haven't seen any ill effects of this, at least.

Thaumaturge said:
I'm not sure of what remainder there would be

I'll make an example by commenting your code…

def updatePlayer(dt):

    newDt = dt 

// newDt = 4.01
// someVerySmallValue = 2

    while newDt > someVerySmallValue:
        # Update both target and camera by a small, fixed increment
        position += velocity * someVerySmallValue
        updateCamera(someVerySmallValue)
        # Keep doing so until the total delta-time for the frame is all-but
        # used up
        newDt -= someVerySmallValue 
// newDt = 0.01 (which i meant with reminder of dt/someVerySmallValue)

    # Perform the update one more time, using whatever delta-time remains
// here we integrate this left but small time of 0.01
    position += velocity * newDt 
    updateCamera(newDt) 

(btw, i realize i was confused and should not have made the edit to my post, but i got it right initially.)

Now the problem is you integrate those timesteps: 2, 2, 0.01. This can eventually cause problems like motion looking not as smooth as it could be.
Following my proposal you would get: 2.005, 2.005. Which should end up more smooth.

Thaumaturge said:
One thing that I'll note here is that I'm not applying the division to all objects. For example, enemies do not use the divided time-step.

That's fine of coarse, because enemies are no variables affecting our current subdivision of time, which only depends on player and camera stuff.

Though, you may want to use the same strategy for the whole game, so it behaves more consistent across different HW which might cause different delta times.
It's also possible to do both, like having ‘someVerySmallValue’ at 1/10 for the games physics which are not very sensitive on dt, but having it at 1/100 for the camera because it is very sensitive. (just to make some random example)
And if you did this, it could end up recursive eventually, like slicing the whole game by 1/10, which calls the camera update, which slices at 1/100.
In such case a small timestep from a reminder would propagate down to subroutines and cause problems much more likely. Thus i always do the proposed rounding for such things.

Hmm… Okay, I think that I see what you're saying, indeed. Thank you for the explanation!

That said, thus far movement has felt nicely smooth. I'm thus hesitant to rework things on the basis that an issue might appear.

Still, I might give it further consideration at a later stage!

As to other objects, my intuition is that it shouldn't be a problem; any inconsistency between, for example, enemy behaviour on different platforms should be minimal and harmless, I would think.