Re: [pygame] Path finding demo, now with more fugu
As someone who runs a slower-than-average computer, I very much appreciate games that let me run at 10-15 fps, rather than slowing the game down to boring speeds or telling me I can't play. Telling me I can't at least TRY to play the game with some screen updates missing feels really snobby to me. Sure, I'd rather have it run at 30 fps, but at least I can for the most part enjoy the game at a lower fps. Games really don't become unplayable until they are under about 12 fps, so if you say that I have to run it at 30 fps or nothing, that's really cutting off a group of players who could enjoy the game (nearly) as it was intended. Yes, games should give at least some cpu time back, and only hog as much cpu as they need :) Some games need to hog a lot of it though.
Re: [pygame] Path finding demo, now with more fugu
Brian Fisher wrote: > 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. I've seen this argument before on the pygame list and I don't really understand it. It seems to me that in my experience, when I play a game which I don't have the CPU for, I get slideshow framerates, and it's pretty unplayable regardless of whether these slides are one "tick" apart or more. Of course, sometimes a player only has "not quite enough" CPU. So what happens if the game needs 110% of the player's CPU? If you decouple the visual update from the physics update, the player is "flying blind", and I think this makes the game much more difficult. If you don't, the game slows down, and this might make the game easier. This might be a problem if you like making very difficult games (I do!) but I think it would just be better to just abort and say "Sorry guy, you don't have enough CPU". I guess when it comes down to it, a good game engine has the physics decoupled from the graphics in the code, and so decoupling the updates for each shouldn't be that much more difficult. But I don't really see the point. Ethan signature.asc Description: OpenPGP digital signature
Re: [pygame] Path finding demo, now with more fugu
On 4/22/07, Richard Jones <[EMAIL PROTECTED]> 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)
Re: [pygame] Path finding demo, now with more fugu
Brian Fisher wrote: > Also if any game (pygame or not) can't run at it's desired frame rate > for performance reasons, or doesn't do anything to limit execution to > a specific frame rate, it will most likely run at 100% cpu all the > time (it's very common for games to take up all the cpu) I got a few comments on my recent PyWeek entry mentioning that it ran at 100% CPU. I agree with the sentiment already expressed here - this is common, and pretty much expected. Indeed, I provide a fullscreen mode, so that it can take up 100% of the monitor, and 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. To flip around what Brian said - my desired frame rate is as fast as possible, so using 100% of the CPU is correct behavior. One thing to consider - you can have different frame rates, and sometimes it makes good sense to do so. We just had people talking about the benefits of input processing happening multiple times per graphical frame, and (quirks of DirectX aside,) sometimes this is a very good thing - back 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. 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. With all of that in mind, I think it makes complete sense to leave the graphics frame rate aside when talking about CPU use. Consider this scenario: a user is playing a strategy game (chess, perhaps), and the computer isn't able to provide a satisfactory amount of challenge given the player's patience levels - the player doesn't want to wait 2 minutes for a move, and the AI is too easy to beat given that. Well, the user gets a brand new machine that's ten times faster - the user might well expect that his old machine would play at a certain skill level with two minute moves and his new machine would play at roughly the same skill level with 12 second moves (1/10 the time, given a machine that's 10x as fast). If the game was implemented to a hard-coded amount of logic per second, the new machine would perform just the same as the old machine, which might disappoint this player. And, if the player had another game that he also liked playing on his old machine, and it actually performs 10x better on this new machine, he might well decide to switch over to playing that other game instead. -Dave LeCompte
Re: [pygame] Path finding demo, now with more fugu
On Mon, 23 Apr 2007, Brian Fisher wrote:
> I think pygame.time.Clock.tick used
> to do busy loop waiting as well, in older pygame versions (not sure
> when it may have changed).
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).
Richard
Re: [pygame] Interface Surfaces
Kris Schnee wrote:
> What do you think of having each widget draw directly to the screen
> instead of to the parent widget's surface? Sounds awkward, since they'd
> need to know their absolute drawing location.
Actually, this is the way I usually draw widgets - although there are
times when being able to draw to a parent widget makes a lot of sense.
You don't have to have the location in the child widgets (absolute or
relative) - what I have done in the past is have the parent ("container")
widgets keep track of the locations of its children relative to itself.
This makes things like dialog boxes really easy to deal with, because
moving the box only needs to update the position of the box, not any
deeper in the hierarchy.
The way that I have got that to work (in PyGame, in particular, but it
applies elsewhere, as well) is that all widgets implement a draw method
something like this:
def draw(self, canvas, pos)
In the case of containers, the container first draws itself, then it
delegates down to its children and draws them with a passed-through
canvas, and a calculated position (the position of the container, plus
some offset of the child widget within the container).
This has worked well for the kinds of UI that I've wanted to draw, but I
can imagine cases where it becomes tricky. For example, maybe you've got a
dialog box that can fade out over time. (That seems like atrocious user
interface design, but leaving that aside...) For that, I imagine the
easiest way to get that to work is to draw the entire dialog box at full
alpha into an offscreen surface, then blit that surface to the screen with
an alpha that ramps to full transparency over time.
However, using container widgets to group and position child widgets makes
a number of UI idioms simple. I mentioned dialog boxes already, but list
boxes or any other kind of container with a scroll bar become (almost)
trivial.
Hope this is of use.
-Dave LeCompte
Re: [pygame] Path finding demo, now with more fugu
On 4/22/07, andrew baker <[EMAIL PROTECTED]> wrote: I've always been under the impression that this was a quirk of Pygame. It's not a quirk of pygame to run at 100% cpu all the time. The only things special about pygame in this area were that it provides waiting functions that perfer to chew cpu rather than release it (with the intent of getting a high-precision wait function). pygame.time.delay does busy loop waiting, and so does pygame.time.Clock.tick_busy_loop. I think pygame.time.Clock.tick used to do busy loop waiting as well, in older pygame versions (not sure when it may have changed). If a game uses a function that uses busy loop waiting in order to limit the frame rate then it will take 100% cpu even if it doesn't need to. It can be bad to take 100% cpu if you don't need to, because it can cause the game's frame rate to be choppy. Also if any game (pygame or not) can't run at it's desired frame rate for performance reasons, or doesn't do anything to limit execution to a specific frame rate, it will most likely run at 100% cpu all the time (it's very common for games to take up all the cpu)
Re: [pygame] Path finding demo, now with more fugu
I've always been under the impression that this was a quirk of Pygame. Works great, although it pegs the cpu at 100% :) -- Andrew Ulysses Baker "failrate"
[pygame] transparent images
Marcus: I would like to have a transparent image map. Subclassing Style with: def draw_imagemap(imagemap): return imagemap.picture and subclassing ImageMap class to use new Style subclass works, but bypasses the bordering code and maybe other functionality. Is there a better way to get a transparent image map? David -- [EMAIL PROTECTED] Pitcher's Duel -> pitchersduel.python-hosting.com
