Timeline for Tile based collision detection failing when player is going too fast
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2011 at 13:48 | comment | added | Olhovsky | @Sven: I am stating that you have to check "another frame ahead", yes. In order for objects to move at all, you must integrate velocity once per frame to get the current position. Physics engines typically test collision well by computing what the position of the object will be if it continues on it's current path to the next frame, and then traces it's position between now and the next frame. This avoids the problem of missing collisions without having to limit object velocities, as is partially described by CiscolPPhone as "Swept Collision Detection". | |
| May 22, 2011 at 17:35 | comment | added | Sven van Zoelen | @Olhovsy: My code already used that method what you are describing, it adds only the velocity in the update. So in the collision method you know the current location and by adding the velocity you know the next. I thought you stated that I had to check another frame ahead. | |
| May 22, 2011 at 14:05 | comment | added | Olhovsky | @Sven: You can't know for certain where an object will be next frame, because objects may collide with it between this frame and next, however you can add velocity*timestep to the object to find the position that the object will be in if it doesn't collide with anything. Typically physics engines accurately find collision by tracing an object from this frame to the next, to find the earliest collision point. This prevents any objects from falling through other objects, and this is what CiscolPPhone describes as his "Second method". | |
| May 22, 2011 at 9:11 | comment | added | Sven van Zoelen | @Olhovsky: How do you mean flawed? How can I predict another frame ahead without knowing what the player will do at that frame? | |
| May 22, 2011 at 3:11 | comment | added | Olhovsky | @JRT: It's flawed because he doesn't compute the next position in his algorithm. His algorithm describes discreet collision detection, where he only detects collisions with the current position at this frame. | |
| May 21, 2011 at 18:25 | vote | accept | Sven van Zoelen | ||
| May 21, 2011 at 18:10 | answer | added | aaaaaaaaaaaa | timeline score: -1 | |
| May 21, 2011 at 13:25 | comment | added | PrettyPrincessKitty FS | That seems like a lot of code.. | |
| May 21, 2011 at 12:57 | history | edited | Sven van Zoelen | CC BY-SA 3.0 |
edited body
|
| May 21, 2011 at 12:54 | comment | added | JRT | @Olhovsky: If his intention is to calculate the next position, then check for a collision based on the calculated position, then why is this flawed? (His implementation may well be flawed) | |
| May 21, 2011 at 12:49 | history | edited | Sven van Zoelen | CC BY-SA 3.0 |
added 6079 characters in body
|
| May 21, 2011 at 12:35 | comment | added | Sven van Zoelen | @CiscoIPPhone: Exactly. When the the player is going slower the collision detection works fine. | |
| May 21, 2011 at 12:14 | comment | added | CiscoIPPhone | My understanding is that the character is moving so fast it has gone completely through the platform in the time between two frames and so the collision isn't being detected. | |
| May 21, 2011 at 12:12 | history | tweeted | twitter.com/#!/StackGameDev/status/71911231631532032 | ||
| May 21, 2011 at 12:11 | comment | added | Olhovsky | JRT: Actually his algorithm is flawed, if the goal is to prevent the player from passing through objects. | |
| May 21, 2011 at 12:05 | history | edited | PrettyPrincessKitty FS | CC BY-SA 3.0 |
added 2 characters in body; edited title
|
| May 21, 2011 at 11:57 | comment | added | JRT | Your algorithm looks sound. A code snippet would be useful. | |
| May 21, 2011 at 11:57 | answer | added | CiscoIPPhone | timeline score: 7 | |
| May 21, 2011 at 11:36 | history | asked | Sven van Zoelen | CC BY-SA 3.0 |