•      Sign In
• Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

### #Actualfreakchild

Posted 23 May 2012 - 10:06 AM

Just to clarify, but this is why I went on to mention that there could still be a case where you miss a collision if you rely solely on checking for overlap...

If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

Sorry, those last seven words probably could have highlighted the issue further but hey you saw it yourself anyway.  As you can see, the basic point is that if you rely on overlap alone as a means of determining if there was a collision then you do stand a chance of missing some.

I do explain a little about getting around this problem above, but today is a new day so I can maybe focus a little more on it.

One solution is that you can avoid this issue by not doing overlap checking.  If you do the line of motion from corners tests alone then that shouldn't fail you at all because it checks the path of motion - anything in the way is thrown up as a potential collision without fail.

The reason most people don't do that though is because it can result in a lot of potential collisions that involve deeper and more expensive collision tests.  This isn't really that expensive in a 2D box line vs line case to be honest, but even so I think it's better to prune out collisions via a broad phase collision pass anyway, which is really just pulling together a list of potential collisions using a less accurate/cheaper technique before you do the detailed work.

A reasonably accurate way of doing this is by sweeping the box volume along it's path of motion.  This sounds complex, but really to obtain this volume you just consider the start location and the end location of the moving box and connect the two boxes together.  In the case of a box moving down and right, it's shape would be defined by the top-left, top-right and bottom-left corners of the box when at the starting point and the top-right, bottom-right and bottom-left corners of the box when at the end point.

This gives you a six sided 2D object, which you can test for intersection against other objects to give you a pruned and very accurate list of potential collisions, which you then subject to further scrutiny with more detailed checks to find which ones you did actually hit and eventually...the one you hit first.

This is accurate, but I would recommend you use an even broader phase collision sweep just to keep things easier instead.  Rather than establish a six-sided object then work with that, just derive your pruned list from the bounding box encompassing the start and the end boxes.  In the down right moving example, the top left of this box would be the top left of the original collision box at it's start point and the bottom right of the new bounding box would be the bottom right of the original collision box at it's end point.

(side note: The description above is really a way of describing the geometry of the new box and not really an algorithm.  Don't write a function to create the new box by considering the direction it was travelling to pinpoint the new top-left and bottom right.  Yes, you could do that...but really it's best to write a general purpose function that creates a new box from the extents of two boxes regardless of where they are located.  This is a 'best fit' algorithm which can be complex with other geometry but in the case of oriented boxes is actually very simple.)

This bigger box is less accurate than a true swept volume (the six sided object) because it covers a larger area.  So you'll get a pruned list of potential collisions sampled from the same region some of which may not even represent a collision because they are 'off' the swept path.  Generally, you'll get a longer list then...but the cost of obtaining this data will be a little cheaper than testing for intersections on a six-sided object and the code is easier and typically will be quicker.

Note that any broad phase pass does prune and offer a list of 'potential' collisions.  As I hint at above...some will not actually be collisions, they'll just be pulled in via the broad phase pass.  The key point...any broad phase pass is going to be inaccurate and subsequent tests or passes should be aware that some of the potential collisions are not that.  Plan to discard these.  All will have to be processed to find if they are a collision or not...and to find which one of them is the first collision.

Bear in mind that you could (if you wish) use this box based broad phase pass to get the least accurate list and then further prune that list via deriving the six sided object.  It's not uncommon for collision detection functions to do this.  I wouldn't recommend it for you, but at least you can if you want.  I say it more to pass on some theory.  You would generally do this sort of thing if your final intersection tests on your final pruned list are very expensive and you want to make sure you're spending your processing resources on the absolutely minimal set.

Either way, the above will solve the sweeping problem you saw.  You can likely combine this with a first 'overlap' test because if that does get a positive, it will be your first potential collision.  Detecting for overlap, then broad phasing and finding 0 other candidates would be an appropriate 'early out'...really you'd be saying 'I have found one collision in the easiest cheapest manner and I have proven nothing has been missed out, so I'm okay to rely on the overlap'.

If I were you, then if you are doing all this I would still focus on initial overlap and rewind/cast lines first before adding the broad phase in.  Don't get me wrong...you will likely need the broad phase, but there's a logical sequence to follow in order to make all this easier to develop.  Just make sure you consider the idea you're dealing with multiple objects, so you'll always want to be iterating through some list even if the first overlap test puts only one potential collision in that list.  In that way, you're broad phase pass can just insert objects into the same list.  Make sure your object to object collision tests are strong and detects the first point of collision between the two objects and make sure you can keep the results of that around, so you can compare with other objects in the list.  You can optimize the memory wasted by keeping results around...by only keeping the most relevant one around, which is really a case of discarding anything other than what you know to be the nearest collision, which at any one time is the only candidate for the first collision (when iterating through many potentials).

I'll just add one more point too.  What I've described here is really a test and rewind initially, with sweeping added - really it's now simple test, sweep/broad test then rewind and sweep forward with lines (based on a pruned list).  Bear in mind that there is an alternative to sweeping forward...I have actually moved objects and then cast the lines backwards along the lines of motion in the past.  It's really the same thing just in the other direction...but some people can find this convenient it depends on how they've set things up.

### #6freakchild

Posted 23 May 2012 - 10:01 AM

Just to clarify, but this is why I went on to mention that there could still be a case where you miss a collision if you rely solely on checking for overlap...

If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

Sorry, those last seven words probably could have highlighted the issue further but hey you saw it yourself anyway.  As you can see, the basic point is that if you rely on overlap alone as a means of determining if there was a collision then you do stand a chance of missing some.

I do explain a little about getting around this problem above, but today is a new day so I can maybe focus a little more on it.

One solution is that you can avoid this issue by not doing overlap checking.  If you do the line of motion from corners tests alone then that shouldn't fail you at all because it checks the path of motion - anything in the way is thrown up as a potential collision without fail.

The reason most people don't do that though is because it can result in a lot of potential collisions that involve deeper and more expensive collision tests.  This isn't really that expensive in a 2D box line vs line case to be honest, but even so I think it's better to prune out collisions via a broad phase collision pass anyway, which is really just pulling together a list of potential collisions using a less accurate/cheaper technique before you do the detailed work.

A reasonably accurate way of doing this is by sweeping the box volume along it's path of motion.  This sounds complex, but really to obtain this volume you just consider the start location and the end location of the moving box and connect the two boxes together.  In the case of a box moving down and right, it's shape would be defined by the top-left, top-right and bottom-left corners of the box when at the starting point and the top-right, bottom-right and bottom-left corners of the box when at the end point.

This gives you a six sided 2D object, which you can test for intersection against other objects to give you a pruned and very accurate list of potential collisions, which you then subject to further scrutiny with more detailed checks to find which ones you did actually hit and eventually...the one you hit first.

This is accurate, but I would recommend you use an even broader phase collision sweep just to keep things easier instead.  Rather than establish a six-sided object then work with that, just derive your pruned list from the bounding box encompassing the start and the end boxes.  In the down right moving example, the top left of this box would be the top left of the original collision box at it's start point and the bottom right of the new bounding box would be the bottom right of the original collision box at it's end point.

(side note: The description above is really a way of describing the geometry of the new box and not really an algorithm.  Don't write a function to create the new box by considering the direction it was travelling to pinpoint the new top-left and bottom right.  Yes, you could do that...but really it's best to write a general purpose function that creates a new box from the extents of two boxes regardless of where they are located.  This is a 'best fit' algorithm which can be complex with other geometry but in the case of oriented boxes is actually very simple.)

This bigger box is less accurate than a true swept volume (the six sided object) because it covers a larger area.  So you'll get a pruned list of potential collisions sampled from the same region some of which may not even represent a collision because they are 'off' the swept path.  Generally, you'll get a longer list then...but the cost of obtaining this data will be a little cheaper than testing for intersections on a six-sided object and the code is easier and typically will be quicker.

Note that any broad phase pass does prune and offer a list of 'potential' collisions.  As I hint at above...some will not actually be collisions, they'll just be pulled in via the broad phase pass.  The key point...any broad phase pass is going to be inaccurate and subsequent tests or passes should be aware that some of the potential collisions are not that.  Plan to discard these.  All will have to be processed to find if they are a collision or not...and to find which one of them is the first collision.

Bear in mind that you could (if you wish) use this box based broad phase pass to get the least accurate list and then further prune that list via deriving the six sided object.  It's not uncommon for collision detection functions to do this.  I wouldn't recommend it for you, but at least you can if you want.  I say it more to pass on some theory.  You would generally do this sort of thing if your final intersection tests on your final pruned list are very expensive and you want to make sure you're spending your processing resources on the absolutely minimal set.

Either way, the above will solve the sweeping problem you saw.  You can likely combine this with a first 'overlap' test because if that does get a positive, it will be your first potential collision.  Detecting for overlap, then broad phasing and finding 0 other candidates would be an appropriate 'early out'...really you'd be saying 'I have found one collision in the easiest cheapest manner and I have proven nothing has been missed out, so I'm okay to rely on the overlap'.

If I were you, then if you are doing all this I would still focus on initial overlap and rewind/cast lines first before adding the broad phase in.  Don't get me wrong...you will likely need the broad phase, but there's logical sequence to follow in order to make all this easier to develop.  Just make sure you consider the idea you're dealing with multiple objects, so you'll always want to be iterating through some list even if the first overlap test puts only one potential collision in that list.  In that way, you're broad phase pass can just insert objects into the same list.  Make sure your object to object is strong and detects the first point of collision between two objects and make sure you can get the results of that around, so you can compare with other objects in the list.

I'll just add one more point too.  What I've described here is really a test and rewind initially, with sweeping added - really it's now simple test, sweep/broad test then rewind and sweep forward with lines.  Bear in mind that there is an alternative to sweeping forward...I have actually moved objects and then cast the lines backwards along the lines of motion in the past.  It's really the same thing just in the other direction...but some people can find this convenient it depends on how they've set things up.

### #5freakchild

Posted 23 May 2012 - 09:59 AM

Just to clarify, but this is why I went on to mention that there could still be a case where you miss a collision if you rely solely on checking for overlap...

If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

Sorry, those last seven words probably could have highlighted the issue further but hey you saw it yourself anyway.  As you can see, the basic point is that if you rely on overlap alone as a means of determining if there was a collision then you do stand a chance of missing some.

I do explain a little about getting around this problem above, but today is a new day so I can maybe focus a little more on it.

One solution is that you can avoid this issue by not doing overlap checking.  If you do the line of motion from corners tests alone then that shouldn't fail you at all because it checks the path of motion - anything in the way is thrown up as a potential collision without fail.

The reason most people don't do that though is because it can result in a lot of potential collisions that involve deeper and more expensive collision tests.  This isn't really that expensive in a 2D box line vs line case to be honest, but even so I think it's better to prune out collisions via a broad phase collision pass anyway, which is really just pulling together a list of potential collisions using a less accurate/cheaper technique before you do the detailed work.

A reasonably accurate way of doing this is by sweeping the box volume along it's path of motion.  This sounds complex, but really to obtain this volume you just consider the start location and the end location of the moving box and connect the two boxes together.  In the case of a box moving down and right, it's shape would be defined by the top-left, top-right and bottom-left corners of the box when at the starting point and the top-right, bottom-right and bottom-left corners of the box when at the end point.

This gives you a six sided 2D object, which you can test for intersection against other objects to give you a pruned and very accurate list of potential collisions, which you then subject to further scrutiny with more detailed checks to find which ones you did actually hit and eventually...the one you hit first.

This is accurate, but I would recommend you use an even broader phase collision sweep just to keep things easier instead.  Rather than establish a six-sided object then work with that, just derive your pruned list from the bounding box encompassing the start and the end boxes.  In the down right moving example, the top left of this box would be the top left of the original collision box at it's start point and the bottom right of the new bounding box would be the bottom right of the original collision box at it's end point.

(side note: The description above is really a way of describing the geometry of the new box and not really an algorithm.  Don't write a function to create the new box by considering the direction it was travelling to pinpoint the new top-left and bottom right.  Yes, you could do that...but really it's best to write a general purpose function that creates a new box from the extents of two boxes regardless of where they are located.  This is a 'best fit' algorithm which can be complex with other geometry but in the case of oriented boxes is actually very simple.)

This is less accurate because it covers a wider area than the six sided object and so you'll get a pruned list of potential collisions sampled from the same, some of which mat not even represent a collision.  Generally, you'll get a longer list then...but the cost of obtaining this data will be a little cheaper than testing for intersections on a six-sided object and the code is easier.

Note that any broad phase pass does prune and offer a list of 'potential' collisions.  As I hint at above...some will not actually be collisions, they'll just be pulled in via the broad phase pass.  The key point...any broad phase pass is going to be inaccurate and subsequent tests or passes should be aware that some of the potential collisions are not that.  Plan to discard these.  All will have to be processed to find if they are a collision or not...and to find which one of them is the first collision.

Bear in mind that you could (if you wish) use this box based broad phase pass to get the least accurate list and then further prune that list via deriving the six sided object.  It's not uncommon for collision detection functions to do this.  I wouldn't recommend it for you, but at least you can if you want.  I say it more to pass on some theory.  You would generally do this sort of thing if your final intersection tests on your final pruned list are very expensive and you want to make sure you're spending your processing resources on the absolutely minimal set.

Either way, the above will solve the sweeping problem you saw.  You can likely combine this with a first 'overlap' test because if that does get a positive, it will be your first potential collision.  Detecting for overlap, then broad phasing and finding 0 other candidates would be an appropriate 'early out'...really you'd be saying 'I have found one collision in the easiest cheapest manner and I have proven nothing has been missed out, so I'm okay to rely on the overlap'.

If I were you, then if you are doing all this I would still focus on initial overlap and rewind/cast lines first before adding the broad phase in.  Don't get me wrong...you will likely need the broad phase, but there's logical sequence to follow in order to make all this easier to develop.  Just make sure you consider the idea you're dealing with multiple objects, so you'll always want to be iterating through some list even if the first overlap test puts only one potential collision in that list.  In that way, you're broad phase pass can just insert objects into the same list.  Make sure your object to object is strong and detects the first point of collision between two objects and make sure you can get the results of that around, so you can compare with other objects in the list.

I'll just add one more point too.  What I've described here is really a test and rewind initially, with sweeping added - really it's now simple test, sweep/broad test then rewind and sweep forward with lines.  Bear in mind that there is an alternative to sweeping forward...I have actually moved objects and then cast the lines backwards along the lines of motion in the past.  It's really the same thing just in the other direction...but some people can find this convenient it depends on how they've set things up.

### #4freakchild

Posted 23 May 2012 - 09:58 AM

Just to clarify, but this is why I went on to mention that there could still be a case where you miss a collision if you rely solely on checking for overlap...

If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

Sorry, those last seven words probably could have highlighted the issue further but hey you saw it yourself anyway.  As you can see, the basic point is that if you rely on overlap alone as a means of determining if there was a collision then you do stand a chance of missing some.

I do explain a little about getting around this problem above, but today is a new day so I can maybe focus a little more on it.

One solution is that you can avoid this issue by not doing overlap checking.  If you do the line of motion from corners tests alone then that shouldn't fail you at all because it checks the path of motion - anything in the way is thrown up as a potential collision without fail.

The reason most people don't do that though is because it can result in a lot of potential collisions that involve deeper and more expensive collision tests.  This isn't really that expensive in a 2D box line vs line case to be honest, but even so I think it's better to prune out collisions via a broad phase collision pass anyway, which is really just pulling together a list of potential collisions using a less accurate/cheaper technique before you do the detailed work.

A reasonably accurate way of doing this is by sweeping the box volume along it's path of motion.  This sounds complex, but really to obtain this volume you just consider the start location and the end location of the moving box and connect the two boxes together.  In the case of a box moving down and right, it's shape would be defined by the top-left, top-right and bottom-left corners of the box when at the starting point and the top-right, bottom-right and bottom-left corners of the box when at the end point.

This gives you a six sided 2D object, which you can test for intersection against other objects to give you a pruned and very accurate list of potential collisions, which you then subject to further scrutiny with more detailed checks to find which ones you did actually hit and eventually...the one you hit first.

This is accurate, but I would recommend you use an even broader phase collision sweep just to keep things easier instead.  Rather than establish a six-sided object then work with that, just derive your pruned list from the bounding box encompassing the start and the end boxes.  In the down right moving example, the top left of this box would be the top left of the original collision box at it's start point and the bottom right of the new bounding box would be the bottom right of the original collision box at it's end point.

(side note: The description above is really a way of describing the geometry of the new box and not really an algorithm.  Don't write a function to create the new box by considering the direction it was travelling to pinpoint the new top-left and bottom right.  Yes, you could do that...but really it's best to write a general purpose function that creates a new box from the extents of two boxes regardless of where they are located.  This is a 'best fit' algorithm which is really simple when considering oriented boxes.)

This is less accurate because it covers a wider area than the six sided object and so you'll get a pruned list of potential collisions sampled from the same, some of which mat not even represent a collision.  Generally, you'll get a longer list then...but the cost of obtaining this data will be a little cheaper than testing for intersections on a six-sided object and the code is easier.

Note that any broad phase pass does prune and offer a list of 'potential' collisions.  As I hint at above...some will not actually be collisions, they'll just be pulled in via the broad phase pass.  The key point...any broad phase pass is going to be inaccurate and subsequent tests or passes should be aware that some of the potential collisions are not that.  Plan to discard these.  All will have to be processed to find if they are a collision or not...and to find which one of them is the first collision.

Bear in mind that you could (if you wish) use this box based broad phase pass to get the least accurate list and then further prune that list via deriving the six sided object.  It's not uncommon for collision detection functions to do this.  I wouldn't recommend it for you, but at least you can if you want.  I say it more to pass on some theory.  You would generally do this sort of thing if your final intersection tests on your final pruned list are very expensive and you want to make sure you're spending your processing resources on the absolutely minimal set.

Either way, the above will solve the sweeping problem you saw.  You can likely combine this with a first 'overlap' test because if that does get a positive, it will be your first potential collision.  Detecting for overlap, then broad phasing and finding 0 other candidates would be an appropriate 'early out'...really you'd be saying 'I have found one collision in the easiest cheapest manner and I have proven nothing has been missed out, so I'm okay to rely on the overlap'.

If I were you, then if you are doing all this I would still focus on initial overlap and rewind/cast lines first before adding the broad phase in.  Don't get me wrong...you will likely need the broad phase, but there's logical sequence to follow in order to make all this easier to develop.  Just make sure you consider the idea you're dealing with multiple objects, so you'll always want to be iterating through some list even if the first overlap test puts only one potential collision in that list.  In that way, you're broad phase pass can just insert objects into the same list.  Make sure your object to object is strong and detects the first point of collision between two objects and make sure you can get the results of that around, so you can compare with other objects in the list.

I'll just add one more point too.  What I've described here is really a test and rewind initially, with sweeping added - really it's now simple test, sweep/broad test then rewind and sweep forward with lines.  Bear in mind that there is an alternative to sweeping forward...I have actually moved objects and then cast the lines backwards along the lines of motion in the past.  It's really the same thing just in the other direction...but some people can find this convenient it depends on how they've set things up.

### #3freakchild

Posted 23 May 2012 - 09:57 AM

Just to clarify, but this is why I went on to mention that there could still be a case where you miss a collision if you rely solely on checking for overlap...

If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

Sorry, those last seven words probably could have highlighted the issue further but hey you saw it yourself anyway.  As you can see, the basic point is that if you rely on overlap alone as a means of determining if there was a collision then you do stand a chance of missing some.

I do explain a little about getting around this problem above, but today is a new day so I can maybe focus a little more on it.

One solution is that you can avoid this issue by not doing overlap checking.  If you do the line of motion from corners tests alone then that shouldn't fail you at all because it checks the path of motion - anything in the way is thrown up as a potential collision without fail.

The reason most people don't do that though is because it can result in a lot of potential collisions that involve deeper and more expensive collision tests.  This isn't really that expensive in a 2D box line vs line case to be honest, but even so I think it's better to prune out collisions via a broad phase collision pass anyway, which is really just pulling together a list of potential collisions using a less accurate/cheaper technique before you do the detailed work.

A reasonably accurate way of doing this is by sweeping the box volume along it's path of motion.  This sounds complex, but really to obtain this volume you just consider the start location and the end location of the moving box and connect the two boxes together.  In the case of a box moving down and right, it's shape would be defined by the top-left, top-right and bottom-left corners of the box when at the starting point and the top-right, bottom-right and bottom-left corners of the box when at the end point.

This gives you a six sided 2D object, which you can test for intersection against other objects to give you a pruned and very accurate list of potential collisions, which you then subject to further scrutiny with more detailed checks to find which ones you did actually hit and eventually...the one you hit first.

This is accurate, but I would recommend you use an even broader phase collision sweep just to keep things easier instead.  Rather than establish a six-sided object then work with that, just derive your pruned list from the bounding box encompassing the start and the end boxes.  In the down right moving example, the top left of this box would be the top left of the original collision box at it's start point and the bottom right of the new bounding box would be the bottom right of the original collision box at it's end point.

(side note: The description above is really a way of describing the geometry of the new box and not really an algorithm.  Don't write a function to create the new box by considering the direction it was travelling to pinpoint the new top-left and bottom right.  Yes, you could do that...but really it's best to write a general purpose function that creates a new box from the extents of two boxes regardless of where they are located.  This is a 'best fit' algorithm which is really simple when considering oriented boxes.)

This is less accurate because it covers a wider area than the six sided object and so you'll get a pruned list of potential collisions sampled from the same, some of which mat not even represent a collision.  Generally, you'll get a longer list then...but the cost of obtaining this data will be a little cheaper than testing for intersections on a six-sided object and the code is easier.

Note that any broad phase pass does prune and offer a list of 'potential' collisions.  As I hint at above...some will not actually be collisions, they'll just be pulled in via the broad phase pass.  The key point...any broad phase pass is going to be inaccurate and subsequent tests or passes should be aware that some of the potential collisions are not that.  Plan to discard these.  All will have to be processed to find if they are a collision or not...and to find which one of them is the first collision.

Bear in mind that you could (if you wish) use this box based broad phase pass to get the least accurate list and then further prune that list via deriving the six sided object.  It's not uncommon for collision detection functions to do this.  I wouldn't recommend it for you, but at least you can if you want.  I say it more to pass on some theory.  You would generally do this sort of thing if your final intersection tests on your final pruned list are very expensive and you want to make sure you're spending your processing resources on the absolutely minimal set.

Either way, the above will solve the sweeping problem you saw.  You can likely combine this with a first 'overlap' test because if that does get a positive, it will be your first potential collision.  Detecting for overlap, then broad phasing and finding 0 other candidates would be an appropriate 'early out'...really you'd be saying 'I have found one collision in the easiest cheapest manner and I have proven nothing has been missed out, so I'm okay to rely on the overlap'.

If I were you, then if you are doing all this I would still focus on initial overlap and rewind/cast lines first before adding the broad phase in.  Don't get me wrong...you will likely need the broad phase, but there's logical sequence to follow in order to make all this easier to develop.  Just make sure you consider the idea you're dealing with multiple objects, so you'll always want to be iterating through some list even if the first overlap test puts only one potential collision in that list.  In that way, you're broad phase pass can just insert objects into the same list.  Make sure your object to object is strong and detects the first point of collision between two objects and make sure you can get the results of that around, so you can compare with other objects in the list.

I'll just add one more point too.  What I've described here is really a test and rewind initially, with sweeping added - really it's now simple test, sweep/broad test then rewind and sweep forward with lines.  Bear in mind that there is an alternative to sweeping forward...I have actually moved objects and then cast the lines backwards along the lines of motion in the past.  It's really the same thing just in the other direction...but some people can find this convenient it depends on how they've set things up.

### #2freakchild

Posted 23 May 2012 - 09:49 AM

Just to clarify, but this is why I went on to mention that there could still be a case where you miss a collision if you rely solely on checking for overlap...

If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

Sorry, those last seven words probably could have highlighted the issue further but hey you saw it yourself anyway.  As you can see, the basic point is that if you rely on overlap alone as a means of determining if there was a collision then you do stand a chance of missing some.

I do explain a little about getting around this problem above, but today is a new day so I can maybe focus a little more on it.

One solution is that you can avoid this issue by not doing overlap checking.  If you do the line of motion from corners tests alone then that shouldn't fail you at all because it checks the path of motion - anything in the way is thrown up as a potential collision without fail.

The reason most people don't do that though is because it can result in a lot of potential collisions that involve deeper and more expensive collision tests.  This isn't really that expensive in a 2D box line vs line case to be honest, but even so I think it's better to prune out collisions via a broad phase collision pass anyway, which is really just pulling together a list of potential collisions using a less accurate/cheaper technique before you do the detailed work.

A reasonably accurate way of doing this is by sweeping the box volume along it's path of motion.  This sounds complex, but really to obtain this volume you just consider the start location and the end location of the moving box and connect the two boxes together.  In the case of a box moving down and right, it's shape would be defined by the top-left, top-right and bottom-left corners of the box when at the starting point and the top-right, bottom-right and bottom-left corners of the box when at the end point.

This gives you a six sided 2D object, which you can test for intersection against other objects to give you a pruned and very accurate list of potential collisions, which you then subject to further scrutiny with more detailed checks to find which ones you did actually hit and eventually...the one you hit first.

This is accurate, but I would recommend you use an even broader phase collision sweep just to keep things easier instead.  Rather than establish a six-sided object then work with that, just derive your pruned list from the bounding box encompassing the start and the end boxes.  In the down right moving example, the top left of this box would be the top left of the original collision box at it's start point and the bottom right of the new bounding box would be the bottom right of the original collision box at it's end point.

This is less accurate because it covers a wider area than the six sided object and so you'll get a pruned list of potential collisions sampled from the same, some of which mat not even represent a collision.  Generally, you'll get a longer list then...but the cost of obtaining this data will be a little cheaper than testing for intersections on a six-sided object and the code is easier.

Note that any broad phase pass does prune and offer a list of 'potential' collisions.  As I hint at above...some will not actually be collisions, they'll just be pulled in via the broad phase pass.  The key point...any broad phase pass is going to be inaccurate and subsequent tests or passes should be aware that some of the potential collisions are not that.  Plan to discard these.  All will have to be processed to find if they are a collision or not...and to find which one of them is the first collision.

Bear in mind that you could (if you wish) use this box based broad phase pass to get the least accurate list and then further prune that list via deriving the six sided object.  It's not uncommon for collision detection functions to do this.  I wouldn't recommend it for you, but at least you can if you want.  I say it more to pass on some theory.  You would generally do this sort of thing if your final intersection tests on your final pruned list are very expensive and you want to make sure you're spending your processing resources on the absolutely minimal set.

Either way, the above will solve the sweeping problem you saw.  You can likely combine this with a first 'overlap' test because if that does get a positive, it will be your first potential collision.  Detecting for overlap, then broad phasing and finding 0 other candidates would be an appropriate 'early out'...really you'd be saying 'I have found one collision in the easiest cheapest manner and I have proven nothing has been missed out, so I'm okay to rely on the overlap'.

If I were you, then if you are doing all this I would still focus on initial overlap and rewind/cast lines first before adding the broad phase in.  Don't get me wrong...you will likely need the broad phase, but there's logical sequence to follow in order to make all this easier to develop.  Just make sure you consider the idea you're dealing with multiple objects, so you'll always want to be iterating through some list even if the first overlap test puts only one potential collision in that list.  In that way, you're broad phase pass can just insert objects into the same list.  Make sure your object to object is strong and detects the first point of collision between two objects and make sure you can get the results of that around, so you can compare with other objects in the list.

I'll just add one more point too.  What I've described here is really a test and rewind initially, with sweeping added - really it's now simple test, sweep/broad test then rewind and sweep forward with lines.  Bear in mind that there is an alternative to sweeping forward...I have actually moved objects and then cast the lines backwards along the lines of motion in the past.  It's really the same thing just in the other direction...but some people can find this convenient it depends on how they've set things up.

PARTNERS