[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Path finding demo, now with more fugu



On 4/22/07, Richard Jones <richardjones@xxxxxxxxxxxxxxxx> wrote:
AFAIK ('cos it's early in the morning and I'm feeling lazy ;) this is still
the case when the requested frame rate is high enough (42 on my system).

Looks like Richard is right - the change to clock.tick was made in svn
Feb 2006. So in 1.7 pygame still usually busy waits with clock.tick.
It only sleeps starting with 1.8 I guess.


I don't see much conceptual
difference between taking full advantage of the pixels available to me and
taking full advantage of the CPU cycles available.

Background processes are often asking for a little bit of CPU, causing
contentions with greedy apps. There aren't really contentions for
pixels in the same way at all. When a high frame rate game (like 60)
is interrupted, it will often lose the CPU for an entire frame or 2,
which is a noticeably choppy effect if the game doesn't adjust for it.
If you want a high fps game to run silky smooth (i.e. at a regular
frame rate) it's better to share the CPU.


in the heyday of first person shooters, devotees insisted that reading the
mouse at 100-200 frames per second was mandatory, even if the graphics
were "only" running at 75 frames per second.

I know this is kind of getting off in the weeds, but it's still frame
rate related...

I got a pet peeve about the 100-200 fps turn off vsync thing that some
gamers would get obsessed with - human motor control is only capable
of about 15 movements a second (most people can only get to like 10
and we can't sustain it for long) and world class human reaction time
only gets as low as 150 milliseconds (6.6 reactions a second).
Visually it takes between 12-18 frames per second for human visual
systems to stop seeing distinct pictures (depending on the person).
Based on all that, sampling things at 30 frames per second is great
from a human interface perspective and 48 frames per second is
arguably as good as it gets (sampling rate of > 3x the phenomen rate),
so 60 is really more than is needed.

However human brains are very good at detecting changes, and changes
in the rates at which things change. We can easily tell when frame
rates skip or jump if the physics didn't update at a regular rate, and
it can be jarring.


You might also consider running your AI, physics, and any other "game
logic" at some rate separate from (and thus presumably tuned to a
different value than) your graphics and input frame rate.

I second this, especially for software rendering where drawing takes
most of the time. In those cases skipping draws is a great way to keep
gameplay consistent on slow computers that can't draw the high frame
rate you might want otherwise. Also running graphics at a different
rate than game stuff lets you make game stuff run at a consistent rate
with respect to time, which is good.


With all of that in mind, I think it makes complete sense to leave the
graphics frame rate aside when talking about CPU use.

You are right that they are not necessarily strongly tied. However a
game's frame rate is usually a good rule of thumb in terms of knowing
if a game is getting more CPU time than it needs. The real idea is not
use more CPU than you need (because it's good for energy use, good for
laptop battery life, good for multitasking on pause menus and such,
good for getting consistent frame rates)