I feel like this may have gone full circle...
Could anyone offer any solutions to the original problem at hand?
I feel like this may have gone full circle...
Could anyone offer any solutions to the original problem at hand?
I feel like this may have gone full circle...
Could anyone offer any solutions to the original problem at hand?
Did this link not answer your problems? Specifically:
"Because we don't want the player (or any other fast moving object) passing though platforms if they move too quickly, the fine grained collision detection system, or narrow phase, must be good enough to prevent this from happening."
Have a look at the "Collision detection" section on the second part of the platformer tutorial from paul (prev post from BeerNutts).
There you have the simplest possible solution achieving a cheap continuous collision solution using a tilebased system.
The only thing you have to do is to calculate the closest point+distance on a minkowski-sum aabb (tile aabb extended by the player aabb).
Another approach is to calculate the time when a line segment from a tile hits the movement line of a player - also using minkowski sum.
This is fully explained in the collision series of handhand hero, see:
https://hero.handmadedev.org/videos/game-architecture/day043.html (The Equations of Motion)
https://hero.handmadedev.org/videos/game-architecture/day045.html (Geometric vs. Temporal Movement Search)
https://hero.handmadedev.org/videos/game-architecture/day048.html (Line Segment Intersection Collisions)
https://hero.handmadedev.org/videos/game-architecture/day050.html (Basic Minkowski-based Collision Detection)
Thanks for the replies!
So I've read over that wildbunny article quite a few times, and I simply just don't understand it. I understand the concept of speculative contacts,
and how I could possibly be moving so quickly that I completely skip a collision check, but I just don't understand how to put what he's said
into practice, and I definitely don't understand his code as a lot of it is down to assumption. It may seem more obvious if you have experience with
collision detection, but to me, it's very difficult to understand! :)
At the moment, I have a spatial hasher implemented as the furthest and most "abstracted" layer of collision detection.
Once objects are in the same "bucket" of the hasher, a simple loop is used to determine whether the
rectangles intersect. If they do, the code I posted in the original post is executed to adjust the objects
accordingly and move them to where they should be. This all seems to work as intended, but things
are falling through now and again.
Does this mean that it's the higher level check of whether the intersection is happening that should be changed, and not my actual
intersection code? Like, the actual loop that checks to see if the two rectangles intersect needs fixing, and not the actual code that
executes once this condition is met?
Also, is the act of determining whether this collision check should happen referred to as speculative contacts, or do speculative contacts
play an actual role in adjusting the position of the object once it's intersected a tile?
Zuhane, I would also advise you watch these 2 videos form the handmade heros segment, as he discusses possible tunneling as well as the Minkowski Sum for collision, and it makes a lot of sense.
https://hero.handmadedev.org/videos/game-architecture/day048.html (Line Segment Intersection Collisions)
https://hero.handmadedev.org/videos/game-architecture/day050.html (Basic Minkowski-based Collision Detection)
Thanks again for the reply :D I'm not really proficient with C++, so I couldn't get much from those videos. I think
I'll just have to leave this problem and maybe make it into a "glitch feature", or alternatively just shoot myself lol.
I'm amazed there's nothing simpler out there, but I suppose that's just the way it is :(
Thanks again for the reply I'm not really proficient with C++, so I couldn't get much from those videos. I think
I'll just have to leave this problem and maybe make it into a "glitch feature", or alternatively just shoot myself lol.
I'm amazed there's nothing simpler out there, but I suppose that's just the way it is
I know that collisions maybe hard for someone, but its not that big of a deal.
It always boils down to some simple scalar/dot products and some very basic trigonometry and if you dont know this yet - just google "unit circle" + "vector length" + "vector projection" and you will get it. This was the key for me to start solving a lot of collision problems by myself - without any extraordinary math and if you have a specific question, just ask. There are tons of helpful people here.
A possibly simple solution might be to multisample (explained in a sec) objects that are smaller than some value, or their speed is greater than some value. Basically, you could multisample objects that have the potential to tunnel through objects, either just check if their dimension on an axis (or both) is smaller than some value, and then check smultiple positions of that object.
For example, in the bullet's case, when you test for collision, make multiple tests, but with the object having moved only the parital distance it moves in a frame, and check for collision. Repeat once or twice more (depending on size and speed), and you will have resolved your issue.
Maybe this is something you can play with at least, and see if it resolves your issue, then you can work out a solution.
Here's a great page on collisions BTW, it talks about tunneling in section 5 with a multisample mention as well.
This is one of the best explanations of continuous collision detection using bounding boxes that I've seen:
You don't need to use 2 bounding boxes, nor do need to do the splitting into top/bottom and left/right boxes if you don't want, this technique works equally well with a single bounding box and I've used it to great effect in games that I've written.
Doing the same with a single bounding box is explained in this video, although it's explained mostly through code rather than diagrams:
In case the video isn't clear enough, the basic steps (regardless of how many bounding boxes you use) are as follows:
This has been the most arduous process imaginable haha! A huge problem regarding the game's development is that I started
adding loads of new features and complexities in before getting the collision detection working properly. After hours of rigorous testing,
I've deduced that it is indeed the speed of objects moving that is causing the clipping issue, and that smaller objects have less surface area
to check for collision, so in turn have to move even slower that large objects to successfully perform a test.
The hardest part of this problem wasn't figuring out WHAT to do to fix it, but WHY they were clipping in the first place, specifically. I made a few
assumptions before about my code, but it's definitely safe to say that it is the bullet-through-paper problem causing the issue! This feels
like progress, finally :D
I'm also massively hyped to check out this video, adt, as Cave Story is one of my favourite games of all time :D I'll be sure to reply once I've looked
into this further, and I'll most definitely post a solution once I find it myself, so that future readers may be able to fast-track some collision code :)