1
\$\begingroup\$

So I have a fast-moving object in my game, let's say a bullet. At each iteration of the main loop I update the object's position based on the delta time value dt and draw it at the new position.

I also check whether the object's new position is close to a target position. In that case the object will be removed:

S....|...|....|....|......|...|....|....|...|..T..|X

The object starts from location S, moving towards target position T. Each dot . represents one ms time. The vertical bars | represent a game loop iteration, in which I check whether the object has reached its target destination. At X the object will be removed.

Since these checks (ie. game loop iterations) might take place before or after the 100% exact target position (even if only a few pixels off), I perform this check with a distance between a line segment from the last position to the current position, and whether the target position is on that line. This approach works well.

There is one issue though: Since the check in which I recognize that the target has been reached happens after the real position of the target, the object moves a little bit further than desired. That's becoming more severe when the object is moving very fast.

Now my question: Is there kind of a "best practice" how to deal with this issue? I assume this is a common problem in game development.

PS: The only solution I could think of is to re-position the object to the real target position as soon as the check succeeds. However, that can look a bit like a "jump" back, which does not look great.

\$\endgroup\$
2
\$\begingroup\$

Definitely a common issue! Whenever you quantize time -- which is always, in a step-wise simulation -- you need to account for these boundaries.

As part of each bullet-move, you need to say something like,

distanceToMove = min(velocity * time, howFarTilWeGetStopped);

Which really is the same check you're already doing... just do it before rendering.

\$\endgroup\$
  • 1
    \$\begingroup\$ Ohh yes, thanks. Stupid me, seems quite obvious now :-) \$\endgroup\$ – Matthias Dec 22 '14 at 0:09
  • 1
    \$\begingroup\$ In this way you are assuming that next dt (hopefully) will be as same as last dt. Also it's a better solution but of course it's still an issue. \$\endgroup\$ – Emadpres Dec 22 '14 at 18:31
  • \$\begingroup\$ Thanks EmAdpres... I was completely assuming that without even thinking about it... And I'm glad to be reminded! \$\endgroup\$ – david van brink Dec 23 '14 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.