To get to a box versus box test in axis-aligned space, first need to go through line versus box (cuboid) collision test.
Parameters:
1. Need an origin point XYZ.
2. Need an end point (XYZ) using ...
2. ... line slope XYZ.
3. Need bounding box mins (X LEFT, Y TOP, Z NEAR)
4. Need bounding box macs (X RIGHT, Y BOTTOM, Z FAR)
A bounding box is define by 6 planes, each plane with a slope. In axis-aligned space (no angles for cuboid) ...
1. Front face. X left, Y top through X right, Y bottom. Z Near. Check to make sure LINE origin Z <= ZNEAR <= Line end Z (if not, cannot have hit. Collision = False). Calculate LINE at Z Near. Call result Point_At_Plane. If X Left <= Point_At_Plane (X) =< X Right and Y Bottom <= Point_At_Plane (Y) <= Y Bottom. We have collision. Collision point is Point_At_Plane (X) and Point_At_Plane (Y).
2. Blah
3. Blah
4. Blah
5. Blah again? Yes
6. Guess what? Answer is blah. Surprised? No.
In fact, any cuboid can be pulled into axis-aligned space as long as you do the same calc on the line slope.
[I guess after writing this code, the next step is plane versus cube. Quake has entities move in turn, so there is no need for a cube versus cube test for motion. It is plane versus plane. But a plane moving is a cuboid in a way with a Z depth of the motion length. And not really a plane. Looks like might have some of this already worked out. I still want to work through the calks myself step by step, but I don't want to step up to the eventual matrix maths without being able to code the simpler axis-aligned stuff myself.]
Maybe only 16 steps away from being able to write the Worldcraft "carve" tool function. Sigh ..