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\$

1 Answer 1

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\$
3
  • 1
    \$\begingroup\$ Ohh yes, thanks. Stupid me, seems quite obvious now :-) \$\endgroup\$
    – Matthias
    Dec 22, 2014 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, 2014 at 18:31
  • \$\begingroup\$ Thanks EmAdpres... I was completely assuming that without even thinking about it... And I'm glad to be reminded! \$\endgroup\$ Dec 23, 2014 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .