[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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