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
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: [email protected] >> 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] Re: Mac Installers (was: 100% CPU FAQ)
y an >> inaccurate comment on the downloads page (http://pygame.org/download.shtml): >> >> "pyobjc is needed for OSX 10.3 and 10.4, not 10.5" >> >> I think the rationale for the comment on the download page was that the >> system python (2.5) on Mac OS X has PyObjC 2.0 preinstalled - however as the >> pygame installers target the user-installed framework builds of python, >> there is no PyObjC available for pygame to use, if the user has not >> installed one. >> >> So in fact, pyobjc is required for all os x revisions for pygame, and I >> believe the pyObjC installer on the pygame download page will suffice for >> all 3 revisions as well. >> >> So if the web page could be clarified, that would be great - but mostly I >> wanted it to be clear what the expectation of the current Mac OS X support >> for pygame is, so if people have a different experience or require something >> different than what is provided, they can report it. >> >> >> >> On Thu, Jul 31, 2008 at 4:09 PM, Brian Fisher <[EMAIL PROTECTED]> >> wrote: >>> >>> 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] Re: Mac Installers (was: 100% CPU FAQ)
I thought you would ask so I went offline and started working on assembling a final testbench of code and cleaning up the readme file and uploading. The pygame code is 2 years old (I did not have any Mac Pygame binaries/support to follow along with the latest developments). But surprisingly you won't find many lines of code and it is very short, simple, and relies almost entirely on the underlying API framework to do the heavy lifting. Pygame, Pyglet, and Pyglet+Rabbyt versions of the same program here URL: http://pyglet.googlecode.com/issues/attachment?aid=-6168358247731042672&name=shadowtestbattery2.zip Cheers, PN 2008/8/12 René Dudfield <[EMAIL PROTECTED]>: > hi, > > Where is this code you are using? I got a 404 with the link you > posted in a previous message. > > > > On Tue, Aug 12, 2008 at 3:56 PM, Python Nutter <[EMAIL PROTECTED]> wrote: >> I look forward to a non PyObjC tied down version of Pygame on OS X. >> >> I have installed the old 1.4 PyObjC to get Pygame 1.8.1 running on OS X >> 10.5.4. >> >> I decided to re-run the shadow test bench to compare all the libraries >> including the newest Pygame: >> >> Note that all data files are the same (graphics and ogg file audio) >> only difference is the api and python script loading and animating >> (parallax scrolling + screen scrolling + audio decode and play). >> >> As a side note Pygame and SDL is a large install and PyObjC is 19 MB >> on top of that. That is a quite hefty install compared to other >> frameworks (i.e. Pyglet is around 6 and includes within that as an >> optional dependency AVBIN to decode mp3 files, ogg files, video files, >> etc. without it you just decode wav files etc.) >> >> Another warning deprecation error for Pygame on OS X and Python 2.5.2: >> >> 008-08-12 15:26:23.122 Python[2514:613] Warning once: This >> application, or a library it uses, is using NSQuickDrawView, which has >> been deprecated. Apps should cease use of QuickDraw and move to >> Quartz. >> >> About 35 seconds to load the sprites and decode the ogg file and start >> the Pygame window (system locked up with 100% cpu during >> initialization). >> >> Test system: PPC G4 CPU, ATI RV280 GPU, 1 GB RAM, OS X 10.5.4, Python >> Reference Framework 2.5.2, PyObjC 1.4, Pygame 1.8.1. (Bash#1: $top -o >> cpu, Bash#2 (normal):$python shadow.py, Bash#2 (optimisation):$python >> -O shadow.py >> >> Pygame version of the shadow test bench: >> o Is using only 56% to 61% CPU use. >> o Running Pygame with python optimizations turned on did not show >> noticeable decrease in CPU use >> o Animations on the system includes minor stuttering which is still >> playable but will show an end product running on this system using the >> above API as being less polished looking. >> o Audio decoding is flawless, but then again unlike Linux, on the Mac, >> the OpenAL sound layer is well written and actually works. >> >> Pyglet 1.1 version of the shadow test bench: >> o Is using 18% only CPU use. >> o Running Pyglet with python optimizations turned on did not show >> noticeable decrease in CPU use (however, interestingly on the new >> Intel Core 2 Duo CPUs, it does - but then the initial CPU utilisation >> is higher at 46% on the Intel CPU and nVidia 8600 GPU equipped >> machine). >> o Animations on the system includes minor stuttering which is still >> playable but will show an end product running on this system using the >> above API as being less polished looking. >> o Audio decoding is flawless, but then again unlike Linux, on the Mac, >> the OpenAL sound layer is well written and actually works. >> >> Pyglet 1.1 + Rabbyt 0.8.1 version of the same shadow test bench: >> o Is only using is taking 6-7% CPU use with a spike to 18% for a >> fraction of a second during the beginning of the full screen scroll >> with a then immediate drop back down to 6-7% CPU use. >> o Running Pyglet+Rabbyt with python optimizations turned on did not >> show noticeable decrease in the initial CPU utilisation. >> o Animations are silky smooth and fast with non perceptible stuttering >> in the scrolling sprites >> o Audio decoding is flawless, but again thats being done by Pyglet >> with Rabbyt handling just the sprite animations. >> o Rabbyt is only a 285KB addon egg to distribute with a game along >> with Pyglet + AVBIN at 6MB. Also the clear winner for performance + >> distribution size. >> >> >> I'll have to get motivated an make a complete test bench archive with >> all version for anyone to test on any processor +
Re: [pygame] Re: Mac Installers (was: 100% CPU FAQ)
Thank you for the update Rene, I have renamed it to shadow-pygame-alternate.py I re-ran the tests, there is a CPU use reduction, but not as drastic, but the initialisation is a lot faster and very much improved =) CPU use of shadow-pygame-alternate.py is now averaging 43% CPU on the same system used in the previous tests in this post. Initialisation of the Pygame window is almost instantaneous. I have yet to test the modified Pygame version on the Linux and Core 2 Duo Macbook Pro systems. Cheers, PN 2008/8/12 René Dudfield <[EMAIL PROTECTED]>: > hi, > > I've attached an updated version of the shadow demo for pygame. > > It does most of the things listed on my list (except for using dirty > rects, and using sprite sheets). So it could still be improved... but > these are just the easy changes. > > So it should load much quicker, and run much faster. It uses about 1% > cpu on my machine. > > It'd be interesting to see how these changes affect your measurements. > > > cu, > > > > On Tue, Aug 12, 2008 at 5:06 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >> hi, >> >> I remember that demo now... looks really cool and old school :) >> >> a few notes... >> >> - the whole ogg music is decompressed before playback. Better to use >> pygame.mixer.music to stream it. >> - you could put all of the sprites together in a sprite sheet, and use >> threads to load. Pygame can use multiple cpus to decode images... to >> speed up loading. >> - don't need to initialise all of pygame. Only the display, and mixer >> need initialising. >> - there is no frame rate limiting. No use of pygame.time.Clock Other >> examples use frame limiting. >> - the whole screen is updated every frame. Pygame doesn't need to >> update the whole screen. Could probably use sprite.LayeredDirty for >> easiest way to do layers with dirty rect handling to speed things up. >> Otherwise keep track of dirty rects manually. >> - does not convert the images into native format before displaying. >> This gives massive speed increases. convert() or convert_alpha() >> depending on the image. >> - The pygame version is simpler. No decorators, classes to be made, >> or functions required to be written, and no need to use inheritance. >> No need to register callbacks, which makes the code more explicit and >> less magical(a library, not a framework). >> - pygame version is only 139 lines, verses 218 lines for rabbit and >> 190 lines for pyglet. >> >> >> >> cheers, >> >> >> >> >> On Tue, Aug 12, 2008 at 4:37 PM, Python Nutter <[EMAIL PROTECTED]> wrote: >>> I thought you would ask so I went offline and started working on >>> assembling a final testbench of code and cleaning up the readme file >>> and uploading. >>> >>> The pygame code is 2 years old (I did not have any Mac Pygame >>> binaries/support to follow along with the latest developments). But >>> surprisingly you won't find many lines of code and it is very short, >>> simple, and relies almost entirely on the underlying API framework to >>> do the heavy lifting. >>> >>> Pygame, Pyglet, and Pyglet+Rabbyt versions of the same program here >>> URL: >>> http://pyglet.googlecode.com/issues/attachment?aid=-6168358247731042672&name=shadowtestbattery2.zip >>> >>> Cheers, >>> PN >>> >>> >>> 2008/8/12 René Dudfield <[EMAIL PROTECTED]>: >>>> hi, >>>> >>>> Where is this code you are using? I got a 404 with the link you >>>> posted in a previous message. >>>> >>>> >>>> >>>> On Tue, Aug 12, 2008 at 3:56 PM, Python Nutter <[EMAIL PROTECTED]> wrote: >>>>> I look forward to a non PyObjC tied down version of Pygame on OS X. >>>>> >>>>> I have installed the old 1.4 PyObjC to get Pygame 1.8.1 running on OS X >>>>> 10.5.4. >>>>> >>>>> I decided to re-run the shadow test bench to compare all the libraries >>>>> including the newest Pygame: >>>>> >>>>> Note that all data files are the same (graphics and ogg file audio) >>>>> only difference is the api and python script loading and animating >>>>> (parallax scrolling + screen scrolling + audio decode and play). >>>>> >>>>> As a side note Pygame and SDL is a large install and PyObjC is 19 MB >>>>> on top of that. That is a quite hefty install compared to other >&g
Re: [pygame] Re: Mac Installers (was: 100% CPU FAQ)
Thank you for the updates DR0ID,
I have run your pygame-alternate2.py: 39.6% CPU on Mac OS X, up to 42%
CPU during full screen scrolling.
I notice the spikes in CPU in the rabbyt version as well both on Linux
(Pentium M / Intel GPU) and Mac (PPC G4 / ATI GPU) both systems spend
the majority of the time around the 6%-7% CPU mark and usually during
the full screen scroll I see a spike upwards towards 18% CPU for what
seems to last less than a second then immediately drops back down to
6%-7% CPU range. I can only guess that it might be related to
loading/addressing of textures.
Animations under Ubuntu 7.10 Gutsy Gibbon running on Dell Latitude D510 hardware
Linux Kernel 2.6.22-15-generic
Gnome 2.20.1
Intel Celeron M processor 1.4GHz
512MB Ram
With pyglet a good trick is $python -m pyglet.info which will dump
information on your system including the detected/reported OpenGL
system (what it supports/extensions). It might be useful for
comparison purposes:
Mac OS X System Information:
python -m pyglet.info
Python
--
sys.version: 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)]
sys.platform: darwin
os.getcwd(): /Users/pn/Documents/PYTHON FILES/Example Code/Game
Frameworks/PyGame, Pyglet, and Rabbyt Combined/shadowtestbattery2
pyglet
--
pyglet.version: 1.1
pyglet.__file__:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/pyglet/__init__.py
pyglet.options['debug_trace_depth'] = 1
pyglet.options['audio'] = ('directsound', 'openal', 'alsa', 'silent')
pyglet.options['xsync'] = True
pyglet.options['debug_trace_flush'] = True
pyglet.options['debug_win32'] = False
pyglet.options['debug_gl_trace'] = False
pyglet.options['debug_x11'] = False
pyglet.options['shadow_window'] = True
pyglet.options['debug_font'] = False
pyglet.options['debug_media'] = False
pyglet.options['debug_trace'] = False
pyglet.options['debug_lib'] = False
pyglet.options['graphics_vbo'] = True
pyglet.options['vsync'] = None
pyglet.options['debug_trace_args'] = False
pyglet.options['debug_gl'] = True
pyglet.options['debug_graphics_batch'] = False
pyglet.options['font'] = ('gdiplus', 'win32')
pyglet.options['debug_texture'] = False
pyglet.options['debug_gl_trace_args'] = False
pyglet.window
--
platform:
display:
screens[0]: CarbonScreen(x=0, y=0, width=1680, height=1050)
config['double_buffer'] = 1
config['stereo'] = 0
config['buffer_size'] = 32
config['aux_buffers'] = 0
config['sample_buffers'] = 0
config['samples'] = 0
config['red_size'] = 8
config['green_size'] = 8
config['blue_size'] = 8
config['alpha_size'] = 8
config['depth_size'] = 32
config['stencil_size'] = 0
config['accum_red_size'] = 0
config['accum_green_size'] = 0
config['accum_blue_size'] = 0
config['accum_alpha_size'] = 0
context: CarbonGLContext()
pyglet.gl.gl_info
--
gl_info.get_version(): 1.3 ATI-1.5.28
gl_info.get_vendor(): ATI Technologies Inc.
gl_info.get_renderer(): ATI Radeon 9200 OpenGL Engine
gl_info.get_extensions():
GL_APPLE_aux_depth_stencil
GL_APPLE_client_storage
GL_APPLE_element_array
GL_APPLE_fence
GL_APPLE_flush_buffer_range
GL_APPLE_flush_render
GL_APPLE_packed_pixels
GL_APPLE_pixel_buffer
GL_APPLE_specular_vector
GL_APPLE_texture_range
GL_APPLE_transform_hint
GL_APPLE_vertex_array_object
GL_APPLE_vertex_array_range
GL_APPLE_vertex_program_evaluators
GL_APPLE_ycbcr_422
GL_ARB_imaging
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_occlusion_query
GL_ARB_pixel_buffer_object
GL_ARB_shader_objects
GL_ARB_shading_language_100
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_texture_rectangle
GL_ARB_transpose_matrix
GL_ARB_vertex_blend
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_vertex_shader
GL_ARB_window_pos
GL_ATI_array_rev_comps_in_4_bytes
GL_ATI_blend_equation_separate
GL_ATI_blend_weighted_minmax
GL_ATI_text_fragment_shader
GL_ATI_texture_env_combine3
GL_ATI_texture_mirror_once
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_geometry_shader4
GL_EXT_gpu_program_parameters
GL_EXT_multi_draw_arrays
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texture_compression_dxt1
GL_EXT_texture_c
