When handling collisons, calculate colliding objects and their time of impact sort by time of impact, process the first impact by advancing the simulation to that point and solving the collision.
You then iterate until there are no collisions or you run out of time in the timestep (or you hit a max number of iterations in which case bad things might happen).
For example, in a game of pool, if your time step is 2 and two balls collide at time 1.2, then the balls positions are upated to where they would be at that intermediate time, the two balls that collide would update their velocities. That collision results in one of the balls hitting a third ball at time 1.75, using the new velocities the balls would be updated to time 1.75, assuming no more collisions occur the balls would be updated the remaining 0.25 and you'd be done.
By only updating the simulation to the time of impact and updating velocities then iterating you get around the problem of fixing penetrations which then push objects into other objects.
Thanks for the explanation. I have never used time step before, is it a cool trick or best practices? Is it fine to update non physics and physics by a differing number of times per frame like that? I've never paid much attention to time before. Currently I just have a loop that calls game update once per frame, and game update would do logic stuff, and move the objects by a little bit. Then game draw is called, and a timer function will wait for some time to make the game run at 60fps.
OP asked about "collision handling". Everyone seems to be replying with the assumption that he meant "generic physics solving".
My fault, I noticed my questions are not that clear, swaying from collision handling to oder of operations, to definition of constraint solver, stc...
To me, the most puzzling thing about collision handling is how to gracefully organize the collision-handling game logic in such a way that you don't have to repeat yourself all over the place.
Take SMB3 -era Mario, for instance. There are a ton of different enemies, different tiles, different powerups in the game. Enemies may have alternate states like "stunned" which change what it means to collide with them. Mario himself has a zillion different states, like small, big, invulnerable, stealthed, etc. Finally, the direction of the collision is often significant in determining the result. A big-Mario-on-breakable-tile collision will only break the tile if Mario hits from under the tile. A normal-Mario-on-normal-Goomba collision kills the Goomba if Mario hits from above, and kills Mario otherwise.
How would you guys deal with this?
The impossibly naive way would be to have a class for each enemy type, a class for Mario's every possible form, and a collision handler function for each class combination. That would result in M*E handler functions - hundreds of functions - just for Mario-enemy collisions. Most lines of code in those functions would repeat hundreds of times in the project. Also, every time you wanted to add any new object that is only slightly different than an existing one, you'd need a new function for every single object that may collide with the new one.
Nice of you to share your experiences. The way I handle it is to have a single generic game object class, and fill it with details instead of making a sperate class for every little thing. Inheritance is cool, but I won't use it just for the sake of using it. Another OOP solution is the composite pattern, I think thats where you have an object that is combination of multiple objects. But now I am going offtopic ;o