Hi,
I like time based movement, it has a lot of advantages over frame based but one thing has me confused, that is, collision detection can seem to suffer. If the game player has a little platform game for example, his little character is moving across the screen, every thing is fine, then pow, his anti-virus kicks in, in the background, and his FPS goes really low, now the character jerks across the screen. This is fine and is to be expected but if the character jerks too far, he could possibly miss collisions with other sprites... not good. What's worse, because the background collision, platforms etc., are also dependant on the characters position for detection, he could 'jerk' inside a wall before he should have stopped at its surface.
Now the only way I can see around this is to make an interpolated collision zone around the character, old position to new position but this then starts to get complex very quickly and slows down the code no end.
So, has anyone used timebase movement before, in this type of situation and worked around these problematic details with collisions?
I've had a look on the net, to no avail.
I usually do a loop checking each pixel the player or object moves thru on the way to the next time-based location. I also set a hard limit on how far this jump can be so there isn't a very high jump possible between positions.
Bottleneck your time to be calculated.
GFT=GETTIMER() //get frame time elapsed
GTime = GT / 1000.0 //convert time to milliseconds
IF GTime > 1.0 THEN GTime = 1.0 // prevent out of control movement greater than 1 second.
I usually average the time from the last 5 loops, and disregard any times over a certain amount.
This actually causes slowdown and pauses when your system is chugging, but I EXPECT to see slowdown and pauses when my system is chugging, so I like it that way. :)
OK thanks guys.
Not sure about restricting the movement if it takes too long, this could mess up other time based calculations, time based animation for example but its an idea I will think more on.
Maybe the answer is a physics library like Box2D, one that uses swept collision that can deal with 'jerky' bodies.
This feels like one of those silly problems that should have a simple solution but then again, maybe not... :P
Quote from: bigsofty on 2009-Sep-15
Not sure about restricting the movement if it takes too long
Well if a players computer slows down, then it should be the players problem.
Restricting the movement should prevent out of bounds problems.
Also you can try to make some kind of logic pathing, to prevent illegal movements etc.
Another thing you can try is making your "walls" thicker, thicker than 1 pixel thickness.
Quote, this could mess up other time based calculations, time based animation for example but its an idea I will think more on.
Animation should be neglible compared to movement antics.
To deal with animations i use time stamping.
And if you know how many frames are in your animation, then you can divide the frame steps with time.
Buffer the animation Start and end time, using gettimerall().
Use gettimerall as a reference to the start time , and add your total animation time to it, to find the end time.
Here is how i deal with animation timing..it works very good, and each frame will show relative to real time elapsed.
//get stuff buffered for animation sequence.
AnimStartTimeStamp=gettimerall()
AnimEndTimeStamp = gettimerall() + 1000 // finish animation in one second 1000ms
TotalNumAnimFrames=number of animated frames in the animation bitmap.
//time based animation algorithm
TotalAnimationLifeTime = AnimEndTimeStamp -AnimStartTimeStamp
AnimTimeLeftToLive = AnimEndTimeStamp - Gettimerall()
FrameTime=TotalAnimationLifeTime / TotalNumAnimFrames
AnimStage=TotalNumAnimFrames - ( AnimTimeLeftToLive / FrameTime )
DRAWANIM ID, AnimStage...
This is cool but does not quite fit into my animation system, I use time-line animation, where each frame has its point on the time line, therefore one frame can last 100ms and the next can be 800ms later.
Time based animation, movement and collision need to all work in parallel or the system will glitch. If you retard the movement for example but not the animation system at the same time, then, for example a characters foot will not hit the ground in the same place when moving... this can leader to all sorts of visual problems.