The proper term for this type of collision detection is 'Continuous Collision Detection.' The math breaks down when you introduce rotation and you end up having to binary search to find when the collision will occur
For games, there are two different parts of the physics simulation: Integrator and collision detection/response.
The integrator uses a lot of math. It gives the positions of everything at time t and time t+D, where D is the timestep. The integrator functions under the assumption that no collisions occur.
The collision detection/response system takes as input the integrator's output, namely the positions of everything at time t, and at time t+D. It finds the earliest collision, say at time t+d where d < D, and does something about it -- usually changing position and velocity of the objects involved -- and then re-runs the integrator from time t+d to t+D, again stopping to process the earliest collision.
The important point is that your results are "good enough" if the collision detection just assumes objects travel in a straight line at constant velocity between their positions at t and t+D. The exact path is something that's confined to the integrator, and only linear paths exist in the simulation outside of it.
Of course there are various optimizations and corner cases you have to take care of -- like making sure colliding objects don't immediately register a second collision when the integrator is restarted, and bounding the number of collisions an object is allowed to experience per frame (to handle for example a ball resting in a V-shaped cup from alternating collisions between the two pieces of the cup thousands of times per frame).
And you can optimize since you don't actually have to re-run the integrator for objects that didn't change their physics state (position/velocity) due to the collision.
That is indeed the case. I've however seen ray checks used effectively to prevent "tunneling" of objects cheaply since often exact solutions aren't as valuable as something more pragmatic, which solves the most noticeable portion of the problem -- Objects passing straight through walls.
The integrator uses a lot of math. It gives the positions of everything at time t and time t+D, where D is the timestep. The integrator functions under the assumption that no collisions occur.
The collision detection/response system takes as input the integrator's output, namely the positions of everything at time t, and at time t+D. It finds the earliest collision, say at time t+d where d < D, and does something about it -- usually changing position and velocity of the objects involved -- and then re-runs the integrator from time t+d to t+D, again stopping to process the earliest collision.
The important point is that your results are "good enough" if the collision detection just assumes objects travel in a straight line at constant velocity between their positions at t and t+D. The exact path is something that's confined to the integrator, and only linear paths exist in the simulation outside of it.
Of course there are various optimizations and corner cases you have to take care of -- like making sure colliding objects don't immediately register a second collision when the integrator is restarted, and bounding the number of collisions an object is allowed to experience per frame (to handle for example a ball resting in a V-shaped cup from alternating collisions between the two pieces of the cup thousands of times per frame).
And you can optimize since you don't actually have to re-run the integrator for objects that didn't change their physics state (position/velocity) due to the collision.