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 >>>>> 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 + GPU + Operating >>>>> system. >>>>> >>>>> I already tested on Linux: >>>>> Linux Kernel 2.6.22-15-generic >>>>> Gnome 2.20.1 >>>>> Intel Celeron M processor 1.4GHz >>>>> 512MB Ram >>>>> Intel 915M GPU >>>>> >>>>> As to be expected the audio is horrendous on most of the Linux distros >>>>> due to broken OpenAL implementations and if you use ALSA, it is also >>>>> broken. You are SOL to get good audio and 3d positioning working on >>>>> the majority of distros if your end users are using Linux. >>>>> >>>>> Cheers, >>>>> PN >>>>> >>>>> >>>>> 2008/8/11 René Dudfield <[EMAIL PROTECTED]>: >>>>>> hi, >>>>>> >>>>>> cool, I've changed the wording on the download page. >>>>>> >>>>>> >>>>>> here's some things we could do to improve pygame on OSX: >>>>>> - remove the dependency on pyobjc by rewriting those parts in C/objc. >>>>>> - make a binary installation of pyobjc 2.0 available for python.org >>>>>> python. >>>>>> - make a pygame binary for the system python on 10.5. >>>>>> - make it work for older versions of OSX. (by removing dependency on >>>>>> pyobjc). >>>>>> >>>>>> Mainly I think removing the use of pyobjc, and making a binary for the >>>>>> 10.5 system python would be nice for >>>>>> >>>>>> Also perhaps changing the way SDL is packaged. So it uses the SDL >>>>>> dlls inside the python directory. So that people could just download >>>>>> a .zip that they put where ever they want... (like in their games >>>>>> directory). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 11, 2008 at 5:22 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: >>>>>>> A poster had asserted earlier on the list that OS X installation >>>>>>> binaries >>>>>>> for pygame are lacking - I believe that the poster was misled by 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. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >