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

["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.
>>>>>
>>>>
>>>
>>>
>>
>