Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question

marked as duplicate by Nicol Bolas, Ali.S, eBusiness, doppelgreener, Patrick Hughes Apr 28 '12 at 15:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

11  
Did you have a look at this: gamedev.stackexchange.com/questions/1589/… ? –  Eric Apr 26 '12 at 18:36
    
Thanks for the link! –  jco Apr 27 '12 at 10:59

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
    
My physics was simple enough so I didn't really need a physics engine... –  jco 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

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