Start a new topic
Add Reply
Well, I have the tile collision working pretty well now. There is a small issue with diagonals but I should be able to fix that at a later date. The readers want me to just get it working so I will fix the problem with diagonals later.
Advanced collision detection discussion
Advanced collision detection discussion
Rate Topic:
#1
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 19 November 2009 - 02:10 PM
Was This Post Helpful?
0
MultiQuote
#2
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 20 November 2009 - 07:37 AM
Fixed the problem with diagonals and the collision of the tiles with the sprite. There is one other topic that I might add eventually. At the moment this doesn't work so good with the transparency of the sprite and the tiles. That would require per pixel collision detection between the specific tile and the sprite. Something that I might add in later on.
Was This Post Helpful?
0
#3
Aurel300
- D.I.C Head
-
- Group: Members
- Posts: 180
- Joined: 10-November 07
Dream Kudos: 0
Posted 20 November 2009 - 08:23 AM
Donīt use pixel by pixel collision. This is not the easiest thing to do neither in code nor performance. Games where a lot of collision detection is needed (like Street Fighter) use collision boxes.
In .NET it is a built in function (rect.Intersect(otherRect)), but it should be fairly easy to code manually.
In .NET it is a built in function (rect.Intersect(otherRect)), but it should be fairly easy to code manually.
This post has been edited by Aurel300: 20 November 2009 - 08:24 AM
Was This Post Helpful?
0
#4
NeoTifa
- 1-800-NEO-ROXS
-
- Group: Authors
- Posts: 7,603
- Joined: 24-September 08
Dream Kudos: 150
Posted 20 November 2009 - 09:53 AM
But the things aren't purely square. If you were playing Call of Duty or something and they used, say, cube collision, and someone shot around your head and clipped the very far corner, which is no where near your head (headshot revetively), and got points for headshotting you, wouldn't you be pissed? I mean, pixel detection is far more accurate, and there is nothing wrong with it. Yes, it's a pain to code, but the rewards are worth it.
Was This Post Helpful?
0
#5
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 20 November 2009 - 11:23 AM
Per pixel collision detection does take a lot of processing. At the moment I'm using a form of rectangle collision for this and it works well. The sprite can never enter a tile that is impassable. I could restrict the player's motion like in the Pokemon games where they are only ever in one tile at a time but I think players prefer free range movement
I was thinking of possibly at some time adding in per pixel for the tiles if the sprite does collide with an impassable tile, just checking in those cases would reduce the amount of time spent processing per pixel collision.
To make it a bit better I might go with a bounding rectangle for the sprite and for the tiles, since they are somewhat rectangular, create a smaller rectangle for them and check collisions between those two rectangles to allow the sprite to get closer to the edge of the tiles. At the moment though what is important is that the sprite can't enter impassable tiles.
For character/object collision detection, like NeoTife said, it is usually better to do per pixel collision. It is frustrating for a player if the object just misses them and it counts as a hit. Though when they are playing against the computer and there is near miss that counts as a hit they never seem to complain.
I was thinking of possibly at some time adding in per pixel for the tiles if the sprite does collide with an impassable tile, just checking in those cases would reduce the amount of time spent processing per pixel collision.
To make it a bit better I might go with a bounding rectangle for the sprite and for the tiles, since they are somewhat rectangular, create a smaller rectangle for them and check collisions between those two rectangles to allow the sprite to get closer to the edge of the tiles. At the moment though what is important is that the sprite can't enter impassable tiles.
For character/object collision detection, like NeoTife said, it is usually better to do per pixel collision. It is frustrating for a player if the object just misses them and it counts as a hit. Though when they are playing against the computer and there is near miss that counts as a hit they never seem to complain.
Was This Post Helpful?
0
#6
Aurel300
- D.I.C Head
-
- Group: Members
- Posts: 180
- Joined: 10-November 07
Dream Kudos: 0
Posted 20 November 2009 - 12:04 PM
Yes, but in a Zelda (I mean top-view) RPG - I think that is different.
I donīt say you should have just ONE boundary box around the whole sprite - maybe there are going to be some bigger ones than 1x1 tiled - like a big dragon or something.
But for those 1x1... Do as you want, but without a good code some performance may be gone.
I donīt say you should have just ONE boundary box around the whole sprite - maybe there are going to be some bigger ones than 1x1 tiled - like a big dragon or something.
But for those 1x1... Do as you want, but without a good code some performance may be gone.
Was This Post Helpful?
0
#7
lesPaul456
- D.I.C Regular
-
- Group: Authors
- Posts: 362
- Joined: 16-April 09
Dream Kudos: 175
Posted 20 November 2009 - 12:15 PM
While per pixel collision detection does require more processing, there usually isn't a noticable difference in performance.
Another common 2D collision detection technique is to use polyogns that are the exact shape of the sprite. The performance remains about the same as rectangle collision. Granted, polygon collision detection is not always a feasible option...
Another common 2D collision detection technique is to use polyogns that are the exact shape of the sprite. The performance remains about the same as rectangle collision. Granted, polygon collision detection is not always a feasible option...
Was This Post Helpful?
0
#8
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 20 November 2009 - 12:21 PM
Collision detection can be a complex topic in just about any situation. Issues like a lot of transparency and animation can compound the problem. For an animated sprites with a lot of transparency the problem can get worse. I'm going to split this thread about collision detection and move it to game programming for more of a discussion on the topic. I think it would be a good discussion there.
Was This Post Helpful?
0
#9
Aurel300
- D.I.C Head
-
- Group: Members
- Posts: 180
- Joined: 10-November 07
Dream Kudos: 0
Posted 20 November 2009 - 02:11 PM
Aurel300, on 20 Nov, 2009 - 12:04 PM, said:
But for those 1x1... Do as you want, but without a good code some performance may be gone.
This post has been edited by Aurel300: 20 November 2009 - 02:11 PM
Was This Post Helpful?
0
#10
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 20 November 2009 - 06:49 PM
Yes, you would definitely want to optimize the code to reduce the number of times you are doing per pixel collision detection. For example, if you find that the player's sprite will collide with an object using say simple rectangle collision if it is even worth doing per pixel collision detection. Even when you do the per pixel collision detection you would want to try and optimize the code to reduce the performance impact. If you are tracking a lot of objects, like in an MMO, you would be better to find a different way to handle collision detection.
Was This Post Helpful?
0
#11
Hellbroth
- D.I.C Head
-
- Group: Contributors
- Posts: 93
- Joined: 15-August 09
Dream Kudos: 50
Posted 20 November 2009 - 08:37 PM
That's realy nice of you SixOfEleven like always you help us so much.
Is this in your tutorials in somewhere else?Cause i realy want to look at it.
Thanx again for all your efforts.
That's realy nice of you SixOfEleven like always you help us so much.
Is this in your tutorials in somewhere else?Cause i realy want to look at it.
Thanx again for all your efforts.
Is this in your tutorials in somewhere else?Cause i realy want to look at it.
Thanx again for all your efforts.
That's realy nice of you SixOfEleven like always you help us so much.
Is this in your tutorials in somewhere else?Cause i realy want to look at it.
Thanx again for all your efforts.
Was This Post Helpful?
0
#12
Aurel300
- D.I.C Head
-
- Group: Members
- Posts: 180
- Joined: 10-November 07
Dream Kudos: 0
Posted 21 November 2009 - 06:35 AM
An alternate solution (for tiles) would be that a tile would have a boolean value "hasWalkMap" and an array of points / polygon "walkMap".
If a player is walking over the tile and the hasWalkMap is false, none collision detection is done. However, if the value is true, then the walkMap determines the walkability.
I think that player would have just a normal boundary box and it will be tested for collision with the polygonal walkMap.
Plus, maybe a value "walkable" (boolean) would be needed too. If a tile isnīt walkable, no collision detection is needed either, and this thing would probably be used for water and things like that.
If a player is walking over the tile and the hasWalkMap is false, none collision detection is done. However, if the value is true, then the walkMap determines the walkability.
I think that player would have just a normal boundary box and it will be tested for collision with the polygonal walkMap.
Plus, maybe a value "walkable" (boolean) would be needed too. If a tile isnīt walkable, no collision detection is needed either, and this thing would probably be used for water and things like that.
This post has been edited by Aurel300: 21 November 2009 - 06:37 AM
Was This Post Helpful?
0
#13
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 21 November 2009 - 08:07 AM
I went one step further than a boolean variable for this. I'm using an enumeration so that I can check for more than just walkable tiles eventually.
The way my collision layer works is when the player is moving, I don't check anything if the player isn't moving as that would be a waste of processing time, check which tile they are moving into using a bounding rectangle. Depending on which direction the player is moving depends on how the collision detection works. The collision layer returns the enum for the tile the player is walking into. At the moment I only have two values in the enum, passable and unpassable. The method that preforms the collision check returns true if the tile is unpassable and false otherwise. I have been considering, if the tile is unpassable, going further and doing a per pixel collision detection between sprite and tile. That would be very far off in the future though.
The way my collision layer works is when the player is moving, I don't check anything if the player isn't moving as that would be a waste of processing time, check which tile they are moving into using a bounding rectangle. Depending on which direction the player is moving depends on how the collision detection works. The collision layer returns the enum for the tile the player is walking into. At the moment I only have two values in the enum, passable and unpassable. The method that preforms the collision check returns true if the tile is unpassable and false otherwise. I have been considering, if the tile is unpassable, going further and doing a per pixel collision detection between sprite and tile. That would be very far off in the future though.
Was This Post Helpful?
0
#14
RudiVisser
- .. does not guess solutions
-
- Group: Members w/DIC++
- Posts: 1,931
- Joined: 05-June 09
Dream Kudos: 150
Expert In: PHP, MySQL, HTML, CSS, C#
Posted 21 November 2009 - 09:31 AM
NeoTifa, on 20 Nov, 2009 - 04:53 PM, said:
But the things aren't purely square. If you were playing Call of Duty or something and they used, say, cube collision,
Hitboxes darling, they are used
TF Hitboxes w/ Anti-Lag applied
ET Hitboxes
etc.
This post has been edited by RudiVisser: 21 November 2009 - 09:34 AM
Was This Post Helpful?
0
#16
Tom9729
- Segmentation fault
-
- Group: Author w/DIC++
- Posts: 2,279
- Joined: 30-December 07
Dream Kudos: 425
Posted 21 November 2009 - 12:06 PM
No one uses per pixel collision detection, especially not in 3d games! It would be way too slow and in a lot of cases it doesn't even make sense.
Might be manageable in 2d games but there are definitely better ways.
If you want accurate results, use simplified collision meshes. For things like headshots, just use hitboxes (as Rudi mentioned).
Edit: Also, NeoTifa you realize you might want to use a bounding box/sphere to see if a bullet is reasonably close to the player and THEN do some more expensive collision checking to see if it's a headshot (for example)?
Might be manageable in 2d games but there are definitely better ways.
If you want accurate results, use simplified collision meshes. For things like headshots, just use hitboxes (as Rudi mentioned).
Edit: Also, NeoTifa you realize you might want to use a bounding box/sphere to see if a bullet is reasonably close to the player and THEN do some more expensive collision checking to see if it's a headshot (for example)?
This post has been edited by Tom9729: 21 November 2009 - 12:08 PM
Was This Post Helpful?
0
#18
Tom9729
- Segmentation fault
-
- Group: Author w/DIC++
- Posts: 2,279
- Joined: 30-December 07
Dream Kudos: 425
Posted 21 November 2009 - 02:26 PM
Aurel300, on 21 Nov, 2009 - 04:53 PM, said:
No, it WOULD be better that way, but in CoD, they simply check the big box around your head and nothing else.
With per-pixel CD, wouldn't you have to render everything (even if it isn't being shown on the screen)?. That would be incredibly slow. Also how would you handle objects that are occluded by other objects? Just because the pixels are overlapping on your screen doesn't mean that the objects they represent are colliding.
This post has been edited by Tom9729: 21 November 2009 - 02:26 PM
Was This Post Helpful?
0
#19
SixOfEleven
- XNA Developer
-
- Group: Moderators
- Posts: 4,013
- Joined: 18-October 08
Dream Kudos: 1100
Expert In: C, C#, XNA, Game Programming, Programming Concepts
Posted 21 November 2009 - 04:53 PM
Tom9729, on 21 Nov, 2009 - 04:26 PM, said:
With per-pixel CD, wouldn't you have to render everything (even if it isn't being shown on the screen)?. That would be incredibly slow. Also how would you handle objects that are occluded by other objects? Just because the pixels are overlapping on your screen doesn't mean that the objects they represent are colliding.
Yes, having to render everything and then check for collisions would be very slow. Having to render everything in the game whether or not it is on the screen, especially in 3D, can be very slow and suck up performance of the game. I guess that is why there are so many good line of sight methods out there.
You have another good point there as well about the occlusion of objects by other objects. If you had two objects in relatively the same position and the object collides with both of them, in pixels, how would you handle that?
Was This Post Helpful?
0
#20
lesPaul456
- D.I.C Regular
-
- Group: Authors
- Posts: 362
- Joined: 16-April 09
Dream Kudos: 175
Posted 21 November 2009 - 05:03 PM
I don't know a lot about 2D, but I know that in 3D it's getting popular to use a capsule for humanoid players, and check for collision against each polygon in the map (using sweeps for performance).
It seems like a lot of people are moving away from bounding boxes since they are not accurate, and the tend to get stuck. Capsules fit much more closely and are great for sliding collision.
It seems like a lot of people are moving away from bounding boxes since they are not accurate, and the tend to get stuck. Capsules fit much more closely and are great for sliding collision.
This post has been edited by lesPaul456: 22 November 2009 - 01:25 PM
Was This Post Helpful?
0
| 
