Game timing and retrace question

Many game developer tutorials tell me that I can use retrace for timing my
programs “main loop”. The advantage is that my program runs at a constant
speed no matter how fast the processor is.

But will the refresh-rate (programmable on many graphic cards) have
influence on the retrace-timing?

“A. Jans-Beken” wrote in message
news:3A68BCB7.8CA9D9AC at wxs.nl

Many game developer tutorials tell me that I can use retrace for timing my
programs “main loop”. The advantage is that my program runs at a constant
speed no matter how fast the processor is.

But will the refresh-rate (programmable on many graphic cards) have
influence on the retrace-timing?

Yes. Don’t do it. Use SDL_GetTicks() for timing.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor

“A. Jans-Beken” wrote:

Many game developer tutorials tell me that I can use retrace for timing my
programs “main loop”. The advantage is that my program runs at a constant
speed no matter how fast the processor is.

But will the refresh-rate (programmable on many graphic cards) have
influence on the retrace-timing?

That was back when you could set the video mode yourself and be sure of
a particular refresh rate. It’s still OK to sync your game with the
refresh (in fact you should if possible), but time your animation
against another source, like clock() or SDL’s timing functions.

My code generally keeps a global floating point variable called
time_scale that gives the ratio of the current framerate to a baseline
of 30 frames/sec. I then time my animations against a 30fps update
interval and multiply the counters by time_scale to get an appropriate
update speed for the current framerate. time_scale gets updated each
frame based on the running average framerate.

-John–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software

Many game developer tutorials tell me that I can use retrace for
timing my programs “main loop”. The advantage is that my program
runs at a constant speed no matter how fast the processor is.

Well… Not quite, but retrace sync is very important for good
results, especially if you’re trying to do full screen scrolling at
full frame rate.

The problem with using the retrace for timing is that the only
platforms that have a useful time base in the refresh rate are game
consoles and the like, with PAL (50 Hz) or NTSC (60 Hz) displays.
(Oh, you could depend on the refresh rate on arcade machines as well,
as you have full control, even if you’re not using 50/60 Hz video
monitors.)

Even though it’s possible, at least on some platforms, to chose a
suitable refresh rate, it’s not recommended. Chosing a low frame rate
(like 60 Hz) will create avery annoying flickering on high end
monitors, while chosing a higher rate (100 Hz) may not work on all
monitors.

Besides, some display targets can’t really be trusted to give you
what you wan’t, even if they’re supposed to be capable of it. (This
can happen on Windows/DirectX, if the video card driver is crappy, it
may provide only one or two fixed refresh rates for a certain
resolution, even though the hardware is fully capable of setting up a
display with virtually any refresh rate.

The solution is to use a known/reliable time base for the control
system, while running the rendering engine synchronized with the
refresh rate. (This doesn’t mean you have to, or even should use two
threads. You can also write a control system that can adapt to any
amount of “control time” to elapse during one call to the control
system “driver” function, and then just configure it for the refresh
rate you actually get.)

But will the refresh-rate (programmable on many graphic cards) have
influence on the retrace-timing?

Yes, as the retrace happens between every refresh. For all practical
matters (unless you’re hacking video drivers, or otherwise using the
hardware directly), you can consider “retrace” and “refresh” the same
thing.

(Tech: The retrace is when the electron beams are shut down and
returned to the top-left corner of the CRT for the next refresh.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 19 January 2001 23:16, A. Jans-Beken wrote: