Inside the animation loop, the following code will regulate your program speed:
frame++; // frame animation index
// skip drawing if time lags
if (SDL_GetTicks() <= lasttime+looptime)
{ redraw(); }
while((lasttime + looptime) > SDL_GetTicks())
{ SDL_Delay(1); }
lasttime += looptime;I am writing a game that uses a fixed time step for physics and would
like to ensure that the game runs smoothly and at the same speed on
different machines. This requires setting the refresh rate for the
video mode, but it is unclear from reading the documentation how one
does that using SDL. The game will be rendered using OpenGL.
If there is no direct way to set the refresh rate through SDL, is it
possible to set the video mode through some other means (DirectX) and
continue to use SDL? Any insight would be greatly appreciated.
First of all, no offense but if your game requires the video to run at
a precise refresh rate to work correctly, then your game is broken.
Not to mention SDL has no way to know if vertical retrace sync is used
or not (much less select it manually from code), so you really
shouldn’t depend on the refresh rate for anything.
To answer your question, sadly there is no mechanism to select video
mode. My guess is it’s one of those “will be in 1.3” features but I’m
no SDL developper.On 12/21/05, Josiah Manson wrote:
I am writing a game that uses a fixed time step for physics and would
like to ensure that the game runs smoothly and at the same speed on
different machines. This requires setting the refresh rate for the
video mode, but it is unclear from reading the documentation how one
does that using SDL. The game will be rendered using OpenGL.If there is no direct way to set the refresh rate through SDL, is it
possible to set the video mode through some other means (DirectX) and
continue to use SDL? Any insight would be greatly appreciated.
–
Hi Josiah,
Instead of setting your video refresh to a certain rate (cause sorry, but
that’s not possible really), you could make a timer (function or thread)
that was called at a certain rate and make the logic happen in there.
One thing i like to do in this kind of situation though is measure the time
between frames using SDL_GetTicks() and multiplying all my physics/logic
equations by that number.> ----- Original Message -----
From: slomojo83@gmail.com (Josiah Manson)
To:
Sent: Wednesday, December 21, 2005 9:54 AM
Subject: [SDL] Setting video refresh rateI am writing a game that uses a fixed time step for physics and would
like to ensure that the game runs smoothly and at the same speed on
different machines. This requires setting the refresh rate for the
video mode, but it is unclear from reading the documentation how one
does that using SDL. The game will be rendered using OpenGL.If there is no direct way to set the refresh rate through SDL, is it
possible to set the video mode through some other means (DirectX) and
continue to use SDL? Any insight would be greatly appreciated.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
sed s/video mode/refresh rate/On 12/21/05, Simon Roby <@Simon_Roby> wrote:
To answer your question, sadly there is no mechanism to select video
mode. My guess is it’s one of those “will be in 1.3” features but I’m
no SDL developper.
–
sed s/video mode/refresh rate/
I’m not sure what that means. Is it a UNIX command to provide relevant
documentation? Unfortunately I do not have access to a UNIX machine.
First of all, no offense but if your game requires the video to run at
a precise refresh rate to work correctly, then your game is broken.
Not to mention SDL has no way to know if vertical retrace sync is used
or not (much less select it manually from code), so you really
shouldn’t depend on the refresh rate for anything.
No offense taken. However, I do not think that a game being locked to
a refresh rate is as broken as you are implying. I intend to make a
high-speed racing game where response time and timing are critical. As
such, it would be bad for a frame to be displayed twice in a row, for
example, or any other imprecision in timing that makes the animation
less smooth.
I also need to use fixed time steps so that a ghost can be replayed
exactly as it was recorded based purely on the recorded inputs. As
time steps become shorter, the smoothness problem starts to disappear,
but that comes with the expense of CPU time.
Linear interpolation of positions between the physics steps for
rendering could be used, but I think that is more complicated and less
elegant of a solution than just setting a refresh rate and having
everything “just work.” If I understand correctly, it is very common
on consoles to go in lock step with the screen refresh.
To answer your question, sadly there is no mechanism to select video
mode. My guess is it’s one of those “will be in 1.3” features but I’m
no SDL developper.
That is unfortunate, because I believe that setting the refresh rate
is an important function.
Josiah Manson wrote:
I am writing a game that uses a fixed time step for physics and would
like to ensure that the game runs smoothly and at the same speed on
different machines. This requires setting the refresh rate for the
video mode, but it is unclear from reading the documentation how one
does that using SDL. The game will be rendered using OpenGL.
While I don’t know an actual answer to your question, I’m replying for
more of a “don’t do that” point of view.
(note: this part may be incorrect, it’s based on an assumption about
what you’re actually asking for) Its generally considered bad form to
force the setting of the actual monitor display frequency – many
monitors will only allow a very limited number of frequencies, but some
will gladly accept any frequency its given, even if the monitor itself
knows better (I’ve seen one that allowed the computer to set it to
640x480x24bpp at 400Hz and it burnt out after about a minute or so – it
tried its best, poor thing). Even if the monitor itself supports a
certain frequency, its a bad idea to assume any given user will be happy
with it. I personally can’t stand a CRT with anything less than 80Hz,
but LCDs are bearable down to 60Hz – anything less and I’ll get a
headache after about 20 minutes.
Another reason to be wary here is that fixed time step physics can cause
major problems in games. Even if the machine meets the minimum specs
for your game, and runs perfectly fine most of the time, what happens to
the physics if, say, the user’s anti-virus and/or anti-spyware software
starts scanning in the middle of the game? It is a much better idea to
use variable-time-step physics, just in case.
If you just can’t do variable-time-step physics (the only reason I can
think of here is in very physics based applications, where the accuracy
of the physics is absolutely important), you should probably sacrifice
the idea of smooth display in its favor. In this case, maintain the
physics at a rate that is necessary, and only render frames when it
won’t interrupt the physics. Another option to consider in this case
would be to use multi-threading to your advantage, and do the physics on
a separate thread – just make sure that the physics doesn’t update
positions of things while you’re rendering, or you will probably get odd
graphics glitches (if you can, minimize the locking time that the
renderer needs [and thus helping to ensure the physics engine doesn’t
block for the entire rendering] by copying all of the data it needs
before actually using it).
Its a regular expression.
It means replace “video mode” with “refresh rate” in his last post, as he
used the wrong term by mistake.
Its a perl (or sed) thing =)
JulianOn Thursday 22 December 2005 9:29 am, Josiah Manson wrote:
sed s/video mode/refresh rate/
I’m not sure what that means. Is it a UNIX command to provide relevant
documentation? Unfortunately I do not have access to a UNIX machine.
–
While you don’t greatly need the outside world, it’s still very
reassuring to know that it’s still there.
Sorry about the unixspeak, this is definitely not appropriate for this
mailing list. I hope you weren’t insulted, because I assure you that
wasn’t the intent at all.
What this means in plain english is “replace all occurences of [video
mode] with [refresh rate]”. So the second paragraph of this my
original reply should be:On 12/21/05, Josiah Manson wrote:
sed s/video mode/refresh rate/
I’m not sure what that means. Is it a UNIX command to provide relevant
documentation? Unfortunately I do not have access to a UNIX machine.
Also, as others have mentionned already, your game logic should be
regulated by SDL_GetTicks(). Use it to check how much time it has been
since the last call, then do a game logic update if enough time has
elapsed (so if your logic runs at 60 updates per second, update every
1/60 second elapsed since the last update). It is also good practice
to pad the time-checking loop with SDL_Delay(10), or else the
time-checking loop will make your game use 100% CPU at all times
(unless vertical retrace sync is used by the video driver, but as I
said before there is no reliable way to know if it is used or not).
–
First of all, no offense but if your game requires the video to
run ata precise refresh rate to work correctly, then your game is
broken.Not to mention SDL has no way to know if vertical retrace sync is
usedor not (much less select it manually from code), so you really
shouldn’t depend on the refresh rate for anything.No offense taken. However, I do not think that a game being locked
to a refresh rate is as broken as you are implying. I intend to make
a high-speed racing game where response time and timing are
critical. As such, it would be bad for a frame to be displayed twice
in a row, for example, or any other imprecision in timing that makes
the animation less smooth.
That’s exactly why you should make sure the rendering loop is locked
to the refresh rate (by means of retrace sync) if at all possible.
Now, what do you do if you can’t reliably/safely select a refresh
rate? What do you do if you’re not on a hard real time OS with an
oversized 3D accelerator?
You have the game logic adapt to whatever refresh rate you get - one
way or another.
[…]
Linear interpolation of positions between the physics steps for
rendering could be used, but I think that is more complicated and
less elegant of a solution than just setting a refresh rate and
having everything “just work.”
The bad news is that it won’t Just Work™, unless you’re on custom
hardware, or somehow can rely on having full control over the display
hardware. On personal computers, you shouldn’t even try it, as, if
if/when it actually works, it’s more likely to cause trouble than
solve your problem. (See other posts on monitors with limited refresh
rate support, users not being able to/wanting to use low refresh
rates etc.)
Interpolation isn’t particularly hard to do, it has minimal impact on
game logic CPU usage with high rendering frame rate, it delivers
smooth animation, and it works. If your game logic is too heavy,
too sensitive (replays and the like) or doesn’t lend itself very well
to variable timing, interpolation is the second best solution.
If I understand correctly, it is very
common on consoles to go in lock step with the screen refresh.
Yes, and that’s how it was usually done on arcade machines and the
C64, Amiga etc back in the good old days.
However, all of those systems have/had integrated and/or fixed refresh
rate display hardware, so the refresh rate was fixed and well known.
(Well, almost. Noticed that some games are smooth in the NTSC version
but not in the PAL version, or vice versa? Lazy conversions from one
system to the other…)
To answer your question, sadly there is no mechanism to select
video mode. My guess is it’s one of those "will be in 1.3"
features but I’m no SDL developper.That is unfortunate, because I believe that setting the refresh rate
is an important function.
It’s an easy way out, that only works for some end users, and it’s not
even possible to do on some platforms and backends.
60 Hz is way too low for most CRT users (stroboscope), whereas many
LCDs won’t go any higher than 60 Hz. CRTs, LCDs and video cards
nearly always have a resolution dependent maximum refresh rate. So,
there’s no safe value that will work everywhere, unless you plan on
supporting only very specific hardware configurations.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 21 December 2005 21:51, Josiah Manson wrote:
[…]
One thing i like to do in this kind of situation though is measure
the time between frames using SDL_GetTicks() and multiplying all my
physics/logic equations by that number.
The only problem is that it’s nearly never quite that simple, if you
actually want the game to play the same at any frame rate. Doing
speed, acceleration, jerk and stuff right is the easy part. The
problem is event handling.
Even in a simple 2D shooter with no physics responses to collission
events (ie any collission kills something instantly), you need to
calculate exact (*) collission times and handle events in correct
order, or the game logic will be affected (if ever so slightly) by
the frame rate.
Basically, with a fixed rate and interpolation, you don’t even have to
do the game logic right by any technical definition. The game will
still play exactly the same regardless of rendering frame rate.
(*) That is, “exact” to some appropriate, well defined
granularity. For example, you can round delta times to
the nearest millisecond (ie 1000 virtual logic FPS),
and implement all calculations so that there will never
be any rounding errors that depend on the delta time.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 21 December 2005 20:27, Alan Wolfe wrote:
sed s/video mode/refresh rate/
I’m not sure what that means. Is it a UNIX command to provide relevant
documentation? Unfortunately I do not have access to a UNIX machine.Sorry about the unixspeak, this is definitely not appropriate for this
mailing list. I hope you weren’t insulted, because I assure you that
wasn’t the intent at all.What this means in plain english is “replace all occurences of [video
mode] with [refresh rate]”. So the second paragraph of this my
original reply should be:To answer your question, sadly there is no mechanism to select refresh
rate. My guess is it’s one of those “will be in 1.3” features but I’m
no SDL developper.
This comes up every once in a while on the list. It seems there is no
reliable way to determine the valid refresh rates the attached monitor.
As a result, setting the refresh rate can cause all sorts of problems.
So, this feature is not included in SDL. Or, at least, that is what I
recall from the last round of this discussion.
Bob PendletonOn Wed, 2005-12-21 at 18:04 -0500, Simon Roby wrote:
On 12/21/05, Josiah Manson wrote:
Also, as others have mentionned already, your game logic should be
regulated by SDL_GetTicks(). Use it to check how much time it has been
since the last call, then do a game logic update if enough time has
elapsed (so if your logic runs at 60 updates per second, update every
1/60 second elapsed since the last update). It is also good practice
to pad the time-checking loop with SDL_Delay(10), or else the
time-checking loop will make your game use 100% CPU at all times
(unless vertical retrace sync is used by the video driver, but as I
said before there is no reliable way to know if it is used or not).–
- SR
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
David Olofson wrote:
That’s exactly why you should make sure the rendering loop is locked
to the refresh rate (by means of retrace sync) if at all possible.
Definitely.
Now, what do you do if you can’t reliably/safely select a refresh
rate? What do you do if you’re not on a hard real time OS with an
oversized 3D accelerator?You have the game logic adapt to whatever refresh rate you get - one
way or another.
[…]
Interpolation isn’t particularly hard to do, it has minimal impact on
game logic CPU usage with high rendering frame rate, it delivers
smooth animation, and it works. If your game logic is too heavy,
too sensitive (replays and the like) or doesn’t lend itself very well
to variable timing, interpolation is the second best solution.
After hearing the arguments (from a number of people) against setting
a refresh rate, I agree that interpolation is probably the way to go.
I think that the game logic will be very sensitive because of replays,
and so fixed time steps are required.On the issue of interpolation, since the physics will have to be slightly behind the current exact state of the game, is it better to guess where things will be those few milliseconds past where the game logic is, or to lag behind a little bit so that what is rendered is interpolated between 2 calculated game states? That was a confusing question. Perhaps ascii art will help? * means this time is rendered o is a fixed point in time that has been calculated = is time that has happened according to the game is time that has yet to be calculated past Predictive rendering: o====o====o====o—* Interpolated rendering: |++lag+| o====o====o=*==o---- John Silicon wrote:
Even if the machine meets the minimum specs
for your game, and runs perfectly fine most of the time, what happens to
the physics if, say, the user’s anti-virus and/or anti-spyware software
starts scanning in the middle of the game?
With fixed time steps, is there a way around this problem? Is this a
problem that should be seriously taken into consideration? Could the
game be set to a higher priority to avoid the virus scanner stealing
CPU time?
[…]
Even if the machine meets the minimum specs
for your game, and runs perfectly fine most of the time, what
happens to the physics if, say, the user’s anti-virus and/or
anti-spyware software starts scanning in the middle of the game?With fixed time steps, is there a way around this problem?
Yes. What you do is keep track of real time as well as logic/virtual
time, and whenever it’s time to render a new frame, you advance the
logic/virtual time until it matches current time. That is, if the
application is stalled for whatever reason, the “throttling” logic
will loop over the game logic only, until it catches up. (You should
probably restrict this so that the game effectively pauses if the
application is stalled for too long.)
[…]
Could the game be set to a higher priority to avoid the virus
scanner stealing CPU time?
No, that’s only possible on real time operating systems. A normal
general purpose OS basically cannot guarantee anything in the first
place. The next problem is that just raising the priority of a thread
pretty much only changes the initial bias for the timesharing. If you
want a thread like a game (that would normally be penalized for being
a CPU hog) to stay high priority, you need to select a different
scheduling policy as well.
(Under Linux, there’s SCHED_FIFO, but that’s available only to root,
and for good reason: If you end up in an infinite loop, the reset
button is the only way out, because only other SCHED_FIFO threads can
preempt SCHED_FIFO threads. NT based Windows versions have some sort
of “real time” threads, but they’re not nearly as strict as Linux
SCHED_FIFO in my experience.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 22 December 2005 03:39, Josiah Manson wrote:
On the issue of interpolation, since the physics will have to be slightly behind the current exact state of the game, is it better to guess where things will be those few milliseconds past where the game logic is, or to lag behind a little bit so that what is rendered is interpolated between 2 calculated game states? That would be extrapolation vs interpolation. The safe and simple way is of course to interpolate - that is, calculate the balanced average of the last two states, balanced by the fractional logic frame time corresponding to the display frame you’re about to render. However, it does obviously add some lag. (That said, in most cases, lag of n ms is much better than +/- .5 n of jitter.) Extrapolation can, at least theoretically, eliminate the lag, and even compensate for the total input->response latency caused by input hardware latency, page flipping/buffering latency etc. The bad news is that it’s hard to do it safely and without overshoot. Normally, in games based on reasonably realistic physics, objects will move smoothly at least down to the jerk (change of acceleration) derivate, and this can be handled relatively well by interpolation of sufficiently high order. When objects are supposed to stop dead instantly, extrapolation will invariably cause some degree of overshoot, because there is no way to predict such events. (In fact, there is no way to predict anything with absolute certainity, but with “smooth” changes, the viewer can’t tell the difference as long as the extrapolation is in the order of ms or even tens of ms.) As to latency, one might think that one frame’s worth of latency more or less won’t make a difference - but it does matter. In fact, even in games where latency itself doesn’t really hurt gameplay, higher rendering frame rates (ie smoother animation) makes it possible to “feel” the added latency. […] John Silicon wrote:
[…]
As to latency, one might think that one frame’s worth of latency more
or less won’t make a difference - but it does matter. In fact, even
in games where latency itself doesn’t really hurt gameplay, higher
rendering frame rates (ie smoother animation) makes it possible to
"feel" the added latency.
In the game that I am writing, collisions should be extremely
infrequent, so it might make sense to risk the overshooting that can
occur. As this is a racing game, the paths taken should be relatively
smooth and continuous, and so I suspect that a higher order
extrapolation would be a good approximation. I don’t want the controls
to feel mushy, so the feel of latency that you mention sounds like an
important consideration.
If I do extrapolate the positions of objects, to what time should I
extrapolate? There are three possible times that I see as possibly
making sense. The first, and most obvious, is to extrapolate to the
current time as reported by SDL_GetTicks(). The second is to
extrapolate to the beginning of the next screen refresh (which would
likely be after the current time). The third is to extrapolate to
half-way through the next screen redraw.
For the last two, I’m not entirely sure how the time of redraw would
be calculated, but I assume that it can be. The distinction between
the last two is a difference in ideas about when the frame is
considered displayed. Is the third, similar to using the midpoint rule
for numerical integration, generally considered more accurate?
Obviously, pushing the extrapolated position farther into the future
increases jittering.
Yes. What you do is keep track of real time as well as logic/virtual
time, and whenever it’s time to render a new frame, you advance the
logic/virtual time until it matches current time. That is, if the
application is stalled for whatever reason, the “throttling” logic
will loop over the game logic only, until it catches up. (You should
probably restrict this so that the game effectively pauses if the
application is stalled for too long.)
Speaking of real time, the documentation for SDL_GetTicks seemed to
say to me that the time reported back was in milliseconds, but did not
explicitly state that the resolution of the timer was actually
accurate to the millisecond. If I want precise timings, can I rely on
SDL, or should I look into using something with greater precision, for
example, the RDTSC instruction on pentium computers?
Thank you so much for your thoughtful replies.
Josiah Manson wrote:
With fixed time steps, is there a way around this problem? Is this a
problem that should be seriously taken into consideration? Could the
game be set to a higher priority to avoid the virus scanner stealing
CPU time?
Hi,
as already mentioned, your problem can be solved if you approximate the
virtual time of your game to the “ideal”, or the real time. Based on the
simple math, frames/time = speed, you can count elapsed seconds and
frames (using SDL_GetTicks() and frame_counter++ in a separate thread or
within main loop), then multiply the speed of your game objects by a
factor f, say,
f = ideal_time * elapsed_frame / frame_counter
where your ideal_time would be something like 24fps (I’m in doubt that
24fps is an ideal value, try to figure it out yourself ;-)–
Alexander Ellwein
David Olofson wrote:
On the issue of interpolation, since the physics will have to be
slightly behind the current exact state of the game, is it better to
guess where things will be those few milliseconds past where the game
logic is, or to lag behind a little bit so that what is rendered is
interpolated between 2 calculated game states?That would be extrapolation vs interpolation.
…
Extrapolation can, at least theoretically, eliminate the lag, and even
compensate for the total input->response latency caused by input hardware
latency, page flipping/buffering latency etc. The bad news is that it’s
hard
to do it safely and without overshoot.
I think overshoots would not be such a big problem in a racing game –
nothing ever comes to a dead stop instantly – that is infinite acceleration
and would ‘energize’ the object, not even simply atomize it 
When hitting walls, tires and car bodies compress and then bounce off
(usually). I think extrapolation would be a better choice in this case, but
also with a little bit of physics extrapolation as well. Or perhaps even a
full-scale extrapolating physics engine that would work like so: 1)
recalculate the previous reference points based on input received during
last game frame; 2) extrapolate the display points for the next display
frame using current vectors with obstacle adjustments; 3) process input; and
back to (1).
And the most important thing is – you will need this method anyway if you
want to make a multiplayer racing game (even if only in a not-so-near
future).
-Alex.