[SDL] Problem with SDL_GetTicks()

[Gianfranco Berardi]

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