3

Possible Duplicate:
Fixed time step vs Variable time step

Now just let me clarify what I mean by "real time based physics", which I will call RTBP from now on. Well, basically, it implies taking, you guessed it, actual time into calculations.

For example:

timePassed = time - lastTime

positionx += vx*timePassed
positiony += vy*timePassed

lastTime = time

This would be a simple RTBP model. What's the alternative? I call it "step based physics" (SBP from now on), which would just be this:

positionx += vx //v in SBP is obviously smaller than in RTBP
positiony += vy

I currently use SBP, but I see that many people actually include time in their calculations. Why is that? I of course limit the update time to 1000/60ms.

Once the update interval is limited, both models would behave the same. The only difference is when the FPS drops. I believe that here is where PBS excels over RTBP. In PBS the game would, yes, run slower, but would always produce the same results! In RTBP, the position might increase so much that an object actually passes through a wall!

Anyway, there must be something that I'm missing.

Community
  • 1
jcora
  • 7,877
  • 4
  • 49
  • 84
  • 11
    Did you have a look at this: http://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step ? – Eric Apr 26 '12 at 18:36

1 Answers1

2

RTBP (as you've written it) can't detect collisions if the time step is too big - objects may jump so much they simply don't ever overlap to cause a collision. Of course the same is true of SBP if the step is too big. It's true for both if the movement is very fast and/or objects are small enough to just skip over each other.

Unless there was a compelling reason to write my own, I'd go with one of the existing physics engines myself - they've solved a lot of these problems before.

Tim Holt
  • 10,318
  • 1
  • 31
  • 46
  • My physics was simple enough so I didn't really need a physics engine... – jcora Apr 27 '12 at 10:59
  • 2
    The first sentence simply isn't true - it's correct if you do your collision tests based on the 'snapshot' of the scene at each timestep, but that's not the only way to do collision. Sweep-based collision algorithms will work correctly no matter how large the timestep is. – Steven Stadnicki Apr 27 '12 at 18:19
  • I agree. I was basing my comment on the sample code, which performs a simple "positionx += vx*timePassed" calculation. I've amended my first sentence to reflect this. Algorithms (sweep-based collision) as you've mentioned are exactly why I'd not write my own physics code. – Tim Holt Apr 27 '12 at 19:30