It's not just animation, though, right?
Like the previous poster mentioned, any game that has a realtime simulation
component is going to be using the CPU even when not responding to user
input. Example of this would include games ranging from SimCity to Tetris.
Similarly, any game with a compute
Hi,
> The suspend-function (from game.py) wouldn't work here in the emu,
> because only root hast write-access to /sys/power/state. Is this
> possible on the xo, and are there other ways to suspend as well?
I don't think the suspend call should be necessary; after thirty seconds
of being
C. Scott Ananian wrote:
> I have patched Pippy's examples to follow best practices for pygame,
> so that the frame rate is limited to 20 FPS and games automatically
> pause and suspend after 20 seconds of inactivity. (These defaults can
> be overridden.)
>
> The patch is pullable from:
> http://de
I have patched Pippy's examples to follow best practices for pygame,
so that the frame rate is limited to 20 FPS and games automatically
pause and suspend after 20 seconds of inactivity. (These defaults can
be overridden.)
The patch is pullable from:
http://dev.laptop.org/git?p=users/cscott/pippy
In this case (animation), the games should "go quiet", if there is no
user input after a short period (say, 30 seconds). It is pretty easy to
get the window system to tell you when it has been idle, I believe (the
X screen saver extension, for example).
When no animation, applications should be q
Jim
This is specific of games which use many resources, like animations
and some more advanced graphics. I also think will be nice if screen /
video driver supports other screen resolution, like 600x450 and less
color depth if the only depth that XO works is 16bits. This can save
CPU/GPU to some g
There is one piece of this discussion that is scaring the bejesus out of
me: the idea that an application should take *any* cpu time when the
user isn't doing anything... Is this specific to pygame based
applications? Or am I missing something?
Electricity doesn't grow on trees, you know In
The Python way is explicit over implicit. pygame.image.load() will
return a surface of the form you actually saved, you must explicitly
convert it to another format if you saved it in a format different than
what you want for blitting.
--Noah
Bernardo Innocenti wrote:
> On 12/09/07 19:51, Roberto
On 12/09/07 19:51, Roberto Fagá wrote:
> I think for now pygame is doing with 16bits at default yet, and I
> wrote wrong, the second parameter from set_mode are the flags, depth
> is the third parameter. I also used 12bits too to test, for games when
> colors don't matter so much can be a good ch
The surf.convert() and .convert_alpha() will do this. It is advised to
always run one of these (depending on if you need per-pixel alphas) on
any image loaded from disk.
--Noah
Bernardo Innocenti wrote:
> On 12/09/07 19:08, Noah Kantrowitz wrote:
>> Unfortunately this is not possible in most game
Just adding, to convert at load time with pygame, just need to use
.convert() on surface object, and it'll convert to the screen surface,
like
surf = load(..)
surf.convert()
I think for now pygame is doing with 16bits at default yet, and I
wrote wrong, the second parameter from set_mode are the f
On 12/09/07 19:08, Noah Kantrowitz wrote:
> Unfortunately this is not possible in most games, as doing them purely
> vector-based is infeasible. A lot of the artwork made for games will be
> standard raster graphics, and will need to be designed for a specific
> screen. If there are changes in the
Last I checked pygame didn't expose the X event source as a file
descriptor, so that anything that used pygame and network had to poll
... is this still a problem? Is there an example activity that solved
that?
--
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Unfortunately this is not possible in most games, as doing them purely
vector-based is infeasible. A lot of the artwork made for games will be
standard raster graphics, and will need to be designed for a specific
screen. If there are changes in the future, they can always be redrawn.
--Noah
Berna
On 12/09/07 18:35, Roberto Fagá wrote:
> Another good option to optimize games in PyGame on XO is to reduce the
> depth of the colors on:
> window = pygame.display.set_mode((400, 225), 16)
Isn't 16bpp the default?
The X display runs at 16bpp, so using any other depth causes
useless and very expe
Chris Ball wrote:
>> We figured out, a combination of pygame.event.wait() and
>> pygame.event.get() very good. That's the demo code; it takes less
>> than 4% cpu (0.3% - 1.7% here):
>
> That's cool. Note that this won't work for any pygame activity that
> wants to do something in the b
Hello Chris
Nice work! Anyway, you are only locking in the event manager, this is
great to games which doesn't need to render each frame.
A good option to use, when you need to process something in the
background, is to use the pygame.time.Clock(), like:
MAXFPS = 20 #for example
clock = pygame.ti
Hi,
> Hi! Mcfletch and I have been talking about the heavy cpu-load of
> the wiki's pygame demo: 99%; and how to reduce it.
> We figured out, a combination of pygame.event.wait() and
> pygame.event.get() very good. That's the demo code; it takes less
> than 4% cpu (0.3% - 1.7% her
Hi!
Mcfletch and I have been talking about the heavy cpu-load of the wiki's
pygame demo: 99%; and how to reduce it.
We figured out, a combination of pygame.event.wait() and
pygame.event.get() very good. That's the demo code; it takes less than
4% cpu (0.3% - 1.7% here):
import sys
import pyga
19 matches
Mail list logo
