Pixel Perfect Collision Detection FAILING!
Author
I believe I have found a scenario where pixel perfect collision detection can actually fail.
Imagine a sprite of height Sy and a bullet sprite with height By. Also the bullet has a velocity of Vy. If the bullet at time T1 is at position y and at time T2 is at position y + Vy. Now at T2 if if the new position of the bullet has actually moved passed all of the sprites image/pixel ( height of Sy ) data then pixel perfect collision detection will fail.
This problem seems to get worse as the bullets velocity Vy increases. Also it never seems to rear its ugly head if the velocity of the bullet Vy = 1.
Has anyone encountered this scenario? How did you work around it?
I have been over my pixel perfect collision detection code with a fine tooth comb and I am pretty convinced it is accurate.
I am using DirectX/DirectDraw on Win32, 2D based game.
Would appreciate any comments or thoughts.
Jeff
What you''ll have to do is check not only the bullet''s final position, but also every position in between.
this is not a new problem.. programmers have been experiencing it
forever..
another method is to raycast your movement and decide where the pixel
"will be" and where it "has been"
using that, you can check if your ray has intersected the object
and correct it.
-eldee
;another space monkey;
[ Forced Evolution Studios ]
forever..
another method is to raycast your movement and decide where the pixel
"will be" and where it "has been"
using that, you can check if your ray has intersected the object
and correct it.
-eldee
;another space monkey;
[ Forced Evolution Studios ]
Do NOT let Dr. Mario touch your genitals. He is not a real doctor!
All you have to do is check if the line (path) of the bullet intesects the sprite and if it does, use the equation from the bullet line to check if the position of the sprite is between the current and previous x coordinate of the bullet.
You don''t have to check -every- step of the way, just steps in jumps of bullet widths. One good option though is ignore pixel perfect colission and stick to coordinates 
Mark
mark@cornutopia.co.uk
http://www.cornutopia.co.uk
Mark
mark@cornutopia.co.uk
http://www.cornutopia.co.uk
The way I do this in my 2D game, is simply to move an object one pixel at a time in the game update loop until it has moved as far as it needs to move. In effect, this checks the line of the ojbect''s path. Not the best way of doing things, but very easy.
<SPAN CLASS=smallfont>quote:Original post by Mark Sheeky
One good option though is ignore pixel perfect colission and stick to coordinates :) </SPAN>
Very good advice...
[Edited by - atcdevil on October 12, 2006 10:42:08 AM]
you could also try slowing down the velocity so that it is not allowed to overpass the sprite
Author
Thanks to all who posted replies.
The "raycasting" and or "back stepping" solutions mentioned in combination with a bug I had in my pixel collision detection code made all the difference.
There are a lot of issues that crop up with this type of collision detection that are not dicussed in the texts. Especially when you consider locking surfaces in DirectX.
Again many thanks,
Jeff
The "raycasting" and or "back stepping" solutions mentioned in combination with a bug I had in my pixel collision detection code made all the difference.
There are a lot of issues that crop up with this type of collision detection that are not dicussed in the texts. Especially when you consider locking surfaces in DirectX.
Again many thanks,
Jeff
You just need to do proper collision detection This involves the 3d shapes extruded by moving objects (or 2d in a 2d game), and checking to see if they ever overlap. It''s alot more compilacted, but requires lots of plane/ray and line/line tests etc. True detection wouldn''t just look at the straight line between starting and ending positions either, but the curved paths vertices take if the object is rotating too - this is VERY complex and I''ve not got round to looking at the maths to see if it''s feasible.
Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor
John 3:16
This involves the 3d shapes extruded by moving objects (or 2d in a 2d game), and checking to see if they ever overlap. It''s alot more compilacted, but requires lots of plane/ray and line/line tests etc. True detection wouldn''t just look at the straight line between starting and ending positions either, but the curved paths vertices take if the object is rotating too - this is VERY complex and I''ve not got round to looking at the maths to see if it''s feasible. Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor
John 3:16
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement