I'm using IntersectRect to detect collisions. I was wondering if anyone whose used this could tell me how you've gone about it. If you detect collision, and then move it if there's no collision, you could end up moving the two sprites over each other, and then they could be "stuck", because it would always say they were collided and never move them again. If you move before you detect, what do you do when they've collided? Do you move it back so they aren't collided any more? What i am doing currently is this:
move sprite
if collision move the opposite direction that it was moved to begin with.
then draw it
Is the proper way to do it?
I normally would check for collisions first, then move it if there isn't one. You should check for the collision for the location of the object after moving. No matter how you do it, you would need to find the location of the object after the movement. If a collision is detected, then you should prevent the movement and run what ever other code is needed (such as to bounce the object).
Basicly what I said is either way works, it just depends on how you which to write the code. (and you don't want to display it before detecting collisions)
Yes but there is a problem that arises. Take two points. A(10,10) and B(11,10). Now, under your system, you would check collision for collision between A and B, and a correct algorithm would tell you that these two points are not collided. And with your method you would then move point a, say by 1 px on the x-axis. Now the point is A(11,10) B(11,10). Your collision detection would tell you that they're collided. And you would not move them. This is a problem for several reasons. Now, you could never move the object, even if it was to move it back from pointB, because you would be prevented from any movement because they are collided. The object that you are moving thus becomes "stuck", once it collides. Also, if the object is moving by more than one pixel at a time, it has the chance of going much farther over the object its colliding with. If the leading edge of the object is at x = 10, and the leading egde of the other object is at x = 11. When the first object is moved, the collision detection checks out, and then it can be moved by like 10 pixels, whereupon it would overlap the second object, and it would also be stuck.
Maybe i don't understand your method correctly
I am coding a collision detection routine. I think it's going to be pretty fast.
1) I use a unique, and very fast method for determining, handling, and re-positioning in-play-only player bullets.
2) I will use the same technique for objects you're supposed to shoot.
3) outside the game loop, I set all background sprite blue values to even (24 bit color) and all sprites that you shoot at blue values odd
4) I dim a byte array as big as 2x max player bullets to hold blue color samples to be taken at low left and top right of player bullet rect.
The array can be bigger depending on how many sampling points you want per bullet
game loop:
4) background is blitted
5) The 2 blue byte samples are stored in the array of every in-play player bullet low left, top right corner
6) objects you shoot at are blitted
7) blues at rect corners are resampled and compared with blues in the array. If any are different,
do the nested rectangle test and delete bullet / shootable object accordingly
This may not be an answer or anything at all. But for a couple of yeas a go I made a game with had pretty basic colission detection. It is pretty fast to. I don't got time to coment the code wery much now...sorry..but if I have time I will do to night....
Yes but there is a problem that arises. Take two points. A(10,10) and B(11,10). Now, under your system, you would check collision for collision between A and B, and a correct algorithm would tell you that these two points are not collided. And with your method you would then move point a, say by 1 px on the x-axis. Now the point is A(11,10) B(11,10). Your collision detection would tell you that they're collided. And you would not move them. This is a problem for several reasons. Now, you could never move the object, even if it was to move it back from pointB, because you would be prevented from any movement because they are collided. The object that you are moving thus becomes "stuck", once it collides. Also, if the object is moving by more than one pixel at a time, it has the chance of going much farther over the object its colliding with. If the leading edge of the object is at x = 10, and the leading egde of the other object is at x = 11. When the first object is moved, the collision detection checks out, and then it can be moved by like 10 pixels, whereupon it would overlap the second object, and it would also be stuck.
Ok, first of all, you should know I SAID that it wouldn't work for objects bigger then 1,1. As for the not detecting collision, then detecting once it's on it, you should check BEFORE you move if it's gonna hit, then not move if it will.
The changes needed to be made for larger objects would be to make it check the corners of each 'square' to get the angle.. o amke min and max, the problem is the different positions they can be in... which causes the code to be lengthy.
Alright then:
How do you deal with the problem of things stopping before they go into a wall? For example, if i move a car at 10 px per second, and i move it towards a wall, say that when i do this it overlaps the wall by 1 px. The car will then only be able to stop 10 px before the wall. How do you fix this? You could just set the cars position to the walls position + 1. But this is much more complicated than it sounds, for when you use IntersectRect, you don't know which side of the sprite the car is hitting, so you wouldn't know exactly where to put the car. any thoughts?
For a 1*1 object with my collisino detection, it would just be the distance between the objects - angle, if it was bigger then 1*1 you'd need some trigonometry in there.
Don't pay attention to this signature, it's contradictory.
jmiller, i made a bouncing circles project that doesn't use trig.
the process goes like this.
you have your dx and dy, and this is meant to be understood as 'per-frame', and they are floating-point.
s * dx + s * dy = {collision}
solve for s, and figure out what collision 'is'
if s ends up 2.5, for example, this would tell you that 2 full frames from now, plus a half of a frame, there is a collision. the advantage is that you don't need to check for a collision every frame
Try the following:
Each object has collision points AND a collision rect. and you check collision by intersecting the points of object1 with the rect (or a mask) of object2. This would allow nearly pixel-based collision but you only have to check 5-6 points per object.
Exactly. You define some points that will act as collision points. Also you need a collision rect (or mask if you need exact collision).
When checking for collision you loop only through the collision points of the first object and compare if they are in the collision rect of the other object (Or if you use masks if it's a white pixel for example).
Of course if you want to write a fast engine you need to implement more than one collision method. If it's a 3D engine you might want to use a heightmap for object->ground collisions and sphere or rectangular collision for object->object. There are several ways to check collisions and sometimes it's worth to use more than one in a game.
Yes, but the question is still not answered as to how to solve the problem of overlapping, or stopping to many pixels before a collision. Ex when you detect that sprite1 will collide with sprite2, you don't move sprite1, but this makes it so sprite1 can never go right up to sprite2. Like I've said, you could put it within 1px of sprite2 if you detect collision, but the problem is knowing what side of sprite2 sprite 1 hit so you can put within 1px. This is the problem and this is what i want to know.
Uhm, hope I right-understood this.. well your problem doesn't depend on any specific collision detection method so you can still use any of the technics mentioned before.
After finding a future collision you could just change the direction vector and try again.. for example your object is moving straight right into a stone and your function says that it'll hit on this move. So you change the angle to 45° or something and try again. If there's again a collision you might even want to try -45° and finally (if there's still a collision) your object is stuck. If not, just move it towards the new direction and refine your pathfinding.
Of course this hardly depends on what kind of movement you need. In some games ("pong") the object just changes direction. It depends on you how exact you'll implement this feature, ie. you could just invert the direction when detecting a future collision. You could also invert the direction and move the object to the other object so they touch each other. Correct would be to calculate how much it'll move away from the other object after the collision and set the new position there (and of course invert the direction).
However, in most cases it's good enough not to move the object when detecting a collision and just change directions.
If your having trouble Colliding too far away and having a gap then all i can suggest is to halve the speed of your sprite and double the halve the movement timer (Assuming this is what your doing) this way you double your calculations.
I know what you mean.
You want to know what'll happen if these bodies accidently get inside eachother then they'll remain stuck.
You could first check for a collision. Make ur own subroutine:
Check, for the 4 points of any one rect, if it lies within the other one (another subroutine for that)
Now find out the min distance for any one such point(intersecting) from the nearest wall, and move it exactly that(or a little more) amount in the opp dir. this sure solved my problem !
Hope it does urs !
all the best
I'm not gonna give you my IP address! Ok... Portugal, South-Western Europe, 3rd rock from the sun (our star is easy to find, a 47 Ursae Majoris in the Milky Way :p )
Posts
1,457
Hi all, I saw this topic here (yes I still surf the forums once in a while ) and thought that since I had this problem too when I made my first game, maybe I could help you out with my experience
Ok, you know that when objects move too fast they can overlap each other and stuff. Sooo, either you check for collisions in every position between the current position of the object and where its gonna move to in this frame, or you find a method that does that for you without any loops (ie: some smart trig calculations).
The first method is not that hard at all. You can find the distance between the 2 points, right? So, if you divide the X/Y Speeds or whatever (how much the object moves in this frame) by the distance, you get a new set of "speeds", that is, how much you have to move to move one pixel at a time. I know it sounds kinda confusing but its also known as normalizing a vector (in this case, the speed vector).
Now, if you have a loop that goes from 1 to the distance, and in each step you move the object by this amount and check for collision, you not only NEVER overlap another object, but you also know exactly where the object stops
The second methos is easier, from the copy-and-paste point of view. It's a piece of code I found on gamasutra.com. It works for circle collisions, which I like a lot more than box collisions (its much more reallistic), and is extremely fast (no loops like the above technique). Anyways, I got a really neat implementation of that C++ code that you might be interested in (btw, I'm not using any Vector class or stuff like that, it's all in the same piece of code and highly reuseable).
Oh, I just had a great idea, what about using collision circles for the different parts of a body or a spaceship or a car, and based on what circle collides with an enemy or a bullet, have damage applied only in that part? (ex.: head shots, a wheel jumping off the car chassis, a wing or reactor being disabled in a space ship)
To learn how to use realistic effects in your games like fire, rain, snow and magic effects, read my article on particles systemshere.
Jotaf's Theories!
"Cats land on their feet. Toast lands peanut butter side down. A cat with toast strapped to its back will hover above the ground in a state of quantum indecision."
I'm not gonna give you my IP address! Ok... Portugal, South-Western Europe, 3rd rock from the sun (our star is easy to find, a 47 Ursae Majoris in the Milky Way :p )
Posts
1,457
One more thing, the original author says its free (as long as you dont claim the original code is yours) so, since all I did was translate the code, it doesn't even have my name or copyright or anything... use it at your own responsability (sp?)
That means: Feel free to modify this code, steal it, etc. I don't give a crap!
(Hmm I have to credit Lucky for that quote )
To learn how to use realistic effects in your games like fire, rain, snow and magic effects, read my article on particles systemshere.
Jotaf's Theories!
"Cats land on their feet. Toast lands peanut butter side down. A cat with toast strapped to its back will hover above the ground in a state of quantum indecision."
I'm not gonna give you my IP address! Ok... Portugal, South-Western Europe, 3rd rock from the sun (our star is easy to find, a 47 Ursae Majoris in the Milky Way :p )
Posts
1,457
Thanks, it's Jazz Jackrabbit from the game with the same name
A bit old I know but hey the sprites are kinda cool
To learn how to use realistic effects in your games like fire, rain, snow and magic effects, read my article on particles systemshere.
Jotaf's Theories!
"Cats land on their feet. Toast lands peanut butter side down. A cat with toast strapped to its back will hover above the ground in a state of quantum indecision."
I'm not gonna give you my IP address! Ok... Portugal, South-Western Europe, 3rd rock from the sun (our star is easy to find, a 47 Ursae Majoris in the Milky Way :p )
To learn how to use realistic effects in your games like fire, rain, snow and magic effects, read my article on particles systemshere.
Jotaf's Theories!
"Cats land on their feet. Toast lands peanut butter side down. A cat with toast strapped to its back will hover above the ground in a state of quantum indecision."
Originally posted by Jotaf98 Thanks, it's Jazz Jackrabbit from the game with the same name
A bit old I know but hey the sprites are kinda cool
...I have been to a little vecation now...and I think it has been a little missunderstanding here....didn't jsun9 say that my avatar did rock....???? But thanx anybay for answering for me....
I'm not gonna give you my IP address! Ok... Portugal, South-Western Europe, 3rd rock from the sun (our star is easy to find, a 47 Ursae Majoris in the Milky Way :p )
To learn how to use realistic effects in your games like fire, rain, snow and magic effects, read my article on particles systemshere.
Jotaf's Theories!
"Cats land on their feet. Toast lands peanut butter side down. A cat with toast strapped to its back will hover above the ground in a state of quantum indecision."
Reply With Quote
)
)
