Timeline for Tile based collision detection failing when player is going too fast
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2011 at 18:18 | comment | added | aaaaaaaaaaaa | I don't completely get your question. Did the edit answer it? | |
| May 23, 2011 at 10:59 | history | edited | aaaaaaaaaaaa | CC BY-SA 3.0 |
added 1082 characters in body
|
| May 23, 2011 at 7:28 | comment | added | Sven van Zoelen | I wrote it down on the whiteboard and you are right. It will check all the collisions correctly, but when the delay is to big the renderer will lag. But what will hapen when your nextUpdate stays under the 10 milliseconds? | |
| May 22, 2011 at 20:53 | comment | added | aaaaaaaaaaaa | Have you actually read and understood the code? Unless the physics takes more than 10 ms per step it will always do a complete catchup. | |
| May 22, 2011 at 19:41 | comment | added | Sven van Zoelen | But then you still have a gap in time that is not caught by your physics when the elapsed time exceeds let's say 100, because the user's machine was busy with other more important processes. | |
| May 22, 2011 at 10:32 | comment | added | aaaaaaaaaaaa | That is only a problem if you set the update rate too high for the computer to keep up. You'd do variable step 20 years ago because stuff like this was on on the limit of what a computer could handle. That is not so any more. | |
| May 22, 2011 at 9:13 | comment | added | Sven van Zoelen | The time elapsed method will keep up with the delay by updating the physics with the lost time. Your method in the other hand will not catch up with the delay when the update cycles will be higher then 10 milliseconds (not smooth). | |
| May 21, 2011 at 18:10 | history | answered | aaaaaaaaaaaa | CC BY-SA 3.0 |