OK I've been butting my head for way too long now and just can't get past the idea that this article on AABB collision sweep algorithm is just wrong:

http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php?page=3

I implemented it with just one moving box (player) and whabam, I can't move cause I'm colliding with a box on the other end of the map. The heck? It seems to work only if we already know that the two boxes will overlap at the end of the movement.

Problem is with the for loop for each separating axis, which only sets values if the boxes are not overlapping on a given axis but moving towards each other. (A.max(i)<B.min(i) && v<0) . What this effectively means is that if the boxes are either already overlapping or moving away from each on that axis, the algorithm will not modify the given u_0 and u_1, thus falsely claim collision is happening when it's not (since the final check is u0 <= u1).

Or am I just missing something really obvious here . Tell me GameDev!

EDIT: Example case Box A min(0,0,0) max(0.5, 0.5, 0.5) and Box B min(1,0,1) max(1.5,0.5,1.5), displacement of A (0, 0, 0.6 ) . Only Z axis causes collision at "0.8" but since the other times don't get computed due to displacement being 0 on them, it reports it as collision.

Yes, I think you're right. It needs to handle the case where v == 0.0. When the velocity is zero on an axis it's not distinguishing between the constantly overlapping case (which it's defaulting to by initialising u_0 and u_1 the way it is, and the never overlapping case which could just early out by returning false.

I'd also spend a little time thinking about what happens when v is very close to zero, is the algorithm going to produce dodgy results?