Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

On Mon, May 4, 2009 at 4:44 PM, Lenard Lindstrom  wrote:

> Ok, the transform problems were caused by the Mac not having MMX, so some
> untested code was conditionally compiled. As for the unit test errors I
> don't know what is happening there. Some newly added unit tests to
> base_test.py were ported back from the python3 trunk. That is where the
> Python 2.5 and 2.6 builds fail. What is happening to Python 2.4 is a
> mystery.
>
> Lenard
>


hi,


it looks like that test is failing because of the missing scrap module.

I guess that test was disabled before.  So if we put in a new scrap for osx
then that test should pass.


cheers,

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Lenard Lindstrom]

Ok, the transform problems were caused by the Mac not having MMX, so 
some untested code was conditionally compiled. As for the unit test 
errors I don't know what is happening there. Some newly added unit tests 
to base_test.py were ported back from the python3 trunk. That is where 
the Python 2.5 and 2.6 builds fail. What is happening to Python 2.4 is a 
mystery.


Lenard

René Dudfield wrote:
... and it looks like Lenard has fixed it already too.  Latest svn 
trunk compiles on osx again.


cu,

On Mon, May 4, 2009 at 8:03 AM, René Dudfield > wrote:


hi,

looks like some changes from the py3k merge that Lenard just did.

Note, that the build bot last built successfully: revision 2047

So you can always check out that revision, that built successfully
on osx, until trunk is fixed.



This is also points out how changes on one platform can easily
break other platforms, and why the buildbot is so awesome.


cu,




On Mon, May 4, 2009 at 1:33 AM, Brian Fisher
mailto:br...@hamsterrepublic.com>> wrote:

My automated build machine is having the same problem on OS X,
so I'd say it's nothing wrong with your setup:
http://thorbrian.com/pygame/builds.php


On Sun, May 3, 2009 at 12:14 AM, el lauwer
mailto:el.lau...@gmail.com>> wrote:

Oi,

Ok, I will use git as for my daily work, and submit my
code to svn if
I need a global feedback.

I have solved the problem with architecture, but now I get
the following
syntax error in the pygame code:

rc/transform.c:57: error: syntax error before ‘_state’
src/transform.c:58: warning: initialization makes integer
from pointer without a cast
src/transform.c:59: error: ‘filter_shrink_X_ONLYC’
undeclared here (not in a function)
src/transform.c:59: warning: excess elements in scalar
initializer
src/transform.c:59: warning: (near initialization for
‘_state’)
src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’
undeclared here (not in a function)
src/transform.c:60: warning: excess elements in scalar
initializer
src/transform.c:60: warning: (near initialization for
‘_state’)
src/transform.c:61: error: ‘filter_expand_X_ONLYC’
undeclared here (not in a function)
src/transform.c:61: warning: excess elements in scalar
initializer
src/transform.c:61: warning: (near initialization for
‘_state’)
src/transform.c:62: error: ‘filter_expand_Y_ONLYC’
undeclared here (not in a function)
src/transform.c:62: warning: excess elements in scalar
initializer
src/transform.c:62: warning: (near initialization for
‘_state’)
src/transform.c:62: warning: data definition has no type
or storage class
src/transform.c: In function ‘surf_scalesmooth’:
src/transform.c:1416: warning: passing argument 3 of
‘scalesmooth’ from incompatible pointer type
src/transform.c: In function ‘surf_get_smoothscale_backend’:
src/transform.c:1437: error: request for member
‘filter_type’ in something not a structure or union
src/transform.c: In function ‘surf_set_smoothscale_backend’:
src/transform.c:1443: warning: initialization from
incompatible pointer type
src/transform.c:1497: error: ‘filter_type’ undeclared
(first use in this function)
src/transform.c:1497: error: (Each undeclared identifier
is reported only once
src/transform.c:1497: error: for each function it appears in.)
src/transform.c: In function ‘inittransform’:
src/transform.c:2739: warning: assignment from
incompatible pointer type
lipo: can't figure out the architecture type of:
/var/tmp//cc47AiT3.out

error: command 'gcc' failed with exit status 1

Re: [pygame] PyGame and SVG

[Jussi Toivola]

Cool, I have been looking for pygame SVG library for some time.

2009/5/4 Daniel Jo :
> 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
>
>



-- 

Jussi Toivola

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

... and it looks like Lenard has fixed it already too.  Latest svn trunk
compiles on osx again.

cu,

On Mon, May 4, 2009 at 8:03 AM, René Dudfield  wrote:

> hi,
>
> looks like some changes from the py3k merge that Lenard just did.
>
> Note, that the build bot last built successfully: revision 2047
>
> So you can always check out that revision, that built successfully on osx,
> until trunk is fixed.
>
>
>
> This is also points out how changes on one platform can easily break other
> platforms, and why the buildbot is so awesome.
>
>
> cu,
>
>
>
>
> On Mon, May 4, 2009 at 1:33 AM, Brian Fisher wrote:
>
>> My automated build machine is having the same problem on OS X, so I'd say
>> it's nothing wrong with your setup:
>> http://thorbrian.com/pygame/builds.php
>>
>>
>> On Sun, May 3, 2009 at 12:14 AM, el lauwer  wrote:
>>
>>> Oi,
>>>
>>> Ok, I will use git as for my daily work, and submit my code to svn if
>>> I need a global feedback.
>>>
>>> I have solved the problem with architecture, but now I get the following
>>> syntax error in the pygame code:
>>>
>>> rc/transform.c:57: error: syntax error before ‘_state’
>>> src/transform.c:58: warning: initialization makes integer from pointer
>>> without a cast
>>> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:59: warning: excess elements in scalar initializer
>>> src/transform.c:59: warning: (near initialization for ‘_state’)
>>> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:60: warning: excess elements in scalar initializer
>>> src/transform.c:60: warning: (near initialization for ‘_state’)
>>> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:61: warning: excess elements in scalar initializer
>>> src/transform.c:61: warning: (near initialization for ‘_state’)
>>> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not
>>> in a function)
>>> src/transform.c:62: warning: excess elements in scalar initializer
>>> src/transform.c:62: warning: (near initialization for ‘_state’)
>>> src/transform.c:62: warning: data definition has no type or storage class
>>> src/transform.c: In function ‘surf_scalesmooth’:
>>> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
>>> incompatible pointer type
>>> src/transform.c: In function ‘surf_get_smoothscale_backend’:
>>> src/transform.c:1437: error: request for member ‘filter_type’ in
>>> something not a structure or union
>>> src/transform.c: In function ‘surf_set_smoothscale_backend’:
>>> src/transform.c:1443: warning: initialization from incompatible pointer
>>> type
>>> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
>>> function)
>>> src/transform.c:1497: error: (Each undeclared identifier is reported only
>>> once
>>> src/transform.c:1497: error: for each function it appears in.)
>>> src/transform.c: In function ‘inittransform’:
>>> src/transform.c:2739: warning: assignment from incompatible pointer type
>>> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
>>> error: command 'gcc' failed with exit status 1
>>>
>>> Slu
>>>
>>>
>>>
>>>
>>> On 3-mei-09, at 07:48, Nirav Patel wrote:
>>>
>>>  I personally found/find it useful to use a personal git repo, and use
 git-svn to stay up to date with the Pygame SVN.  You can use "git svn
 rebase" to keep your repo up to date with upstream and then commit
 with "git svn dcommit" when you have code that others can
 use/test/hack.

 There is a decent guide for using git-svn with github here:
 http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

 That is also useful so you have a repo to work in until 1.9 is
 released and you can start committing to Pygame SVN.

 Nirav

 On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:

> Hi,
>
> more below...
>
> On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:
>
>>
>> Oi,
>>
>> I am installing the latest version of pygame on svn,
>> so I can start coding on my camera module. I am
>> installing it under virtualenv so I can keep using
>> the stable pygame release for my current games.
>>
>> 1)
>> I recently reseaved a svn account for the pygame
>> svn repository. How do you sugest I use this account
>> during the development prossess, should I use it to
>> commit all my changes to the main brange, or should
>> I make a personal brange just for my work on the
>> camera module. Can I use my github account instead,
>> if so, what must I do with the changes and bug
>> fixel to the main pygame development brange.
>>
>
>
> You might want to work on the main trunk, or not... depending on a
> number of
> things.
>
> Either a separate branch or in your git hub is probably a good way to
> g

Re: [pygame] Movie module information

[Tyler Laing]

Thanks Rene, Lenard! I'll begin looking at the two libraries, and learning
the ins and outs of writing a c-library for Python over the next week.

-Tyler

On Sat, May 2, 2009 at 10:20 PM, René Dudfield  wrote:

> Hi,
>
> it looks like SDL_ffmpeg 1.0 has been released:
> http://www.arjanhouben.nl/SDL_ffmpeg/
>
>
>
>
> On Tue, Apr 28, 2009 at 4:13 AM, Lenard Lindstrom  wrote:
>
>> Here is my first attempt at ffmpeg for Windows. It is for Python's 2.4 and
>> 2.5:
>>
>> http://www3.telus.net/len_l/pygame/experimental/ffmpeg.tar.gz
>>
>> md5sum:
>> db4d51a61dbd56a1453e332774dfa494 *ffmpeg.tar.gz
>>
>> Lenard
>>
>>
>> Lenard Lindstrom wrote:
>>
>>>
>>> Tyler Laing wrote:
>>>
 Hello all,

 One of the first steps I need to take for the GSoC project is to get
 user stories so I can build acceptance tests.

 I want to hear what you guys(the users) want out of an updated movie
 module. What do you want to be able to do, and how?

 I'm also interested in hearing what people liked and didn't like about
 the current movie module.

 -Tyler

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

>>>
>>>
>>>
>>> P.S.
>>>
>>> I am working on getting the ffmpeg libraries ready for Windows. I have
>>> built them using the proper C runtime for Python 2.5 (cross-compiled from
>>> linux). Once I can collect together the necessary headers and import
>>> libraries I will bundle them up and make them available. But they will have
>>> limited capability for now. I have only succeeded with an mpg to avi
>>> conversion so far. After this I will try customizing msys_build_deps.py for
>>> ffmpeg.
>>>
>>> L.L.
>>>
>>>
>>
>> --
>> Lenard Lindstrom
>> 
>>
>>
>


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

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[René Dudfield]

hi,

looks like some changes from the py3k merge that Lenard just did.

Note, that the build bot last built successfully: revision 2047

So you can always check out that revision, that built successfully on osx,
until trunk is fixed.



This is also points out how changes on one platform can easily break other
platforms, and why the buildbot is so awesome.


cu,



On Mon, May 4, 2009 at 1:33 AM, Brian Fisher wrote:

> My automated build machine is having the same problem on OS X, so I'd say
> it's nothing wrong with your setup:
> http://thorbrian.com/pygame/builds.php
>
>
> On Sun, May 3, 2009 at 12:14 AM, el lauwer  wrote:
>
>> Oi,
>>
>> Ok, I will use git as for my daily work, and submit my code to svn if
>> I need a global feedback.
>>
>> I have solved the problem with architecture, but now I get the following
>> syntax error in the pygame code:
>>
>> rc/transform.c:57: error: syntax error before ‘_state’
>> src/transform.c:58: warning: initialization makes integer from pointer
>> without a cast
>> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:59: warning: excess elements in scalar initializer
>> src/transform.c:59: warning: (near initialization for ‘_state’)
>> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:60: warning: excess elements in scalar initializer
>> src/transform.c:60: warning: (near initialization for ‘_state’)
>> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:61: warning: excess elements in scalar initializer
>> src/transform.c:61: warning: (near initialization for ‘_state’)
>> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in
>> a function)
>> src/transform.c:62: warning: excess elements in scalar initializer
>> src/transform.c:62: warning: (near initialization for ‘_state’)
>> src/transform.c:62: warning: data definition has no type or storage class
>> src/transform.c: In function ‘surf_scalesmooth’:
>> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
>> incompatible pointer type
>> src/transform.c: In function ‘surf_get_smoothscale_backend’:
>> src/transform.c:1437: error: request for member ‘filter_type’ in something
>> not a structure or union
>> src/transform.c: In function ‘surf_set_smoothscale_backend’:
>> src/transform.c:1443: warning: initialization from incompatible pointer
>> type
>> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
>> function)
>> src/transform.c:1497: error: (Each undeclared identifier is reported only
>> once
>> src/transform.c:1497: error: for each function it appears in.)
>> src/transform.c: In function ‘inittransform’:
>> src/transform.c:2739: warning: assignment from incompatible pointer type
>> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
>> error: command 'gcc' failed with exit status 1
>>
>> Slu
>>
>>
>>
>>
>> On 3-mei-09, at 07:48, Nirav Patel wrote:
>>
>>  I personally found/find it useful to use a personal git repo, and use
>>> git-svn to stay up to date with the Pygame SVN.  You can use "git svn
>>> rebase" to keep your repo up to date with upstream and then commit
>>> with "git svn dcommit" when you have code that others can
>>> use/test/hack.
>>>
>>> There is a decent guide for using git-svn with github here:
>>> http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/
>>>
>>> That is also useful so you have a repo to work in until 1.9 is
>>> released and you can start committing to Pygame SVN.
>>>
>>> Nirav
>>>
>>> On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:
>>>
 Hi,

 more below...

 On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:

>
> Oi,
>
> I am installing the latest version of pygame on svn,
> so I can start coding on my camera module. I am
> installing it under virtualenv so I can keep using
> the stable pygame release for my current games.
>
> 1)
> I recently reseaved a svn account for the pygame
> svn repository. How do you sugest I use this account
> during the development prossess, should I use it to
> commit all my changes to the main brange, or should
> I make a personal brange just for my work on the
> camera module. Can I use my github account instead,
> if so, what must I do with the changes and bug
> fixel to the main pygame development brange.
>


 You might want to work on the main trunk, or not... depending on a
 number of
 things.

 Either a separate branch or in your git hub is probably a good way to
 go.
 If you put things in svn, then it's easier for some of the pygame
 developers
 to watch your work, and maybe even make changes.  However it's up to
 you.

 Best to merge your work in occasionally into a svn branch at least.   Or
 send the mailing list a link to your

Re: [pygame] Cairo + SDL

[Marius Gedminas]

On Sun, May 03, 2009 at 07:32:39AM -0700, Yanom Mobis wrote:
> Is cairo used for game programming?

There are a few games using Cairo:
http://lists.cairographics.org/archives/cairo/2006-May/007032.html

It was not designed specifically for games, though, unlike SDL.

Marius Gedminas
-- 
We don't care.  We don't have to.  We're the Phone Company.


signature.asc
Description: Digital signature

[pygame] PyGame and SVG

[Daniel Jo]

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

Re: [pygame] vector type: mutable or immutable

[Gregor Lingl]

Lorenz Quack schrieb:

Gregor Lingl wrote:

...
pression without the in-place operator (as would be necessary if we 
go with immutable types).

Hi Lorenz,

I'd propose not to confuse two things:
(1) use of syntax x = x + x versus x += x
(2) use of immutable versus mutable datatypes

In python you can write

 >>> a = 2
 >>> a = a + a
 >>> a
4

as well as

 >>> a += a
 >>> a
8

although the int type is immutable.


true, but as a performance test I think my approach is still valid 
because if you do
ok. my objection concerned also some previous postings in this thread 
that stated,

that use of a+=b makes a mutable vector type necessary.

>>> a = 2
>>> a += a
I believe the interpreter internally takes the two operands (in this 
case a and a)  adds them and then rebinds the result to a (the id 
changes) so effectively doing

>>> a = a + a
exactly because a is immutable
if a were mutable the two expressions would be indeed different the += 
version would not create a new instance and rebind the name a to it 
but modify the object a is referring to, while a = a + a would again 
create a new object and rebind it.

So therefore I believe that this test does make sense.
Tell me if I'm wrong somewhere.



here are the calls with the results:



[snip]



which has more than 3 digits. Which result did you get after 
1000 executions of the statement x = x + x?


And which implementation of the long integer type did you use that is 
that much faster than Python's ?


Regards,
Gregor



indeed those are valid objections. well first of all I used a 
self-written C extension with double as the underlying type. but the 
result after 1023 iterations turns into (inf, inf). this could of 
course invalidate the results so I modified the test:


>>> timeit.repeat("x = Vector2d(2,3); x += x", "from vector import 
Vector2d", repeat=5, number=1000)

[5.1832518577575684,
 5.1106431484222412,
 5.1510121822357178,
 5.0923140048980713,
 5.0608019828796387]

>>> timeit.repeat("x = Vector2d(2,3); x = x + x", "from vector import 
Vector2d", repeat=5, number=1000)

[6.5348029136657715,
 6.3499071598052979,
 6.4433431625366211,
 6.412431001663208,
 6.4398849010467529]

>>> timeit.repeat("x = Vector2d(2,3)", "from vector import Vector2d", 
repeat=5, number=1000)

[3.7264928817749023,
 3.6346859931945801,
 3.6241021156311035,
 3.7733709812164307,
 3.6264529228210449]

Did you use two different Vector2d classes here, one mutable and one 
immutable? Why do they
have the same name then? Or did you merely implement the operations x+=x 
and x=x+x differently?


If x = x + y creates a new object x or changes x is also a matter of how 
it is implemented.


Moreover it is my conviction  that one must not decide  about  which 
data type to use on

the basis of a +- 50 percent difference in performance.

One more remark: At least on module of the standard library of Python 
has a (rather simple)
2d-Vector class implemented in pure Python, which of course has a 
considerably worse performance,

by a factor of 4 approximately:

>>> timeit.repeat("x = Vec2D(2,3); x = x + x", "from turtle import 
Vec2D", repeat=1, number=1000)

[25.274672320512536]

Nevertheless one would expect a class implemented in C to run *much* 
faster than a pure Python solution.
So I suspect that your implementation may not be sufficiently 
significant to serve as a criterion to

decide that issue.

Best regards,
Gregor
.







so the numbers change but the overall result stays the same.

Re: [pygame] vector type: mutable or immutable

[DR0ID]

Hi




Brian Fisher pointed out two advantages of immutable vector types:
1) they prevent bugs in programs like the following (adopted from Brian):
> class Angel(object)
> def __init__(self, offset):
> self.offset = offset
>
> t = Angel()
> halo_pos = t.offset
> halo_pos.y -= 5  # BUG: this changes the offset in t



If you have a certain number of objects that you want to move 
simultaneous you could share the self.pos vector and by only changing it 
at one place all objects would change place too. For example a sprite 
that should always follow:


class Entity:

 def __init__(self):
   self.pos = Vec2(x,y)
   self.sprite.pos = self.pos

e = Entity()

by updating e.pos.x = 10 the sprite would follow automatically

To avoid the bug that Brian had I used this:

   def _set_values(self, other):
   self.x = other.x
   self.y = other.y
   values = property(None, _set_values, doc='set only,value assignemt')

This is basically the same as writing:

v.x = w.x
v.y = w.y

but more elegant:

v.values = w

So it can be used like this:

class Angel(object)
   def __init__(self, offset):
   self.offset = offset

t  = Angel()
halo_pos.values = t.offset   # <- set the values rather change the 
reference

halo_pos.y -= 5  # does not change t anymore

I'm for mutable vectors so far.

~DR0ID

Re: [pygame] vector type: mutable or immutable

[Lorenz Quack]

Gregor Lingl wrote:



Lorenz Quack schrieb:

Hi again,

I just did a quick performance test.
The first run uses an in-place operation (as could be used with 
mutable types) the second run on the other hand uses the equivalent 
expression without the in-place operator (as would be necessary if we 
go with immutable types).

Hi Lorenz,

I'd propose not to confuse two things:
(1) use of syntax x = x + x versus x += x
(2) use of immutable versus mutable datatypes

In python you can write

 >>> a = 2
 >>> a = a + a
 >>> a
4

as well as

 >>> a += a
 >>> a
8

although the int type is immutable.


true, but as a performance test I think my approach is still valid because if 
you do

>>> a = 2
>>> a += a
I believe the interpreter internally takes the two operands (in this case a and 
a)  adds them and then rebinds the result to a (the id changes) so effectively 
doing

>>> a = a + a
exactly because a is immutable
if a were mutable the two expressions would be indeed different the += version 
would not create a new instance and rebind the name a to it but modify the 
object a is referring to, while a = a + a would again create a new object and 
rebind it.

So therefore I believe that this test does make sense.
Tell me if I'm wrong somewhere.



here are the calls with the results:

>>> timeit.repeat("x += x", "from vector import Vector2d; x = 
Vector2d(2, 3)", repeat=5, number=1000)

[1.4092800617218018,
 1.4093708992004395,
 1.4093561172485352,
 1.413952112197876,
 1.4092509746551514]

Can you explain a bit how you implemented this. Seems miraculous to me as
even for plain integers I get:

 >>> timeit.repeat("x += x", "x = 2", number=1000)
[0.00030635119219368789, 0.00030155776880746998, 0.000303348264651504]
 >>> timeit.repeat("x += x", "x = 2", number=1)
[0.023589079352177578, 0.023484539926357684, 0.023433343760189018]
 >>> timeit.repeat("x += x", "x = 2", number=10)
[2.1454171779987519, 2.1408996934512743, 2.1383358762293483]

highly nonlinear, which seems to have its cause in

 >>> x


[snip very large number]



which has more than 3 digits. Which result did you get after 
1000 executions of the statement x = x + x?


And which implementation of the long integer type did you use that is 
that much faster than Python's ?


Regards,
Gregor



indeed those are valid objections. well first of all I used a self-written C 
extension with double as the underlying type. but the result after 1023 
iterations turns into (inf, inf). this could of course invalidate the results 
so I modified the test:


>>> timeit.repeat("x = Vector2d(2,3); x += x", "from vector import Vector2d", 
repeat=5, number=1000)

[5.1832518577575684,
 5.1106431484222412,
 5.1510121822357178,
 5.0923140048980713,
 5.0608019828796387]

>>> timeit.repeat("x = Vector2d(2,3); x = x + x", "from vector import 
Vector2d", repeat=5, number=1000)

[6.5348029136657715,
 6.3499071598052979,
 6.4433431625366211,
 6.412431001663208,
 6.4398849010467529]

>>> timeit.repeat("x = Vector2d(2,3)", "from vector import Vector2d", 
repeat=5, number=1000)

[3.7264928817749023,
 3.6346859931945801,
 3.6241021156311035,
 3.7733709812164307,
 3.6264529228210449]

so the numbers change but the overall result stays the same.


//Lorenz




>>> timeit.repeat("x = x + x", "from vector import Vector2d; x = 
Vector2d(2, 3)", repeat=5, number=1000)

[2.3679590225219727,
 2.3530960083007812,
 2.3615989685058594,
 2.3519301414489746,
 2.3658668994903564]

that is quite an overhead IMHO.
Of course it is quite possible you could tweak this a bit but I 
imagine the result would stay more or less the same.


Note that the vector type in this example was implemented as C extension.

This make me once more lean towards mutable.



Lorenz Quack wrote:

Hi,

I'm against implementing both. I think it makes what should be a 
rather simple class overcomplicated. Imagine the zoo of class we 
would have:

Vector2d, Vector2dConst, IntVector2d IntVectro2dConst, Vector3d, ...

I think we should make up our minds and then sick with one.

And I have to add that even though I started off favoring mutable 
vectors I then remembered also running into the subtle bugs Brian 
mentioned. So now I'm leaning in the immutable direction.




Brian Fisher wrote:
I guess making both would be the most pythonic - python gives you 
both lists and tuples...


On Fri, May 1, 2009 at 11:04 AM, Jake b > wrote:


Could you make both? Default to mutable, and use VectorConst ( 
insert

better name ) where needed.

   .offset = Vector3Const(1,2,3)
   .vel = Vector3( offset )

(throw exception when you try to modify a const vector?)
--
Jake

Re: [pygame] vector type: mutable or immutable

[Gregor Lingl]

Lorenz Quack schrieb:

Hi again,

I just did a quick performance test.
The first run uses an in-place operation (as could be used with 
mutable types) the second run on the other hand uses the equivalent 
expression without the in-place operator (as would be necessary if we 
go with immutable types).

Hi Lorenz,

I'd propose not to confuse two things:
(1) use of syntax x = x + x versus x += x
(2) use of immutable versus mutable datatypes

In python you can write

>>> a = 2
>>> a = a + a
>>> a
4

as well as

>>> a += a
>>> a
8

although the int type is immutable.


here are the calls with the results:

>>> timeit.repeat("x += x", "from vector import Vector2d; x = 
Vector2d(2, 3)", repeat=5, number=1000)

[1.4092800617218018,
 1.4093708992004395,
 1.4093561172485352,
 1.413952112197876,
 1.4092509746551514]

Can you explain a bit how you implemented this. Seems miraculous to me as
even for plain integers I get:

>>> timeit.repeat("x += x", "x = 2", number=1000)
[0.00030635119219368789, 0.00030155776880746998, 0.000303348264651504]
>>> timeit.repeat("x += x", "x = 2", number=1)
[0.023589079352177578, 0.023484539926357684, 0.023433343760189018]
>>> timeit.repeat("x += x", "x = 2", number=10)
[2.1454171779987519, 2.1408996934512743, 2.1383358762293483]

highly nonlinear, which seems to have its cause in

>>> x
1998004186028769015888065528660067181960858278108363383543058547726291664928514696654974662664899300806328788897098600375993215312353125816942708494985750397779259747342186492700854746224958531600557062482177474171210574456780329137382053701351847035829394105715289393603049664690951086500585573041613915541943482204464085952702410661555993795850233239741543571551911043440162640590409235898458518591247841931595747116317335050991594626289612498520523675882610161165372063070268357479245669981772715516124209213272744261175590644689944021616972739082803671702719716071207148043745816311133161214372922537945679589243684535158699277786714495177523918275313524822250041417409740930358792797420218400727869491236181203226755797120593727197116049522897866094104445720262754191916714638971796992809144767750341404484665266873788846594763755466306573888435872250603815737807207326566323005452279868305608142343829847806683749870788911792602584394512835434467087089503104758621784536364804905511504189409284371887725731265488462664169484443102986630005435500128457652423645098699201114914669929356966538361903791911538349019346448835480865680911764218275810751293544279953243570530114339709669124975036644766500637291010944228739868335963356340510245625956130389612590810678309314959882594998380697015088672829011263314792013386764854632868079160242560521968424495028415669424449662820608137207439280323711483312878944506929890499400629019780186324537905488857410952850944506335029042364462910776748616465284401266050275066258730328683450412512310623589477238285809522891309854256836350367062654105950990741122876479146455879346060212154913696954855664390698455967672872327529485939091813344738248272651864246671286271788930438203764247659481815832772046470901918777533472806459155987802304308896007274430138231182223992003061178215458842064460848524071386986432105855139251716891644709189290553846216394611612560653033472898687523464819506684666579460565918347138546026572846623519210460990343354066327419044513904920804286775310395288033056296044696663762195118843920952958777040397082034697971897022010938493234468286270619876811846537907173039488540172140572710041711240590987049601015930431298393665302134882019356459039083232354350859950400197746147557524213717815419388232208760572479008906475791837415205785207869796522015497753457058362129369782877872981295691824232243866014158010741180843760257131188073981417760659337432233119224646639966218464501657323606437608788951459735241938716395687718559385002466538703893864154486710547311324964475756677761499985536632668806372089272374075795686260656876469408218886131829438566823819503704784246553487699811231273768658780788840052350619537012102658742028981727922832411121070946711398534018827505436582848144685358751301395311349518682026204506856601608181591746590884271026146041003431968484615209384194658145802832127079217611184047147537712957044801855542229782689848339912143435725968730679563617389482135070704742308087319862177939497131760177572394986871585849240810353449202450123680802393257974534760614099672243594896935820149569271238932965844947226823027113435858356393611210745296828225669571648251824390920236882481869956592663408400506083732338992463747172130497082023739088447576578379424161029150282723929610739446329141129996959075314349096257194812154678317550664710431218871838550398702028939260340274348386750098385907265902022305859036725656383836433033529118930316560979685122334963007356105357573254339992985938987540915897522932562218599640414740266606489020107707571023776069482963973302291586453698019860004734723371105883468841198507439304899958509663186874126

Re: [pygame] vector type: mutable or immutable

[Jake b]

For naming, I prefer 'Vector3' vs 'Vector3d'. I think the 'd'
is unnecessary/redundant.
-- 
Jake

[pygame] draw text and rectangle with pygame

[He Jibo]

Hello,
Could anyone please give me some hint on how to draw text and box in
the same screen with pygame? If you can share me some sample code,
that would be great! I wish I could draw a screen looks like the one
in the following link, that would be great!

https://cid-bbc15003189d7799.skydrive.live.com/self.aspx/Public/Screen.GIF

Thank you so much ! Have a nice weekend!

Re: [pygame] vector type: mutable or immutable

[Lorenz Quack]

Hi again,

I just did a quick performance test.
The first run uses an in-place operation (as could be used with mutable types) 
the second run on the other hand uses the equivalent expression without the 
in-place operator (as would be necessary if we go with immutable types).


here are the calls with the results:

>>> timeit.repeat("x += x", "from vector import Vector2d; x = Vector2d(2, 3)", 
repeat=5, number=1000)

[1.4092800617218018,
 1.4093708992004395,
 1.4093561172485352,
 1.413952112197876,
 1.4092509746551514]

>>> timeit.repeat("x = x + x", "from vector import Vector2d; x = Vector2d(2, 
3)", repeat=5, number=1000)

[2.3679590225219727,
 2.3530960083007812,
 2.3615989685058594,
 2.3519301414489746,
 2.3658668994903564]

that is quite an overhead IMHO.
Of course it is quite possible you could tweak this a bit but I imagine the 
result would stay more or less the same.


Note that the vector type in this example was implemented as C extension.

This make me once more lean towards mutable.



Lorenz Quack wrote:

Hi,

I'm against implementing both. I think it makes what should be a rather 
simple class overcomplicated. Imagine the zoo of class we would have:

Vector2d, Vector2dConst, IntVector2d IntVectro2dConst, Vector3d, ...

I think we should make up our minds and then sick with one.

And I have to add that even though I started off favoring mutable 
vectors I then remembered also running into the subtle bugs Brian 
mentioned. So now I'm leaning in the immutable direction.




Brian Fisher wrote:
I guess making both would be the most pythonic - python gives you both 
lists and tuples...


On Fri, May 1, 2009 at 11:04 AM, Jake b > wrote:


Could you make both? Default to mutable, and use VectorConst ( insert
better name ) where needed.

   .offset = Vector3Const(1,2,3)
   .vel = Vector3( offset )

(throw exception when you try to modify a const vector?)
--
Jake

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

[Jussi Toivola]

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 because it's on a virtual machine without
any audio devices and testLoadIcon, which was unable to locate
pygame/pygame_icon.bmp( checked and it wasn't there )... Anyway, feel
free to start merging the branch to trunk.

The build is available at:
http://pygame-symbian-s60.googlecode.com/files/pygame-S60_py25_SVN-2054_20090503_GCCE-UREL.sisx

2009/5/2 Lenard Lindstrom :
> I've just committed the changes to SVN. As for the mixer crash, there is a
> know cleanup problem with SDL_mixer 1.2.8 that has been fixed in SVN. I use
> the SVN version in Windows. It doesn't seem to help in Debian though. I will
> double check that the proper library is used. As for smpeg there is some
> recent activity (three months ago), but for the most part nothing has been
> checked in for nearly two years. The sndarray test also fails, though the
> sound_array_demos.py works.
>
> Lenard
>
> René Dudfield wrote:
>>
>> hi,
>>
>> awesome.
>>
>> As for the mixer crash... I think it might be smpeg related.  I think
>> on win/mac/source we are using svn smpeg with some patches that
>> haven't made it into Debian as smpeg hasn't had any releases in ages.
>> I haven't confirmed this yet though.  I noticed Tyler had a crash on
>> mixer/ubuntu too.
>>
>>
>>
>>
>> On Sat, May 2, 2009 at 10:57 AM, Lenard Lindstrom  wrote:
>>
>>>
>>> Hi René,
>>>
>>> Good timing. I am preparing to merge python3 back into trunk. It builds
>>> and
>>> passes all tests in Python 2.5 on Windows. There is a mixer.music problem
>>> on
>>> Debian Linux though, causing mixer_music_test.py to crash. I think it is
>>> an
>>> SDL_mixer issue (not recent SVN), but am not sure. Otherwise mixer and
>>> mixer.music work. I will commit what I have then try a Python 3.1 build.
>>> Even if it doesn't build right away there are enough other fixes,
>>> basically
>>> in error checking and removing outdated coding, to make it worthwhile as
>>> is.
>>>
>>> Lenard
>>>
>>>
>>> René Dudfield wrote:
>>>

 hello,

 I have spoken to Jussi Toivola, about merging his pys60 branch into
 trunk before pygame 1.9 is released.

 So... the process we have decided is to slowly merge in changes... in
 small groups if possible.  This will allow us to discuss his changes,
 and to try and make sure things still build and run ok on various
 platforms.

 We can discuss any issues on the mailing list as they come up.

 Is this ok?  Lenard... what do you think?   How does this go with the
 py3k branch?  Should we try and merge more of that first... or at the
 same time... or after?





>>>
>>>
>
>



-- 

Jussi Toivola

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Brian Fisher]

My automated build machine is having the same problem on OS X, so I'd say
it's nothing wrong with your setup:
http://thorbrian.com/pygame/builds.php

On Sun, May 3, 2009 at 12:14 AM, el lauwer  wrote:

> Oi,
>
> Ok, I will use git as for my daily work, and submit my code to svn if
> I need a global feedback.
>
> I have solved the problem with architecture, but now I get the following
> syntax error in the pygame code:
>
> rc/transform.c:57: error: syntax error before ‘_state’
> src/transform.c:58: warning: initialization makes integer from pointer
> without a cast
> src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:59: warning: excess elements in scalar initializer
> src/transform.c:59: warning: (near initialization for ‘_state’)
> src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:60: warning: excess elements in scalar initializer
> src/transform.c:60: warning: (near initialization for ‘_state’)
> src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:61: warning: excess elements in scalar initializer
> src/transform.c:61: warning: (near initialization for ‘_state’)
> src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in
> a function)
> src/transform.c:62: warning: excess elements in scalar initializer
> src/transform.c:62: warning: (near initialization for ‘_state’)
> src/transform.c:62: warning: data definition has no type or storage class
> src/transform.c: In function ‘surf_scalesmooth’:
> src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
> incompatible pointer type
> src/transform.c: In function ‘surf_get_smoothscale_backend’:
> src/transform.c:1437: error: request for member ‘filter_type’ in something
> not a structure or union
> src/transform.c: In function ‘surf_set_smoothscale_backend’:
> src/transform.c:1443: warning: initialization from incompatible pointer
> type
> src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
> function)
> src/transform.c:1497: error: (Each undeclared identifier is reported only
> once
> src/transform.c:1497: error: for each function it appears in.)
> src/transform.c: In function ‘inittransform’:
> src/transform.c:2739: warning: assignment from incompatible pointer type
> lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
> error: command 'gcc' failed with exit status 1
>
> Slu
>
>
>
>
> On 3-mei-09, at 07:48, Nirav Patel wrote:
>
>  I personally found/find it useful to use a personal git repo, and use
>> git-svn to stay up to date with the Pygame SVN.  You can use "git svn
>> rebase" to keep your repo up to date with upstream and then commit
>> with "git svn dcommit" when you have code that others can
>> use/test/hack.
>>
>> There is a decent guide for using git-svn with github here:
>> http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/
>>
>> That is also useful so you have a repo to work in until 1.9 is
>> released and you can start committing to Pygame SVN.
>>
>> Nirav
>>
>> On Sun, May 3, 2009 at 1:10 AM, René Dudfield  wrote:
>>
>>> Hi,
>>>
>>> more below...
>>>
>>> On Sun, May 3, 2009 at 2:50 PM, el lauwer  wrote:
>>>

 Oi,

 I am installing the latest version of pygame on svn,
 so I can start coding on my camera module. I am
 installing it under virtualenv so I can keep using
 the stable pygame release for my current games.

 1)
 I recently reseaved a svn account for the pygame
 svn repository. How do you sugest I use this account
 during the development prossess, should I use it to
 commit all my changes to the main brange, or should
 I make a personal brange just for my work on the
 camera module. Can I use my github account instead,
 if so, what must I do with the changes and bug
 fixel to the main pygame development brange.

>>>
>>>
>>> You might want to work on the main trunk, or not... depending on a number
>>> of
>>> things.
>>>
>>> Either a separate branch or in your git hub is probably a good way to go.
>>> If you put things in svn, then it's easier for some of the pygame
>>> developers
>>> to watch your work, and maybe even make changes.  However it's up to you.
>>>
>>> Best to merge your work in occasionally into a svn branch at least.   Or
>>> send the mailing list a link to your work when you've committed something
>>> you'd like people to look at or merge in.
>>>
>>> Then when your work is getting along, talk about merging it into the
>>> trunk
>>> with the mailing list and other developers.  If no one has changed any of
>>> the files you have changed, then it's probably ok.
>>>
>>> Working in the trunk lets you take advantage of some other things... like
>>> the build bots which build on mac/win python2.4 python2.5 python2.6 and
>>> run
>>> the tests for you.  So it can save you a lot of testing work.
>>>
>>> Say yo

Re: [pygame] vector type: mutable or immutable

[Lorenz Quack]

Hi,

I'm against implementing both. I think it makes what should be a rather simple 
class overcomplicated. Imagine the zoo of class we would have:

Vector2d, Vector2dConst, IntVector2d IntVectro2dConst, Vector3d, ...

I think we should make up our minds and then sick with one.

And I have to add that even though I started off favoring mutable vectors I 
then remembered also running into the subtle bugs Brian mentioned. So now I'm 
leaning in the immutable direction.




Brian Fisher wrote:
I guess making both would be the most pythonic - python gives you both 
lists and tuples...


On Fri, May 1, 2009 at 11:04 AM, Jake b > wrote:


Could you make both? Default to mutable, and use VectorConst ( insert
better name ) where needed.

   .offset = Vector3Const(1,2,3)
   .vel = Vector3( offset )

(throw exception when you try to modify a const vector?)
--
Jake

Re: [pygame] Cairo + SDL

[Yanom Mobis]

Is cairo used for game programming?

--- On Sat, 5/2/09, Chris McCormick  wrote:

From: Chris McCormick 
Subject: [pygame] Cairo + SDL
To: pygame-users@seul.org
Date: Saturday, May 2, 2009, 12:16 PM


-Inline Attachment Follows-

Hi all,

Recently there was some talk of doing vector graphics in Pygame. Since this is
a subject that is dear to me, I thought I'd ask how hard it would be to
incorporate something like this into Pygame:



I realise this probably implies a large amount of work, but I just thought I'd
throw it on to the collective heads-up-display. Would be pretty wonderful to be
able to use Cairo's rendering capabilities from inside Pygame! :)

Best,

Chris.

---
http://mccormick.cx



  

Re: [pygame] Pygame font issues

[René Dudfield]

heh, I guess not.

It'd be good to report to slackware.  Please let me know if you do...
otherwise I'll report the bug.



On Sun, May 3, 2009 at 6:45 PM, Peter Chant  wrote:

> On Sunday 03 May 2009, René Dudfield wrote:
> > hi,
> >
> > what are the permissions of the font file?  Maybe something weird is
> > going on there?
>
> Bingo.
>
> the default font was set to 700, set it to 644 and it worked.  Sounds like
> a
> pygame installation issue, but then if it is surely someone else would have
> spotted it by now?
>
> Pete
>
>
> --
> Peter Chant
> http://www.petezilla.co.uk
>

Re: [pygame] Pygame font issues

[Peter Chant]

On Sunday 03 May 2009, René Dudfield wrote:
> hi,
>
> what are the permissions of the font file?  Maybe something weird is
> going on there?

Bingo.

the default font was set to 700, set it to 644 and it worked.  Sounds like a 
pygame installation issue, but then if it is surely someone else would have 
spotted it by now?

Pete


-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[el lauwer]

Oi,

Ok, I will use git as for my daily work, and submit my code to svn if
I need a global feedback.

I have solved the problem with architecture, but now I get the following
syntax error in the pygame code:

rc/transform.c:57: error: syntax error before ‘_state’
src/transform.c:58: warning: initialization makes integer from pointer  
without a cast
src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here  
(not in a function)

src/transform.c:59: warning: excess elements in scalar initializer
src/transform.c:59: warning: (near initialization for ‘_state’)
src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here  
(not in a function)

src/transform.c:60: warning: excess elements in scalar initializer
src/transform.c:60: warning: (near initialization for ‘_state’)
src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here  
(not in a function)

src/transform.c:61: warning: excess elements in scalar initializer
src/transform.c:61: warning: (near initialization for ‘_state’)
src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here  
(not in a function)

src/transform.c:62: warning: excess elements in scalar initializer
src/transform.c:62: warning: (near initialization for ‘_state’)
src/transform.c:62: warning: data definition has no type or storage  
class

src/transform.c: In function ‘surf_scalesmooth’:
src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’  
from incompatible pointer type

src/transform.c: In function ‘surf_get_smoothscale_backend’:
src/transform.c:1437: error: request for member ‘filter_type’ in  
something not a structure or union

src/transform.c: In function ‘surf_set_smoothscale_backend’:
src/transform.c:1443: warning: initialization from incompatible  
pointer type
src/transform.c:1497: error: ‘filter_type’ undeclared (first use in  
this function)
src/transform.c:1497: error: (Each undeclared identifier is reported  
only once

src/transform.c:1497: error: for each function it appears in.)
src/transform.c: In function ‘inittransform’:
src/transform.c:2739: warning: assignment from incompatible pointer type
lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
error: command 'gcc' failed with exit status 1

Slu



On 3-mei-09, at 07:48, Nirav Patel wrote:


I personally found/find it useful to use a personal git repo, and use
git-svn to stay up to date with the Pygame SVN.  You can use "git svn
rebase" to keep your repo up to date with upstream and then commit
with "git svn dcommit" when you have code that others can
use/test/hack.

There is a decent guide for using git-svn with github here:
http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

That is also useful so you have a repo to work in until 1.9 is
released and you can start committing to Pygame SVN.

Nirav

On Sun, May 3, 2009 at 1:10 AM, René Dudfield   
wrote:

Hi,

more below...

On Sun, May 3, 2009 at 2:50 PM, el lauwer   
wrote:


Oi,

I am installing the latest version of pygame on svn,
so I can start coding on my camera module. I am
installing it under virtualenv so I can keep using
the stable pygame release for my current games.

1)
I recently reseaved a svn account for the pygame
svn repository. How do you sugest I use this account
during the development prossess, should I use it to
commit all my changes to the main brange, or should
I make a personal brange just for my work on the
camera module. Can I use my github account instead,
if so, what must I do with the changes and bug
fixel to the main pygame development brange.



You might want to work on the main trunk, or not... depending on a  
number of

things.

Either a separate branch or in your git hub is probably a good way  
to go.
If you put things in svn, then it's easier for some of the pygame  
developers
to watch your work, and maybe even make changes.  However it's up  
to you.


Best to merge your work in occasionally into a svn branch at  
least.   Or
send the mailing list a link to your work when you've committed  
something

you'd like people to look at or merge in.

Then when your work is getting along, talk about merging it into  
the trunk
with the mailing list and other developers.  If no one has changed  
any of

the files you have changed, then it's probably ok.

Working in the trunk lets you take advantage of some other  
things... like
the build bots which build on mac/win python2.4 python2.5 python2.6  
and run

the tests for you.  So it can save you a lot of testing work.

Say you wanted to make some changes to surface.c and a bunch of  
others that
aren't part of the camera module directly, and didn't commit to  
trunk for a
few weeks... there's a good chance someone else might make changes  
to those

files.

As long as you communicate with other devs what your working on it  
should be

fine.