Re: [pygame] nokia s60 branch merge...

[René Dudfield]

hi again,

all but one of the files were just conflicts between the various py3k
changes... so just added the one file.

Jussi, are you able to test trunk?  Everything should be merged in from your
branch now :)

Thinking of testing the symbian stuff in the future... perhaps we can set up
an emulator for building and testing?  Then we can make sure future changes
work ok on symbian too.  What OS's are the compiler(s) and emulator
available for?  Is that symbian/how_to_build.txt file up to date?


cheers,



On Sat, May 9, 2009 at 1:01 PM, René Dudfield  wrote:

> Excellent, thanks :)I just sat down to finish off merging in the rest
> of lib/ test/ and examples/ stuff from the symbian branch.
>
> I'll try out your build with portable python on vista once I've done with
> that stuff.
>
> cu,
>
>
>
>
>
> On Sat, May 9, 2009 at 12:53 PM, Lenard Lindstrom  wrote:
>
>> I had to make a few small fixes to get it compiling again with Python 3.1,
>> but nothing major. I got some XP time so built an installer (separate post).
>> It is hardly a release quality, but it is available for emergencies.
>>
>> Lenard
>>
>>
>>
>

Re: [pygame] nokia s60 branch merge...

[René Dudfield]

Excellent, thanks :)I just sat down to finish off merging in the rest of
lib/ test/ and examples/ stuff from the symbian branch.

I'll try out your build with portable python on vista once I've done with
that stuff.

cu,




On Sat, May 9, 2009 at 12:53 PM, Lenard Lindstrom  wrote:

> I had to make a few small fixes to get it compiling again with Python 3.1,
> but nothing major. I got some XP time so built an installer (separate post).
> It is hardly a release quality, but it is available for emergencies.
>
> Lenard
>
>
>

Re: [pygame] nokia s60 branch merge...

[Lenard Lindstrom]

I had to make a few small fixes to get it compiling again with Python 
3.1, but nothing major. I got some XP time so built an installer 
(separate post). It is hardly a release quality, but it is available for 
emergencies.


Lenard


René Dudfield wrote:

hi,

I've committed some things... but still about 13 files to fix up.  All 
the .c and .h files have been committed... but nothing is tested 
yet... compiles though (on ubuntu jaunty i386 python2.6).


there seems to be an issue with pygame.h and the ifdefs.  I think it's 
to do with the intptr_t defs/undefs... but haven't looked into it much.


Will do the lib/ test/ and examples/ conflicts tomorrow.


cu!



On Fri, May 8, 2009 at 2:29 AM, Lenard Lindstrom > wrote:


I have committed the latest changes so Pygame now builds normally
for Python 3.1. There may be a few error messages regarding
compiling optional .py files, but they can be ignored. I will get
to them later.

Good luck,

Lenard

René Dudfield wrote:

cool.  I'll try and do a portable python3 windows build on
saturday.

Up to about 40 files left with conflicts in them... it's all
been easy so far... just time consuming.


cu,



On Thu, May 7, 2009 at 5:01 PM, Lenard Lindstrom
mailto:le...@telus.net>
>> wrote:

   Hi,

   No, I don't have ready access to XP at the moment, though I
could
   probably cross-build from Python 2.5 if absolutely
necessary, as I
   did for Python 2.6.

   Lenard

   René Dudfield wrote:

   nice one.

   Well, I only did 2 files I think this morning... so
feel free
   to keep going if you like.  It's no big deal if you
keep going
   I think.  I'll just update from r2077 any of your
changes past
   that before I commit.

   Do you have access to a windows machine at the moment?  If
   not, I'll try and build the installer for the python
3.x that
   Andre Krause is using.


   Andre: can you please confirm that you're using windows
   portable python 3.0.1 from http://www.portablepython.com/ ?

   Also, what day do you need pygame ready by?


   cheers,



   On Thu, May 7, 2009 at 1:01 PM, Lenard Lindstrom
   mailto:le...@telus.net>
>
   

   
  
   >
  ../../symbian_s60_patch.diff


  where 1761 was the revision the symbian branch was
   copied...
  and 2075 is the current revision on trunk

  I'm using this command to merge the changes into
the trunk.
  ./trunk/ $ svn merge -r1761:2075
  svn://seul.org/svn/pygame/branches/symbian_s60/

   
  
  



  I'm working through the merge conflicts slowly,
   hopefully more
  free time on the weekend... expect a day or
two... or
   three :)



  cu,




  On Thu, May 7, 2009 at 4:56 AM, Lenard Lindstrom
  mailto:le...@telus.net>
>
   

[pygame] [ANN]: experimental Pygame 1.9.0 installer for Python 3.0.1 on Win32

[Lenard Lindstrom]

Hi everyone,

I have built Pygame 1.9.0 (rev 2104) for Python 3.0.1. As the subject 
line states it is experimental, though most tests pass. It was not built 
on my own computer so I would suggest running an antivirus scan on the 
installed pygame directory, and even the installer itself, before using.


installer at: 
http://www3.telus.net/len_l/pygame/experimental/pygame-1.9.0a0.win32-py3.0.msi


size: 3,014,656 bytes

md5sum: 401ec16f6d3500fc5f11ecfca097d785  pygame-1.9.0a0.win32-py3.0.msi

Lenard

[pygame] App Store

[Cary Harper]

Would anyone be interested in putting their software into an App Store  
for ARM Linux Netbooks?

Re: [pygame] SDL_ffmpeg vs ffmpeg

[Tyler Laing]

Another significant difference I just found is that SDL_ffmpeg has no
support for subtitle streams. Supporting subtitle streams is smart, it
allows for it to be easier to internationalize games by having the game
select the subtitle stream it wants to play. Plus, I like my cutscenes to
have subtitles in english, as I'm hard of hearing. :)

-Tyler

On Thu, May 7, 2009 at 4:59 PM, Tyler Laing  wrote:

> Hi Rene,
>
> Perhaps. But SDL_ffmpeg is a separate project, another dependency. FFmpeg
> is much more likely to be on someone's system. SDL_ffmpeg also uses a
> completely different build system, complicating the process of using it
> within pygame. I'm having trouble getting it built against ffmpeg 0.5.0 and
> I can't find any info or instructions on building it. If I'm having trouble,
> it'll also be difficult for others. Its just not ready for wide-scale usage,
> in my personal view.
>
> Like I said, I am definitely leaning towards just using ffmpeg directly. It
> also means I have greater control over whats going on, and don't have to try
> to fiddle and be stopped by the limitations of sdl_ffmpeg.
>
> -Tyler
>
>
> On Thu, May 7, 2009 at 4:33 PM, René Dudfield  wrote:
>
>> Hi,
>>
>> I think you will end up re implementing many of the things from SDL_ffpmeg
>> anyway.
>>
>> Overlay is pretty good - and is designed for movie playback.  However it
>> has limitations.
>> The C docs are here: http://sdl.beuc.net/sdl.wiki/SDL_Overlay
>>
>> It's probably a good idea to get basic playback working first, and then
>> worry about other features.
>>
>> SDL_ffmpeg has most of what is needed to remake the current Movie module
>> using ffmpeg.
>>
>>
>> cu,
>>
>>
>>
>> On Fri, May 8, 2009 at 2:27 AM, Tyler Laing  wrote:
>>
>>> Hello all,
>>>
>>> I've been looking at SDL_ffmpeg and ffmpeg.
>>>
>>> There are some considerations for choosing each. SDL_ffmpeg is fairly
>>> simple to interact with, load, play, pause a movie. You can interact with
>>> each frame, and so on. However, SDL_ffmpeg converts every frame from YUV to
>>> RGB, to make it easier on the programmers to use image manipulation
>>> functions and so on. This is a performance hit, for sure. Considering
>>> Python's reputation already for being slow, having a movie module take that
>>> kind of hit will result in a further stain to the reputation, when
>>> sometimes, rarely, movies stutter or pause when they shouldn't. It can take
>>> a long time to recover from a negative reputation.
>>>
>>> For ffmpeg, it offers much the same capability, but without the SDL
>>> conveniences. It does offer far more capability with movie files than
>>> SDL_ffmpeg does though. I think, but I'm not sure, that the pygame surfaces
>>> do not need to have the frames of the movie be in YUV format? Or its a quick
>>> operation to convert the surface for YUV then back to RGB. Something like
>>> that, correct me if I'm wrong. So we don't need every frame to be converted
>>> to RGB, except when we do need it.
>>>
>>> If I went with ffmpeg, I was considering a design where we explicitly
>>> convert the movie from YUV to RGB, with a simple convert function. From the
>>> point its called, to the point it is called again, the movie is in RGB
>>> format. It fits with the python philosophy that "Explicit is better than
>>> implicit." (-The Zen of Python, by Tim Peters)
>>>
>>> Personally, I would prefer to work with ffmpeg, because of the greater
>>> functionality, and the lack of conversion performance hit.
>>>
>>> -Tyler
>>>
>>> --
>>> Visit my blog at http://oddco.ca/zeroth/zblog
>>>
>>
>>
>
>
> --
> Visit my blog at http://oddco.ca/zeroth/zblog
>



-- 
Visit my blog at http://oddco.ca/zeroth/zblog

Re: [pygame] A silly request

[pymike]

Yes I saw! Thanks Rene :D

On Fri, May 8, 2009 at 3:46 AM, René Dudfield  wrote:

> Snakey finally shook off all that goo that was stuck on Snakeys head... but
> now Snakey is on the look out for more goo.
>
> and some new spotlight projects finally...  including Bubbman 2!
>
> cu,
>
>
>
>
> On Fri, May 8, 2009 at 12:46 AM, pymike  wrote:
>
>> Can someone put the poor old snake's real head back on (on the main site -
>> pygame.org)? It might be the least little bit confuzzling to newcomers :)
>>
>> --
>> - pymike
>>
>
>


-- 
- pymike

Re: [pygame] PyGame and SVG

[Peter Gebauer]

Hey Daniel.

OpenVG could be hardware accelerated through OpenGL if no
other hw is available. If you can select backend and make your OpenVG
implementation render on SDL surfaces you'd end up with a complete
drawing kit for almost all 2D needs. It could potentially replace existing
drawing libraries for SDL/PyGame. Using it in some sort of
retained mode could make it faster than drawing pixels, as is the case
already for most 2D operations done in OpenGL. (most notably blending,
transformations, even pixel based operations like bump mapping etc)

The only drawback so far is that there are very few (if any) complete
implementations at all and certainly no free. That is also true for
SVG. Both are good, yet fairly unknown/unpopular standards, sadly. :/

/Peter

On 2009-05-07 (Thu) 20:59, Daniel Jo wrote:
> The OpenVG one is very interesting and if development continues it could be
> very useful once desktop hardware acceleration becomes available.  At that
> point, I see it likely that SDL and PyGame will implement the creation of
> OpenVG surfaces in a similar way that they now allow the creation of OpenGL
> surfaces.  I do, however, wonder at the interoperability of OpenGL and
> OpenVG. . .
> In any case, right now I`m mosting interesting in the rendering of static
> SVG images.  Features like picking would be nice, though. . .
> -Daniel
> 
> On Wed, May 6, 2009 at 7:37 AM, RB[0]  wrote:
> 
> > There are pygame libraries on the pygame.org site for both SVG and OpenVG,
> > though both are limited, and I think the SVG one is only for opengl
> > rendering.
> >
> > http://www.pygame.org/project/962/ -- SVG lib
> > http://www.pygame.org/project/964/ -- OpenVG
> >
> > These might be useful to you, if only as a reference :)
> >
> > On Wed, May 6, 2009 at 7:21 AM, Peter Gebauer <
> > peter.geba...@stockholm.bostream.se> wrote:
> >
> >> Hi!
> >>
> >> I'm not sure, but maybe something like OpenVG would be useful?
> >> http://www.khronos.org/openvg/
> >>
> >> Once you have a OpenVG implementation for SDL/PyGame you have a complete
> >> and free API to do vector graphics for games, UI's and what not with
> >> (potentially) hardware acceleration specifically for vector graphics.
> >>
> >> Just FYI. :)
> >>
> >> /Peter
> >>
> >> On 2009-05-05 (Tue) 18:47, Daniel Jo wrote:
> >> > I don't have very much time during the week, but I'll try to get it
> >> working
> >> > in Windows (XP) this weekend.  As for OS X, I don't own a system running
> >> OS
> >> > X, so unfortunately there's little that I can do there. . .
> >> > -Daniel
> >> >
> >> > On Tue, May 5, 2009 at 8:48 AM, Bo Jangeborg  wrote:
> >> >
> >> > > Do you know if this will be made available for Windows and OS X too ?
> >> > >
> >> > > Bo)
> >> > >
> >> > > Daniel Jo skrev:
> >> > >
> >> > >> I was thinking about UIs today and recalled a post by Brad Wardel
> >> about
> >> > >> the UI in Galactic Civilizations. He mentioned how it would look
> >> pretty much
> >> > >> the same regardless of the resolution one runs the game at, due to
> >> the use
> >> > >> of SVG. Presumably, the UI is designed as vector drawings and at
> >> runtime
> >> > >> rendered to a texture whose size depends upon the current screen
> >> resolution.
> >> > >>
> >> > >> I thought that this would be a great idea for PyGame, but then I
> >> found
> >> > >> that the only implementation of SVG that exists for PyGame actually
> >> uses
> >> > >> Cairo. Personally, I think that using Cairo within PyGame is, at
> >> best,
> >> > >> suboptimum. What you end up with is a whole lot of redundant library
> >> that is
> >> > >> doing exactly nothing. It would be much better to have a
> >> implementation with
> >> > >> relatively atomic dependencies.
> >> > >>
> >> > >> Fortunately, after a bit of googling I discovered SDL_svg. It appears
> >> to
> >> > >> require only libxml-2.0 and libSDL. Perfect. It also has a very small
> >> API.
> >> > >> Perfect. After a bit more research I managed to create my own Python
> >> > >> bindings using Pyrex. Take a look:
> >> > >>
> >> > >> http://code.google.com/p/pygame-svg/
> >> > >>
> >> > >> -Daniel
> >> > >>
> >> > >>
> >> 
> >> > >>
> >> > >>
> >> > >> No virus found in this incoming message.
> >> > >> Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database:
> >> > >> 270.12.15/2093 - Release Date: 05/02/09 14:23:00
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >>
> >
> >

Re: [pygame] nokia s60 branch merge...

[René Dudfield]

hi,

I've committed some things... but still about 13 files to fix up.  All the
.c and .h files have been committed... but nothing is tested yet... compiles
though (on ubuntu jaunty i386 python2.6).

there seems to be an issue with pygame.h and the ifdefs.  I think it's to do
with the intptr_t defs/undefs... but haven't looked into it much.

Will do the lib/ test/ and examples/ conflicts tomorrow.


cu!



On Fri, May 8, 2009 at 2:29 AM, Lenard Lindstrom  wrote:

> I have committed the latest changes so Pygame now builds normally for
> Python 3.1. There may be a few error messages regarding compiling optional
> .py files, but they can be ignored. I will get to them later.
>
> Good luck,
>
> Lenard
>
> René Dudfield wrote:
>
>> cool.  I'll try and do a portable python3 windows build on saturday.
>>
>> Up to about 40 files left with conflicts in them... it's all been easy so
>> far... just time consuming.
>>
>>
>> cu,
>>
>>
>>
>> On Thu, May 7, 2009 at 5:01 PM, Lenard Lindstrom > le...@telus.net>> wrote:
>>
>>Hi,
>>
>>No, I don't have ready access to XP at the moment, though I could
>>probably cross-build from Python 2.5 if absolutely necessary, as I
>>did for Python 2.6.
>>
>>Lenard
>>
>>René Dudfield wrote:
>>
>>nice one.
>>
>>Well, I only did 2 files I think this morning... so feel free
>>to keep going if you like.  It's no big deal if you keep going
>>I think.  I'll just update from r2077 any of your changes past
>>that before I commit.
>>
>>Do you have access to a windows machine at the moment?  If
>>not, I'll try and build the installer for the python 3.x that
>>Andre Krause is using.
>>
>>
>>Andre: can you please confirm that you're using windows
>>portable python 3.0.1 from http://www.portablepython.com/ ?
>>
>>Also, what day do you need pygame ready by?
>>
>>
>>cheers,
>>
>>
>>
>>On Thu, May 7, 2009 at 1:01 PM, Lenard Lindstrom
>>mailto:le...@telus.net>
>>>> wrote:
>>
>>   Hi René,
>>
>>   Yeah, I kind of poured the code in there the last few days. I
>>   could have waited. I can use the time to clean up the remaining
>>   Python 3 changes before making another commit. I have
>>updated all
>>   the modules that make sense for Python 3.1. setup.py will skip
>>   those modules not ported so a Python 3 build will be as
>>simple as
>>   any other. I also need to spend some time on the test
>>framework.
>>
>>   Lenard
>>
>>
>>   René Dudfield wrote:
>>
>>   hi,
>>
>>   I made a diff like this:
>>   ./trunk/ $ svn diff -r1761:2075
>>   svn://seul.org/svn/pygame/branches/symbian_s60/
>>
>>   
>>    >
>>   ../../symbian_s60_patch.diff
>>
>>
>>   where 1761 was the revision the symbian branch was
>>copied...
>>   and 2075 is the current revision on trunk
>>
>>   I'm using this command to merge the changes into the trunk.
>>   ./trunk/ $ svn merge -r1761:2075
>>   svn://seul.org/svn/pygame/branches/symbian_s60/
>>
>>   
>>   
>>
>>
>>
>>   I'm working through the merge conflicts slowly,
>>hopefully more
>>   free time on the weekend... expect a day or two... or
>>three :)
>>
>>
>>
>>   cu,
>>
>>
>>
>>
>>   On Thu, May 7, 2009 at 4:56 AM, Lenard Lindstrom
>>   mailto:le...@telus.net>
>>>
>>   
>>>
>>  Hi,
>>
>>  I guess I have made Pygame trunk a moving target the
>>last few
>>  days. I got carried away. So I am freezing commits
>>at rev
>>   2075 --
>>  with the exception to base_test.py -- until the
>>symbian_s60
>>   branch is merged back into trunk.
>>
>>  Lenard
>>
>>
>>
>>  Jussi Toivola wrote:
>>
>>  Hello,
>>  I merged the latest trunk revisions(1993->2052) to
>>   symbian_s60
>>  branch
>>  and tested the compilation on Ubuntu as well.
>>The tests
>>   passed on
>>  Ubuntu, except audio tests becaus

Re: [pygame] A silly request

[René Dudfield]

Snakey finally shook off all that goo that was stuck on Snakeys head... but
now Snakey is on the look out for more goo.

and some new spotlight projects finally...  including Bubbman 2!

cu,



On Fri, May 8, 2009 at 12:46 AM, pymike  wrote:

> Can someone put the poor old snake's real head back on (on the main site -
> pygame.org)? It might be the least little bit confuzzling to newcomers :)
>
> --
> - pymike
>