Alan Wolfe wrote:
The way I wish i did it now is where it puts all the dt’s into a "bucket"
variable and when the bucket overfills (lets say at 100ms for 10 updates a
second - slow but just for demonstration purposes), it will preform a logic
update to the game and subtract the “threshhold” value from the bucket.
Ie if the bucket is 115, it issues a logic update and subtracts 100 from the
bucket. Toss it in a while loop or something to handle if the bucket is at
523 or something. This makes calculating physics equations etc very stable
no matter what the FPS
It would be alot nicer now if i did it that way then, so hoping this helps
you out some (:
I think out of all the tutorials or code samples I found yesterday, one
or two might have mentioned something along those lines. I believe it
was one of the tutorials that had psuedocode examples, which was helpful
to a point but hard to visualize if you don’t know what the made up
functions were supposed to do.
Anyway, if I understand you correctly, and the following is off the top
of my head, you would basically have a totalTime variable and do:
totalTime += dt;
Then you would check if totalTime was greater than some threshhold
before you do an update:
while ( totalTime > SOME_CONSTANT )
{
// do some updating
totalTime -= SOME_CONSTANT;
}
Of course, if dt still ends up 0.0 most of the time, I don’t think this
will change anything, but it will likely solve the spikes you are
seeing. Of course, what do you use as the modifier instead of dt since
dt will still have larger than normal values? Normally you would do
something like, player.moveX( moveSpeed * dt ), but you did the above to
compensate for dt’s huge deviations. I think SOME_CONSTANT would just
lock dt to some upper bound, so if it does end up getting too high, it
will still work out. Just subtract the upper bound from dt, use the
upper bound as the modifier, and stick the remaining portion in totalTime.
I haven’t tried it yet as it is 6:30AM and I am getting ready to go to
work, but it makes sense to me this early in the morning.–
GBGames’ Blog: http://www.gbgames.com/blog
I’m going to implement such system within next few days, so it’s nice to know that’s tested.