RE: [Algorithms] FPS Questions

[Graham S. R. <gr...@se...>]

I like Jason's post. It is fairly consistent with my own observations, which
I describe here. He may not agree with my whole discussion, though.

The old "fact" that 25-30 fps is enough for animation that appears
continuous to the human eye was discovered when viewing movies of fairly
slow moving objects. Slow compared to FPS games during attack sequences, for
example. It just happens that 60 fps or 100 fps or 25 or 30 fps just works
out nicely for most current games.

Does anyone have any reference that states that the human eye *cannot*
resolve *much* better than, say, 100 fps? I would bet that it *can*. My
monitor is running at a refresh rate of 75Hz now. Not 100Hz, but close
enough. If I just move a pencil across the screen at at speed that is
consistent with the speed of some computer game actors, I see the distinct
strobe effect that indicates when the screen is refreshing. I have to slow
the pencil down significantly before it appears to move smoothly with no
strobing. (This seems move obvious when you move the pencil diagonally
across the screen. Also, you when the pencil is moving slowly, you will
detect the strobing more effectively in your peripheral vision----so keep
your eyes focused at one point while moving the pencil.)

We can think about this without getting too theoretical, in my view. It
seems to me that the target frame rate will generally be a function of how
fast the fastest actor/game element is moving on the screen, in, say, pixels
per second. Count how fast the thing or character is moving in pixels per
second, and the number of pixels is the number of frames you need to get the
SMOOTHEST possible animation. Think about the pencil example. When I slow
the pencil down, I am really reducing its speed, in pixels/second, down so
that it moves roughly one pixel per frame. That gives the smoothest possible
motion of the pencil, given the strobing screen behind.

For example, if a bot is moving at 250 pixels per second (roughly 4 seconds
to cross a 1024 pixel screen), then you need 250 frames per second to
represent the position of that bot at every pixel location it would
potentially occupy in a second. If its moving 60 pixels/second then you need
60 fps. 25 pixels/sec needs 25 fps, etc.

Imagine a very fast moving element in a game, one that moves across the
entire screen in one second---this doesn't seem too fast if you think about
it. If you just move that pencil across in one second it looks fairly slow.
To get the smoothest possible animation (in terms of pixel jumping), you
would need to have a frame rate equal to the pixel resolution of the screen.
For a 1024 pixel screen, you'd want 1024 fps. At some point, pixels are very
small and we can think about something other than pixels/second. Perhaps
tens of pixels per second is close to ideal----this would be consistent with
the current trend of looking for 100fps. (At some point, we may need to look
at the ability of the eye to resolve individual pixels, and the angular
displacement of objects relative to the eye----these being functions of
distance from the screen...)

So, in summary, I believe the target frame rate should be a function of the
rate of movement in screen space of the fastest moving game element. Some
games will continue to need 25-30, some 60, some 100, and, perhaps, 300fps
will be best for some games.

Beyond monitor synchronization and frame drop issues, there will probably be
a *requirement* for motion blur and some other kinds of temporal
antialiasing if we get too fast, I suppose. Can we even make a monitor that
runs at extraordinary refresh rates?

What happens in 5 years when we all have monitors running at 2000 pixels
horizontally? Large immersive displays such as CAVE's already run at 96
frames per second at that resolution... What happens when we are all using
stereoscopic hardware all the time, so that each eye sees have the total
frame rate. 100fps becomes 50fps. We will then need 200fps to match today's
100fps..... Food for thought.

Graham Rhodes