Making the game world independant of CPU speed
By Erik Greenwald <erik@smluc.org>
The game world in modern games appears to run at speeds that do not
depend on the speed of the CPU. This is critical for a game that involves
network interaction between two computers of different speeds. This critical
detail is incredibly easy to implement, yet some games still make it to the
shelf that depends on the speed of the computer. Frames per second, or FPS, is a
common way of benchmarking a systems performance, and is inverse of the time
delta. The time delta is the amount of time it takes from one frame to the
next. Once the time delta is calculated, the physics and controls can be scaled
against it, giving a consistancy necessary for a modern game. Two of the most
common languages for developing action oriented video games are C and C++, so
we will explore how to implement a couple ways of finding the time delta and
FPS using these languages. All 4 examples are comprised of three parts: the
main function, a function to waste time (so the numbers are sane), and the
function or class to calculate the time delta.
Calculating the FPS is extremely easy once the delta time function is
in place. FPS is the acronym for "frames per second". The average fps can be
calculating by dividing the number of total number of frames displayed by the
total elapsed time in seconds. Most of the time, you want to know the
instantanious FPS, not the average. Since the delta time function returns
seconds per frame, the reciprocal is frames per second. The easiest way to
calculate this is 1/delta_time. The more accurate formula is frames/delta_time.
Make sure that you don't update the time delta when computing frames per second,
or it'll skew your fps and your time handling.
One way of calculating the time delta is by using the clock() function.
This function doesn't return a real time value, but real lengths of time can be
calculating by using the CLOCKS_PER_SEC constant defined in time.h. A bonus to
this function is it's ansi standard, therefore portable. The disadvantage is
that the time resolution is only .01 seconds. Having a ceiling of 100 frames
per second may sound acceptable, but that's not the problem with the time
resolution. A very notable instance is when two samples are taken in such quick
succession that the system rounds the difference to be 0. When this happens,
your framerate jumps to infinity (assuming we disallow negative time). Another
issue is the quantitization of frame rates. Since the time resolution is .01
seconds, the fastest frame can happen in .01 seconds, yeilding 100 FPS. The
second fastest will be 50 FPS, the third fastest 33 FPS. While gameplay may be
fine with this going on, if you display an FPS counter, this will be painfully
obvious. One way to compensate for this is to calculate the framerate for a
number of frames at a time. Instead of finding the FPS every frame, find it once
every 10 frames, tracking the time for the 10 frames, then divide 10 by the time
for the 10 frames to commence. I think most games track for a clump of frames,
otherwise the display would constantly be flickering with different numbers.
click here to see clock.c, the C implementation
click here to see clock.cc, the C++ implementation
Another method is by using the gettimeofday() function. The function
modifies a struct you pass to it, and the structs members are then used to get
the time in seconds and microseconds. gettimeofday() conforms to SVr4 and
BSD4.3, so most UNIX and variants support it. MS-DOS, Window9x, MacOS, and I
think NT do not support it. The advantage is that it has a much higher time
resolution, and the current time can be extrapolated from it. The disadvantage
is that lesser operating systems do not support it.
click here to see gettimeofday.c, the C implementation
click here to see gettimeofday.cc, the C++ implementation
One thing that often complicates the issue and confuses people is that
when time scaling is introduced, EVERYTHING must be scaled. Not just movement,
but input, also. When this isn't done, the sensitivity of the controls can have
drastic differences between different computer systems. This only effects input
devices that depend on time, such as the keyboard or a joystick. Mice are
usually not suspect to this.
This document and the pertinant source code can be found at http://math.smsu.edu/~br0ke/gamedev/timer/.
WWWOFFLE - Sat, 11 Dec 1999 18:17:42 CET (vor 20 Minuten) - [Löschen|
Neu abrufen:
Optionen|
regelm. abrufen|
Index] - WWWOFFLE