All built in behaviors use dt to keep the game running at the same speed, even when the framerate drops. This is called 'framerate independence': the game speed is independent of the framerate.
The problem is, if too many frames are skipped, moving objects can 'jump' large distances, moving past barriers, or causing different collision patterns with the same scenario.
Often, this can be compensated for by having larger collision areas for objects. It is also possible to use the custom movement plugin to ensure that objects test collisions every X number of pixels they move.
However, in some cases, these steps are not enough. Sometimes, framerate independence will break a game. For example, take a physics puzzle game where the result of the player's actions are required to be constant so that a given playthru can be replayed. Or a gameplay demo that is required to behave consistently no matter what.
In these cases, you basically have to eschew most of C2's built in behaviors, and control movement and collision testing thru per-tick events. The drawback is, the game will run slower if the framerate drops. IIRC, it would also run faster for a user with a high hz monitor.
Pick your poison.