Would This Problem Happen?
Author
I've started using time-based movement in order to keep the game running at the same speed on all computers, but I thought of something today.
If I have a fast moving object, and the computer running the game is extremely slow, and say, the game was only getting like 1 fps. In that case, there would have been a lot of time passed by before the update code was called, so everything would move a lot in that one frame.
What if an object moves so much that it goes through an object when in reality, it should have collided, but it moved to the other side of the object in one frame?
Would this happen, or am I not thinking of something? I suppose it doesn't really matter, since no one would bother to play a game if their framerate was that low, but I was curious.
one solution is to use fixed timesteps.
say one update for every 10ms (just an example).
Thus if it has been 205ms since the last frame you just run the update method 20 times. (the remaining 5 ms carries over to the next frame)
say one update for every 10ms (just an example).
Thus if it has been 205ms since the last frame you just run the update method 20 times. (the remaining 5 ms carries over to the next frame)
Depends on the collision detection used. Let's take a 2D example.. you're a sphere, the wall is a line. If you simple check if it's collided every frame, then yes, this would occur and it would be a problem. It is true that no one would play it at 1 FPS, however, it could be used as a simple hack (someone could write a program that could pause a game when the user hits a key, and then resume it to find the user is now on the other side of the wall).
The only way to fix this truly is to have a good collision response system that checks collision at all steps between it's new location and previous location to see if at any point it collided with the wall. In example, you could do line-line collision, with one line being the wall and the other being the the coordinates of the player's previous position to the player's new position.
Hope that helps
~Zix
The only way to fix this truly is to have a good collision response system that checks collision at all steps between it's new location and previous location to see if at any point it collided with the wall. In example, you could do line-line collision, with one line being the wall and the other being the the coordinates of the player's previous position to the player's new position.
Hope that helps
~Zix
Author
That's kind of what I was thinking. I suppose it's a little overboard for the homebrew stuff that I do now, so I probably shouldn't worry about it.
Author
Wait, couldn't I just use a 'for' loop to perform the update logic once per millisecond that's passed?
Doing 1000 collision checks per second is going to destroy your FPS if there's any more than a couple objects in the scene. Every 10 or 15ms however brings that number down considerably.
This is why we use 'swept' collision checks. For example, rather than testing a point (say, the bullet) against a plane (the wall), we test a line segment spanning the current and previous positions (of the bullet), against the plane. It's trickier to do, but adapting your geometry is far more efficient than adapting your algorithm.
Admiral
Admiral
Author
Okay, I'll look into that. It might be out of range of what I'm doing now, but It'll definately be good stuff to know when I actually get a job.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
