Re: [pygame] 100% CPU FAQ
yeah, SDL 1.3 can use an opengl video driver. SDL 1.3 isn't finished yet... but is fairly usable at the moment. At a guess it won't be finished for at least 6 months, probably more. On Thu, Aug 7, 2008 at 4:35 AM, Kevin <[EMAIL PROTECTED]> wrote: > Isn't SDL 1.3 supposed to offer hardware acceleration as a default, then > have software as a backup? It seems like I heard something about that > before... > > On Wed, Aug 6, 2008 at 9:51 AM, Frozenball <[EMAIL PROTECTED]> wrote: >> >> Personally I would love if there were an option to use hardware >> acceleration (OpenGL) instead of software rendering. I know there >> exists an option for that, but it doesn't work that well (requires >> fullscreen). > > > > -- > This, from Jach. >
Re: [pygame] 100% CPU FAQ
Isn't SDL 1.3 supposed to offer hardware acceleration as a default, then have software as a backup? It seems like I heard something about that before... On Wed, Aug 6, 2008 at 9:51 AM, Frozenball <[EMAIL PROTECTED]> wrote: > Personally I would love if there were an option to use hardware > acceleration (OpenGL) instead of software rendering. I know there > exists an option for that, but it doesn't work that well (requires > fullscreen). > -- This, from Jach.
Re: [pygame] 100% CPU FAQ
Personally I would love if there were an option to use hardware acceleration (OpenGL) instead of software rendering. I know there exists an option for that, but it doesn't work that well (requires fullscreen). On Fri, Aug 1, 2008 at 2:56 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > Pygame using more CPU resources could be completely expected because it uses > software rendering while Pyglet/rabbyt would be using openGL (i.e. hardware) >
Re: [pygame] 100% CPU FAQ
hi, Using pyglet your code won't run at all on many more machines, because it depends on opengl. pygame installs fine with binaries for the python available from python.org. If you have any issues what are they? We'd like to fix them. cheers, On Fri, Aug 1, 2008 at 8:42 AM, Python Nutter <[EMAIL PROTECTED]> wrote: > I was annoyed by the OP's observations as well. I've converted my > program to many different Python game/media APIs to observe the > differences. > > Pygame = chew up the most CPU resources > Pyglet = chews up 28% to 42% CPU (surprised that the low CPU use was > on old PowerPC G4 processors and the new latest Intel Core 2 Duo was > chewing up 42% on the same program/codebase) > Pyglet + Rabbyt = only 6%-8% CPU depending on old PowerPC G4, Intel > Celeron M, Intel Core 2 Duo, does not matter what the CPU, and *the > clear winner* for my use =) > > Pyglet and Rabbyt both are available for Mac OS X in their latest > versions, which is another reason I'm leaning heavily towards that > solution. Pygame just has been sorely lacking in the OS X installation > binaries department and I don't want to send users through installing > a DVD worth of developer tools and compiling their own Pygame and > dependencies just so they can play my game. > > Cheers, > PN >
Re: [pygame] 100% CPU FAQ
> ...We'll port it to C.
>
> while 1{};
I think you mean:
while(1) {}; // c has parentheses!
:)
Re: [pygame] 100% CPU FAQ
techtonik wrote:
Hello,
I do not know why this question is not present in FAQ yet, but - why
pygame always eats 100% of CPU time?
The following example shows 100% load even with empty event queue when
pygame.event.get() is blocking.
Also be aware, the following code will eat 100% cpu.
while 1:
pass
So obviously Python is an inefficient language. We'll port it to C.
while 1{};
Hmm, this still takes 100% cpu. That must be ineffecient?
The point is, in any programming language, with any library. Running a
full loop with no delay or blocking function will always eat 100% cpu,
regardless of language or game library.
Re: [pygame] 100% CPU FAQ
Python Nutter wrote: I was annoyed by the OP's observations as well. I've converted my program to many different Python game/media APIs to observe the differences. Pygame = chew up the most CPU resources There's nothing about pygame that inherently chews up cpu, it's all a matter of how you use it. Understanding which event-getting calls block and which don't is important (the docs could perhaps be more explicit about this in some places). -- Greg
Re: [pygame] 100% CPU FAQ
Noah Kantrowitz wrote: If you want to control your framerate (and therefore CPU usage) use pygame.time.Clock. Alternatively, use pygame.time.set_timer to arrange for a USEREVENT to be sent at regular intervals. In your event loop, use pygame.event.wait(), which does block (but only returns one event at a time). If you want to get multiple events in one go, use pygame.event.wait() to get the first one, then call pygame.event.get() to get any others that have been put in the queue since the last time round the event loop. -- Greg
Re: [pygame] 100% CPU FAQ
Pygame using more CPU resources could be completely expected because it uses software rendering while Pyglet/rabbyt would be using openGL (i.e. hardware) Also, because pygame basically requires you to write your own main loop (although it provides facilities to help), it's fairly easy to write loops that use more cpu than others. In my experience, I use OpenGL with pygame and have my own little dynamic framerate thing and get nice low CPU usages most of the time. On Thu, Jul 31, 2008 at 3:42 PM, Python Nutter <[EMAIL PROTECTED]>wrote: > I was annoyed by the OP's observations as well. I've converted my > program to many different Python game/media APIs to observe the > differences. > > Pygame = chew up the most CPU resources > Pyglet = chews up 28% to 42% CPU (surprised that the low CPU use was > on old PowerPC G4 processors and the new latest Intel Core 2 Duo was > chewing up 42% on the same program/codebase) > Pyglet + Rabbyt = only 6%-8% CPU depending on old PowerPC G4, Intel > Celeron M, Intel Core 2 Duo, does not matter what the CPU, and *the > clear winner* for my use =) > >
RE: [pygame] 100% CPU FAQ
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Python Nutter > Sent: Thursday, July 31, 2008 4:09 PM > To: pygame-users@seul.org > Subject: Re: [pygame] 100% CPU FAQ > > http://pyglet.googlecode.com/issues/attachment?aid=- > 8684410250382500806&name=shadowtestbattery.zip I see no Pygame version in this. > and > > http://sebastian-tillmann.de/stuff/shadow-1.0.0.tgz This is a 404 for me. --Noah
Re: [pygame] 100% CPU FAQ
I'm curious, In what way is Pygame currently sorely lacking in OS X installation binaries? What would you like to be different about the binaries here: http://pygame.org/download.shtml The reason I ask is cause for me they all work perfectly fine, and if there was a problem I'd like to help fix it. On Thu, Jul 31, 2008 at 3:42 PM, Python Nutter <[EMAIL PROTECTED]>wrote: > solution. Pygame just has been sorely lacking in the OS X installation > binaries department and I don't want to send users through installing > a DVD worth of developer tools and compiling their own Pygame and > dependencies just so they can play my game. > >
RE: [pygame] 100% CPU FAQ
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Python Nutter > Sent: Thursday, July 31, 2008 3:55 PM > To: pygame-users@seul.org > Subject: Re: [pygame] 100% CPU FAQ > > I've tested multiple frame rates, > > 12, 15, 24, 25, 30, 60, 90, 120, and unlimited (as much as the > hardware can put out). > > I've left my framework in the code I uploaded at 60 fps but its a > trivial matter to change the numbers and then re-run and observe the > results. I have the unlimited loop commented out as option so you can > simply comment out the fps limited clock tick loop and uncomment out > the unlimited loop. > > I've also run under standard execution and with optimization(s) turned > on in the python interpreter to see how that effects the performance > as well. Where is this code? --Noah
Re: [pygame] 100% CPU FAQ
I've tested multiple frame rates, 12, 15, 24, 25, 30, 60, 90, 120, and unlimited (as much as the hardware can put out). I've left my framework in the code I uploaded at 60 fps but its a trivial matter to change the numbers and then re-run and observe the results. I have the unlimited loop commented out as option so you can simply comment out the fps limited clock tick loop and uncomment out the unlimited loop. I've also run under standard execution and with optimization(s) turned on in the python interpreter to see how that effects the performance as well. Cheers, PN 2008/8/1 Noah Kantrowitz <[EMAIL PROTECTED]>: >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> On Behalf Of Python Nutter >> Sent: Thursday, July 31, 2008 3:43 PM >> To: pygame-users@seul.org >> Subject: Re: [pygame] 100% CPU FAQ >> >> I was annoyed by the OP's observations as well. I've converted my >> program to many different Python game/media APIs to observe the >> differences. >> >> Pygame = chew up the most CPU resources > > What framerate were you using? > > --Noah > >
RE: [pygame] 100% CPU FAQ
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Python Nutter > Sent: Thursday, July 31, 2008 3:43 PM > To: pygame-users@seul.org > Subject: Re: [pygame] 100% CPU FAQ > > I was annoyed by the OP's observations as well. I've converted my > program to many different Python game/media APIs to observe the > differences. > > Pygame = chew up the most CPU resources What framerate were you using? --Noah
Re: [pygame] 100% CPU FAQ
I was annoyed by the OP's observations as well. I've converted my program to many different Python game/media APIs to observe the differences. Pygame = chew up the most CPU resources Pyglet = chews up 28% to 42% CPU (surprised that the low CPU use was on old PowerPC G4 processors and the new latest Intel Core 2 Duo was chewing up 42% on the same program/codebase) Pyglet + Rabbyt = only 6%-8% CPU depending on old PowerPC G4, Intel Celeron M, Intel Core 2 Duo, does not matter what the CPU, and *the clear winner* for my use =) Pyglet and Rabbyt both are available for Mac OS X in their latest versions, which is another reason I'm leaning heavily towards that solution. Pygame just has been sorely lacking in the OS X installation binaries department and I don't want to send users through installing a DVD worth of developer tools and compiling their own Pygame and dependencies just so they can play my game. Cheers, PN
Re: [pygame] 100% CPU FAQ
Incidentally, if you say "start_time = time.time()" when starting your program, then get the time when ending, subtract start_time, and divide by the number of frames drawn, you get an easy FPS counter. I noticed pygame has functionality for this inbuilt. Clock.get_fps(), "Compute your game's framerate (in frames per second). It is computed by averaging the last few calls to Clock.tick - update the clock" Documentation: http://www.pygame.org/docs/ref/time.html#Clock.get_fps Examples: http://www.google.com/codesearch?q=file%3A\.py%24+pygame+Clock.get_fps
RE: [pygame] 100% CPU FAQ
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of techtonik > Sent: Thursday, July 31, 2008 4:09 AM > To: pygame-users@seul.org > Subject: Re: [pygame] 100% CPU FAQ > > On Thu, Jul 31, 2008 at 11:31 AM, Noah Kantrowitz <[EMAIL PROTECTED]> > wrote: > > >> > >> The following example shows 100% load even with empty event queue > when > >> pygame.event.get() is blocking. > > > > That would be because event.get() doesn't block. If you want to > control your > > framerate (and therefore CPU usage) use pygame.time.Clock. > > > > If it doesn't block when why print time is executed only when I pass > mouse over the window? In your original sample you had the main body of the game code indented inside the event for loop. I had assumed it was a paste error, but from what you said, maybe it wasn't. --Noah
Re: [pygame] 100% CPU FAQ
By default, Python/Pygame will run as fast as the OS lets it, which means
100% CPU usage. If you want to avoid that, there are several ways. One is
to create a Pygame Clock object ("clock = pygame.clock.Clock()", I think)
and then, in your main loop, call the clock's tick() function with the
desired framerate, eg. "clock.tick(20)". Another is to call time.sleep(),
which simply makes the program pause without using CPU cycles.
Either of these methods is usable, though if you're using Pygame already,
the Clock object is the better choice because it lets you directly control
the framerate. Either method will allow other programs to run faster,
reduce needless wear on the computer, and (especially useful for laptops)
use less energy.
There's also a method I don't recall offhand for controlling the program's
speed more precisely at the expense of still using 100% CPU, but you
probably don't need it.
Incidentally, if you say "start_time = time.time()" when starting your
program, then get the time when ending, subtract start_time, and divide by
the number of frames drawn, you get an easy FPS counter.
Re: [pygame] 100% CPU FAQ
for event in []: print time.time() event.get() will return an empty list if the event queue is empty. With your code sample, this is happening many times per second thus using a lot of cpu. Only when there is actually events in the event list will the for block be executed. Stick the time.time() inside the while just before the event.get() and you will get a better idea of how often event.get is running. On Thu, Jul 31, 2008 at 9:08 PM, techtonik <[EMAIL PROTECTED]> wrote: > On Thu, Jul 31, 2008 at 11:31 AM, Noah Kantrowitz <[EMAIL PROTECTED]> > wrote: > > >> > >> The following example shows 100% load even with empty event queue when > >> pygame.event.get() is blocking. > > > > That would be because event.get() doesn't block. If you want to control > your > > framerate (and therefore CPU usage) use pygame.time.Clock. > > > > If it doesn't block when why print time is executed only when I pass > mouse over the window? > > -- > --anatoly t. >
Re: [pygame] 100% CPU FAQ
On Thu, Jul 31, 2008 at 11:31 AM, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: >> >> The following example shows 100% load even with empty event queue when >> pygame.event.get() is blocking. > > That would be because event.get() doesn't block. If you want to control your > framerate (and therefore CPU usage) use pygame.time.Clock. > If it doesn't block when why print time is executed only when I pass mouse over the window? -- --anatoly t.
Re: [pygame] 100% CPU FAQ
event.wait() will, well, _wait_ for single events while blocking. On Thu, Jul 31, 2008 at 6:31 PM, Noah Kantrowitz <[EMAIL PROTECTED]>wrote: > techtonik wrote: > >> Hello, >> >> I do not know why this question is not present in FAQ yet, but - why >> pygame always eats 100% of CPU time? >> >> The following example shows 100% load even with empty event queue when >> pygame.event.get() is blocking. >> > > That would be because event.get() doesn't block. If you want to control > your framerate (and therefore CPU usage) use pygame.time.Clock. > > --Noah > >
Re: [pygame] 100% CPU FAQ
techtonik wrote: Hello, I do not know why this question is not present in FAQ yet, but - why pygame always eats 100% of CPU time? The following example shows 100% load even with empty event queue when pygame.event.get() is blocking. That would be because event.get() doesn't block. If you want to control your framerate (and therefore CPU usage) use pygame.time.Clock. --Noah signature.asc Description: OpenPGP digital signature
[pygame] 100% CPU FAQ
Hello, I do not know why this question is not present in FAQ yet, but - why pygame always eats 100% of CPU time? The following example shows 100% load even with empty event queue when pygame.event.get() is blocking. import time if __name__ == "__main__": import pygame pygame.init() size = width, height = 750, 550 screen = pygame.display.set_mode(size) bgcolor = 90, 90, 90 game_quit = False while not game_quit: for ev in pygame.event.get(): if ev.type == pygame.QUIT: game_quit = True print time.time() screen.fill(bgcolor) pygame.display.flip() -- --anatoly t.
