Re: [pygame] Re: Mac Installers (was: 100% CPU FAQ)

["Python Nutter" <pythonnutter@xxxxxxxxx>]

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 <renesd@xxxxxxxxx>:
> 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 <renesd@xxxxxxxxx> 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 <pythonnutter@xxxxxxxxx> 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 <renesd@xxxxxxxxx>:
>>>> 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 <pythonnutter@xxxxxxxxx> 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 <renesd@xxxxxxxxx>:
>>>>>> 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 <brian@xxxxxxxxxxxxxxxxxxx> 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 <brian@xxxxxxxxxxxxxxxxxxx>
>>>>>>> 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 <pythonnutter@xxxxxxxxx>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>