Collision detection for small, fast objects

[Davey]

n00b question:

Right now I'm checking collisions by seeing which sprites overlap each frame, but fast objects can skip over each other between frames and a collision isn't detected. What is the best way to handle this?

Right now, whenever I check two objects for a collision, I compare their sizes and speeds to find out how many collisions I need to check for between frames. For example, if a bullet moves 20 pixels per frame, I might move it 4 pixels 5 times and check for a collision at each iteration. This works, but I'm assuming there are better ways to do this. Right now the bullets in my game travel in a straight line at a constant speed, I don't know how well this will work if I want to add bullets that speed up, slow down, change directions, etc. I'm not even sure if pixels per frame is the right way to go here, should I be going off a timer instead?

My first idea was just to have the game logic run at a faster rate than the refresh rate, but I'm guessing I'll run into performance problems if I do that.

[Pixel_Outlaw]

Check under the tutorials at Shmup-Dev, Motorherp has covered this in-depth.

Link in my sig. He does game physics for a living he knows...stuff.

Also you might use small line segments from each object's position to their next position. Using the current position and future position should make a series of vectors. Use this algorithem to check all objects. Before deletion. http://en.wikipedia.org/wiki/Line_segment_intersection This algorithem is for one stationary object and one moving however.

If you are simply checking for collision between bullets and enemies you just break the enemy into one or more rectangles, with some exception all shmups even modern ones use rectangles rather than pixel level collisions. Check the new topic on Shmup-Dev for more info. http://www.shmup-dev.com/forum/index.ph ... icseen#new


A simple rule of thumb is large boxes for enemies small box for the player. Pixel level collisions are simply not needed in shmups.

[Zebra Airforce]

Pixel-perfect collisions are a bad idea in just about any kind of game.

[Shion]

While pixel-perfect collision detection isn't efficient, I find circular hitboxes a lot better for shmups than rectangles (since like, bullets are round). They also require a minimum amount of processing power. If you'd like, I could share some tricks on how to do this efficient.

For the OP's main problem, I've always solved this by drawing an imaginary line between the bullet's x, y, and previousx and previousy. If this line crosses the players hit circle, it counts as a collision. Obviously this only works with very small bullets though.

[Ixmucane]

For the OP's main problem, I've always solved this by drawing an imaginary line between the bullet's x, y, and previousx and previousy. If this line crosses the players hit circle, it counts as a collision. Obviously this only works with very small bullets though.

It works with any size of bullet by adjusting the hit box. If the player has radius x and the bullet has radius y, there is a hit if the line crosses the circle around the player of radius x+y.

[Shion]

For the OP's main problem, I've always solved this by drawing an imaginary line between the bullet's x, y, and previousx and previousy. If this line crosses the players hit circle, it counts as a collision. Obviously this only works with very small bullets though.

It works with any size of bullet by adjusting the hit box. If the player has radius x and the bullet has radius y, there is a hit if the line crosses the circle around the player of radius x+y.

Yeah, but I meant without adjusting the players hitbox. I prefer to have bullets with different sized hitboxes, while the player has a fixed, small, hitbox. Also, using the line calculation thing with every single bullet is inefficient, so I only use it on rare occasions.

[rtw]

I read motorherp's interesting article on Gunbird2 collision detection.

Can anyone tell me how the hit boxes are activated in Gunbird2 ? From the images it looks like it's from a console version of some kind.

rtw

[Motorherp]

I read motorherp's interesting article on Gunbird2 collision detection.

Can anyone tell me how the hit boxes are activated in Gunbird2 ? From the images it looks like it's from a console version of some kind.

rtw

Glad you liked the article. Yeah the photo's are taken from the gunbird special edition package for the PS2 which included a debug mode. I doubt they'd include it for the conversion if it wasn't present in the original PCB though I've no idea how you'd activate it sorry.

Anyway about the dynamic collision testing, you might want to check out the second art of collision tutorial I wrote at shmupdev which discusses dynamic collision for circles and a nice time filter optimisation you can create. The time filter method is easily upgradeable to dynamic collision testing and its also possible to include other shapes as well if you dont want top just stick with circles. The method isn't suitable for all games though, it was aimed at bullet hell style shmups such as progear for example. Perhaps if you describe your game and say what you need to collide I can point you in the right direction.

[rtw]

Glad you liked the article. Yeah the photo's are taken from the gunbird special edition package for the PS2 which included a debug mode. I doubt they'd include it for the conversion if it wasn't present in the original PCB though I've no idea how you'd activate it sorry.

Anyway about the dynamic collision testing, you might want to check out the second art of collision tutorial I wrote at shmupdev which discusses dynamic collision for circles and a nice time filter optimisation you can create. The time filter method is easily upgradeable to dynamic collision testing and its also possible to include other shapes as well if you dont want top just stick with circles. The method isn't suitable for all games though, it was aimed at bullet hell style shmups such as progear for example. Perhaps if you describe your game and say what you need to collide I can point you in the right direction.

Thanks for the heads up Motorherp!

I'll read the second one as well.

I'm not planning on using this algorithm in any games. I work as a
programmer and by nature I'm fascinated by clever algorithms.

Thanks for sharing!

rtw