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

["René Dudfield" <renesd@xxxxxxxxx>]

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