Hi Mike, i see you use a timeMultiplier and i have seen time used a lot on
game source, i was wondering is there anything wrong in what i am doing,
that is doing my movements/Animation in a timer set at 30fps and letting the
draw loop just take care of drawing, that way i don’t need to use a time
Multiplier.
So am i wrong???
Patricia Curtis wrote:
Hi Mike, i see you use a timeMultiplier and i have seen time used a lot
on game source, i was wondering is there anything wrong in what i am
doing, that is doing my movements/Animation in a timer set at 30fps and
letting the draw loop just take care of drawing, that way i don’t need
to use a time Multiplier.So am i wrong???
In general, no, there is nothing wrong with that. It’s simply another approach. I’ve never used this approach, and in fact, I hadn’t really thought of it. Thinking about it now, I see one real advantage and one real disadvantage.
The advantage is that you will always produce precisely the same results over the same number of frames, if given precisely the same conditions. In the timeMultiplier method I proposed, I will actually get slightly different end results in different frame rates, because of the way I compile acceleration.
The disadvantage of the method that you propose is that, if you’re running on a particularly slow machine, it may not be able to run the game at 30 fps. In that case, the entire game will slow down, because it’s still running the same time increment per frame, but showing fewer frames in a second. How likely this is to come up depends, of course, on how resource intensive your game is.
Resource intensitivity is … well… set a minimum hardware requirement
heh.
Over the years I’ve given a fair bit of thought to system performance vs
independent logic timing. Obvious system performance stuff should be
reactive or capped in such a way that a system 10x faster than what you
developed for can still play the game peacefully without a need for a slo-mo
type of program.
I think it depends on the kind of game you’re designing. Alot of button
mashers, on, say, the original NES benefited from performance hits when
there was alot going on graphically — when a lot was going on, you didn’t
have to try to guess where things would be graphically while time was
ticking. At the same time, it’s mildly irksome on highly fluctuated games
to have to constantly keep your ‘internal clock’ matching the game.
a prime example would be an fps. having game logic limitted by graphical
fps is a good thing. if you walk into a room in doom on your 386sx and
there’s 50 monsties, it’d suck to die without knowing why. if the game is
playing slow, you can at least trudge through that area or similar.
Of course there are situations where it doesn’t matter if the system gets
bogged down… at which time it’s mildly annoying to have to wait to input
commands.
For an asteroids clone, I’d suggest keeping game logic limited by FPS. If
you have a HD spike or some other background process trigger at the wrong
time you’d get pissed about the game ‘jumping’ and then finding out you’re
dead… or game being jittery and hard to control.
Of course, there is plenty of gray area in the debate. Ya could have an
independent timing mechanism and only have it slow down if the system is
remarkedly slow over a given number of frames. Something along the lines of
#define AVG 10
times[AVG] = 0 // fifo
timethreshold=66ms (15fpsish)
time=0
totaltime = 0
start=0
end=0
loop
{
start=now
input()
logic()
draw()
end=now
time = end-start
totaltime -= times[fifotail]
times[fifohead] += time
adjust fifohead and fifotail
if(frames < AVG) frames++
if(totaltime / frames > timethreshold)
{
logic fps = graphical fps
}
else
{
logic fps = 30fps
}
}
this way the game will slow down for just a moment during a single load
spike… or be semi-transparent if ya have weird load issues … or actually
bring the logic down to graphical speed if there’s something intensive going
on… and recover on its own. being spread out across several frames also
makes it a bit less jarring and even things out with intermitant issues
(rather than frame by frame basis), although if AVG is too high, you won’t
take the logic fps speed hit until alot has already happened.
then there’s fun of doing linear or quadratic speed changes from max/current
logic fps to match whatever the graphical fps is running at… where instead
of just logic = graphical, ya say adjust logic constantly to move it towards
graphical (within a limit of course) so that you get there over the course
of several frames… possibly yielding a slighty more fluid change.
meh!
-Will
Will Langford wrote:
Of course, there is plenty of gray area in the debate. Ya could have an
independent timing mechanism and only have it slow down if the system is
remarkedly slow over a given number of frames.
These are some interesting points… An alternate implementation of this would be to just use something like what I proposed initially, with the timeMultiplier, but cap the timeMultiplier to a particular amount, say 0.05 (20 fps), so if you get a momentary lag spike, for whatever reason, it won’t cause the game to charge forward without you and get you killed. This would also aid in debugging, as it can be really annoying when you pause to look at the debugger, and when you hit play again, it updates for the last 30,000ms all at once.
This is also super easy to implement. A simple matter of:
timeMultiplier = (newMS - oldMS) / 1000.0;
if (timeMultipler > 0.05)
timeMultiplier = 0.05;
Just tossing in my 2 cents worth of experience…I’ve used the time
multiplier before and in the end it was just a headache for too many reasons
such as non reproducibility and strange things happening when time between
frames was very small (round off error in physics making the player not move
barely at all) or very big (obvious issues)! It’s one of those lessons I
learned never to do again hehe. (:> ----- Original Message -----
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Mike Powell
Sent: Thursday, August 23, 2007 12:35 AM
To: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Spaceship rotation (Mike Powell)Patricia Curtis wrote:
Hi Mike, i see you use a timeMultiplier and i have seen time used a lot
on game source, i was wondering is there anything wrong in what i am
doing, that is doing my movements/Animation in a timer set at 30fps and
letting the draw loop just take care of drawing, that way i don’t need
to use a time Multiplier.So am i wrong???
In general, no, there is nothing wrong with that. It’s simply another
approach. I’ve never used this approach, and in fact, I hadn’t really
thought of it. Thinking about it now, I see one real advantage and one real
disadvantage.The advantage is that you will always produce precisely the same results
over the same number of frames, if given precisely the same conditions. In
the timeMultiplier method I proposed, I will actually get slightly different
end results in different frame rates, because of the way I compile
acceleration.The disadvantage of the method that you propose is that, if you’re running
on a particularly slow machine, it may not be able to run the game at 30
fps. In that case, the entire game will slow down, because it’s still
running the same time increment per frame, but showing fewer frames in a
second. How likely this is to come up depends, of course, on how resource
intensive your game is.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Alan Wolfe wrote:
Just tossing in my 2 cents worth of experience…I’ve used the time
multiplier before and in the end it was just a headache for too many reasons
such as non reproducibility and strange things happening when time between
frames was very small (round off error in physics making the player not move
barely at all) or very big (obvious issues)! It’s one of those lessons I
learned never to do again hehe. (:
What I actually do in my projects is store speeds in units per millisecond. Then, I run the update multiple times per frame, once for each millisecond that’s passed. This method seems very numerically stable. The one worry I’ve always had is that, when done on a slower machine, it may choke up doing more and more updates each frame. The simple, and in retrospect, obvious change of just limiting the number of ms it perceives per frame (just like limiting the timeMultiplier) totally fixes that problem.
I presented the timeMultiplier solution because, while it may be less numerically robust, it’s much simpler to explain and implement, and seems adequate for most simple games.