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
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
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
...We'll port it to C.
while 1{};
I think you mean:
while(1) {}; // c has parentheses!
:)
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
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
-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
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
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
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
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.
