Better collision detection
Author
In my last game, I did movement and animation so that the characters moved x pixels per frame, etc, and capped the framerate. In the current one I''m planning to do movement so that it moves x pixels per second, so I will be multiplying speed by velocity to get distance. But I was thinking that for collision detection, this could present a problem, because the sprites might move through each other, and not ever touch if it is running on a slow system, but a collision should have still occured. How would I do collision detection that searches for a collision along a path instead of only at the exact location of the sprite? I have heard a little about vectors, but I am not quite sure how to do this...
Thanks
-----------------------------
"And I write and I write and I don't believe it's gonna change today"
- From Yellow Ledbetter by Pearl Jam
http://www.crosswinds.net/~uselessknowledge
I was thinking of using that kind of Collision Detection also, I think I know 1 way of doing it, there might be a faster way of doing it though.
You could use the same routine as drawing a line from the sprites last position to its current position, and each pixel(or position) between the two points you check for a collision. I guess that would work
You could use the same routine as drawing a line from the sprites last position to its current position, and each pixel(or position) between the two points you check for a collision. I guess that would work
Ok, this is going to get a little hypothetical since I''ve not done colision detection yet. Make a bounding box or sphere and put yourself in it. Then leave some room between yourself and the inside edge of the cube. Do a check on world geometry and if the box is very close to the world object yet not touching it then it''s ok and you move closer to the object. On next iteration, the box collided/went through the world object, but because you are some distance from the edge of the box you haven''t gone through yet, however you detect the colision and stop. D3d has bounding sphere for you to use, so give it a try. Good luck
I have the same problem im updateing my movement by time also and am using velocities. So i fiqure i need to test the all the pixels moved 1 by 1 for a collision,but i havent been able to fiqure out how to implement this 
.
I think a artical should be written up about collision detection like this.
.I think a artical should be written up about collision detection like this.
I agree with you there, the general idea would be to start a timer, render the screen, check the timer, and then to update all the elements of the game world by
position'' = position + (velocity * time)
as for checking along the path, I agree the best way is to check for every x amt of length as you traverse the path, something like:
That way, you will check for every incremental spot from start_spot to dest_spot, and leaving it so you can do one more checkspot() at the dest_spot, which you have reached. The only thing about that is that instead of affecting curr_spot with curr_spot++, as you are talking about doing when you speak of checking every pixel, I don''t see why that''d be necessary...you could check every CHECK_DIST or whatever, that way you could turn up and down the precision by increasing or decreasing CHECK_DIST.
That''s the way I''d do it, I don''t know what you all think...Peace out.
- Ah, to write code; to compose electrical music, to manipulate the bits that make up everything...such is our chosen line of work. And for a game, no less!
position'' = position + (velocity * time)
as for checking along the path, I agree the best way is to check for every x amt of length as you traverse the path, something like:
for (curr_spot = start_spot; curr_spot < dest_spot; curr_spot++){ checkspot(curr_spot);} That way, you will check for every incremental spot from start_spot to dest_spot, and leaving it so you can do one more checkspot() at the dest_spot, which you have reached. The only thing about that is that instead of affecting curr_spot with curr_spot++, as you are talking about doing when you speak of checking every pixel, I don''t see why that''d be necessary...you could check every CHECK_DIST or whatever, that way you could turn up and down the precision by increasing or decreasing CHECK_DIST.
That''s the way I''d do it, I don''t know what you all think...Peace out.
- Ah, to write code; to compose electrical music, to manipulate the bits that make up everything...such is our chosen line of work. And for a game, no less!
I tend to agree with the above. You will find it nice to be able to tweak the algortihm as you go. You could even go as far as to add a variable to the bounding box/sphere distance. When I create a game I usually put in some sort of structure that allows me to tweak these game variables. You will find it much easier than hard coding them or even #define macroing them in a header file.
Kressilac
ps GameDev: Love the number of posts thing.
Kressilac
ps GameDev: Love the number of posts thing.
I was thinking about this problem for the cheesy asteroids game I''m working on. Because I''m using bounding spheres for simple collision detection, I thought that it might be possible to relate the radius of the bounding sphere to the velocity of the object, to dynamically determine the number (if any) of intermidiary collision checks you would need for each object.
distance traveled / radius seems right, but I haven''t tested this yet.
You might also want to check to see if the objects'' path (the line between it''s start and end position) intersect each other. If they do, you know they collided somewhere along thier path. You can use the intersection point and thier bounding boxes to solve for the exact time they collided. Although this method may be slower than the more brute force method above.
distance traveled / radius seems right, but I haven''t tested this yet.
You might also want to check to see if the objects'' path (the line between it''s start and end position) intersect each other. If they do, you know they collided somewhere along thier path. You can use the intersection point and thier bounding boxes to solve for the exact time they collided. Although this method may be slower than the more brute force method above.
I''ve just tackled a problem very similar to this. This is how I did it, seems to work ok, not sure if it''s the best way. Basically I''m using bounding circles (2D detection). I''ll move the object, then first test for detections at it''s current position. Then I''ll find out how far it moved in the last frame, then from this value I''ll work out how many bounding circles I would need to cover this distance.
distance_travelled / circle_radius;
from here I''ll step back only the distance travelled in the last frame, testing more bounding circles, at intevals determined by how many circles will fit into that distance.
distance_travelled / circle_radius;
from here I''ll step back only the distance travelled in the last frame, testing more bounding circles, at intevals determined by how many circles will fit into that distance.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
