Re: [pygame] pygame.quit() not working after upgrade to python 2.6

[René Dudfield]

Hi,

thanks for reporting the bug...  it shouldn't hang things.


Note, that it's generally better to let your program end naturally, rather
than calling sys.exit.


For example, you can do it the way mentioned below...


import pygame
from pygame.locals import *

going = True

screen = pygame.display.set_mode((320,200))

while going:
events = pygame.event.get()
for e in events:
if e.type in [QUIT]:
going = False

pygame.display.flip()



cheers,


On Tue, Apr 28, 2009 at 4:04 PM, Thadeus Burgess wrote:

> Yes, using just sys.exit() hangs the game up.
>
> However, on other python programs (not using pygame) using sys.exit() does
> not hang the application up, so it is something to do with pygame.
>
> -Thadeus
>
> http://thadeusb.com
>
>
> H. L. Mencken - 
> "It is even harder for the average ape to believe that he has descended
> from man."
>
> On Tue, Apr 28, 2009 at 12:59 AM, Brian Song  wrote:
>
>> Have you tried
>>
>> if event.type == pygame.QUIT:
>>  sys.exit()
>>
>> On Tue, Apr 28, 2009 at 1:22 AM, Thadeus Burgess 
>> wrote:
>>
>>> Is there any reason pygame.quit() hangs the application up?
>>>
>>> I am running python 2.6 on Ubuntu.
>>>
>>> It works on python 2.6 in windows.
>>>
>>> What, if any information could I provide to help track down the culprite?
>>>
>>> -Thadeus
>>>
>>> http://thadeusb.com
>>>
>>>
>>>
>>
>

Re: [pygame] pygame.quit() not working after upgrade to python 2.6

[Thadeus Burgess]

Yes, using just sys.exit() hangs the game up.

However, on other python programs (not using pygame) using sys.exit() does
not hang the application up, so it is something to do with pygame.

-Thadeus

http://thadeusb.com


H. L. Mencken 
- "It is even harder for the average ape to believe that he has
descended
from man."

On Tue, Apr 28, 2009 at 12:59 AM, Brian Song  wrote:

> Have you tried
>
> if event.type == pygame.QUIT:
>  sys.exit()
>
> On Tue, Apr 28, 2009 at 1:22 AM, Thadeus Burgess wrote:
>
>> Is there any reason pygame.quit() hangs the application up?
>>
>> I am running python 2.6 on Ubuntu.
>>
>> It works on python 2.6 in windows.
>>
>> What, if any information could I provide to help track down the culprite?
>>
>> -Thadeus
>>
>> http://thadeusb.com
>>
>>
>>
>

Re: [pygame] pygame.quit() not working after upgrade to python 2.6

[Brian Song]

Have you tried

if event.type == pygame.QUIT:
 sys.exit()

On Tue, Apr 28, 2009 at 1:22 AM, Thadeus Burgess wrote:

> Is there any reason pygame.quit() hangs the application up?
>
> I am running python 2.6 on Ubuntu.
>
> It works on python 2.6 in windows.
>
> What, if any information could I provide to help track down the culprite?
>
> -Thadeus
>
> http://thadeusb.com
>
>
>

Re: [pygame] API draft for vector type

[René Dudfield]

hi again,

a slightly related point... consider that pygame already works with big
multidimensional vectors of a limited amount of types - this is Surface.

However it is limited to 1, 2, 3, and 4 uint8 multi dimensional vectors.
For these limited cases it is fairly fast.

It should be possible to make some sorts of really basic particle systems
with Surface I guess.

Having one image for positions, one for direction vectors, one for lifetime
etc.

To update the movement each frame, you'd use:
   position_surf.blit(directions_surf, (0,0), special_flags=BLEND_ADD)

Would still need a fast way to draw each particle based on the pixels in
each surface.  If pygames functions/methods took more arrays it could be
possible...  eg.  a Surface.blit_multi which took a buffer of destination
rects.




On Tue, Apr 28, 2009 at 3:06 PM, Casey Duncan  wrote:

> I have found this to be generally true as well, and storing a large number
> of individual vector objects to be operated on in a batch performs poorly
> regardless of implementation language. As an example, for Lepton I coded a
> controller object which looped over a large number of particles to update
> their velocities. Under the covers the particles are stored as a simple
> array of C structs, but you can iterate them and access the individual
> vectors for position, velocity, etc. from python.
>
> To make a long story short, the python version of the code that iterated
> and updated the velocities by manipulating vector objects was about 1600x
> slower than the equivalent C code that did the same using inline vector
> functions. psyco sped up the python code almost 5x, but it still was no
> contest.
>
> This is definitely an extreme case, but one relevant to game coding at
> least 8^)
>
> -Casey
>
>
> On Apr 27, 2009, at 7:24 PM, Daniel Jo wrote:
>
>  I've pretty much abandoned the idea of vector classes in Python.  I've
>> tested various implementations: pure python classes (with and without
>> __slots__), C++ exposed through Pyrex/Cython, tuples manipulated
>> through add/mul/div/etc functions. . .  Of these, C++ turned out to be
>> the fastest, but faster by far than that was simply not using any
>> structure at all.  Store the components in tuples for convenience, but
>> extract them and manipulated them individually for complex equations.
>> Vector classes work well for convenience and code readability, but
>> from a performance standpoint they aren't very useful.
>>
>> On Mon, Apr 27, 2009 at 4:28 PM, Brian Fisher 
>> wrote:
>>
>>> I don't see a 3 element vector type being useful from a pygame
>>> perspective.
>>> What pygame api anywhere even takes 3 element lists aside from colors?
>>> (which already have a special struct type thing)
>>>
>>> I'm not saying 3 element vectors don't have their uses - just that the
>>> seem
>>> to me to be a pretty random thing to have added to pygame, which is
>>> exclusively 2d in every interesting respect. It seems like the sort of
>>> thing
>>> to add that would add much more to the maintenance and testing cost of
>>> the
>>> pygame library than it would bring to the users as a whole. To put
>>> another
>>> way, there is no synergy between a 3 element vector class and pygame. Why
>>> would a 3 element vector class be better as part of pygame than not? what
>>> existing element of pygame is better or easier to use with a 3 element
>>> vector also being part of pygame?
>>>
>>> ...now a 2 element vector being part of pygame... rect could be better by
>>> making use of it, it could be used as an argument to the various
>>> functions
>>> that take 2 element lists, etc. etc
>>>
>>> ... and a 3 element vector (and quaternions and matrices) being part of
>>> pyOpenGL, that sounds great too...
>>>
>>>
>>>
>>> On Mon, Apr 27, 2009 at 2:59 PM, Lorenz Quack 
>>> wrote:
>>>

 Hello,

 I am interested in the inclusion of a vector and matrix types into
 pygame
 as suggested here [4]. In this email I want to propose a API for a
 vector
 module.

 I will for brevity only present the API for the types in three
 dimensions.
 The APIs for two or four dimensions should look analog.

 Also I enumerated every API for easier reference in discussions.
 Alternatives are denoted by lexical items (e.g. a) or b))
 At the end I put together a small comparison to existing
 implementations.

 This is only a suggestion to spark discussion and provoke feedback. So
 throw
 in your 2 cents.

 sincerely yours
 //Lorenz


 PS: If this turns out to be of any value I will put something similar
 together for matrix types and quaternions.




 **
 * API draft v1.0 *
 **

 In the following I will use the notation:
  v, v1, v2, ... are vectors
  s, s1, s2, ... are objects implementing the sequences
 protocol (list, tuple, the proposed vector)
  a, a1

[pygame] pygame.quit() not working after upgrade to python 2.6

[Thadeus Burgess]

Is there any reason pygame.quit() hangs the application up?

I am running python 2.6 on Ubuntu.

It works on python 2.6 in windows.

What, if any information could I provide to help track down the culprite?

-Thadeus

http://thadeusb.com

Re: [pygame] API draft for vector type

[René Dudfield]

On Tue, Apr 28, 2009 at 2:52 PM, Casey Duncan  wrote:

> On Apr 27, 2009, at 6:16 PM, René Dudfield wrote:
>
>  Would be nice if the vectors storage of things could be anything
>> underneath.  This would be useful to allow them to use pygame.Rect or
>> numpy.array underneath.  This means they can refer to a batch of vectors,
>> but also operate only on a single vector at a time.
>>
>
> +1, though there are performance vs. generality tradeoffs to be made. On
> the general side, a vector class could assume the underlying storage
> supports __getitem__, but the performance of this would suffer, I think too
> greatly. On the performance side, it could just have a pointer to an array
> of floats that it wraps with the vector api. I used this strategy with
> Lepton and the performance is great, but it is inflexible for the storage,
> and probably not very practical for totally general use across different
> storages.
>

ah, that's an interesting point.  We could have a few special cases for
giving a buffer to use.  Then as it's written in C, there will only be one
pointer indirection.




>
>  Wondering about why only 3 element vectors?  2,3, and 4 element ones are
>> common?  Is there a way to make a combined 2,3,4 type?
>>
>
> Most operations can assume the higher dimensions are always zero, or the
> length could just be variable. But in either case the code would be slower
> than it would strictly need to be, since many operations would do more work
> than needed or would require loops where they would not be required for
> single purpose 2D, 3D or better vectors.
>
>  What number types are used?  eg, can you have a float vector, a long
>> vector, an int vector?  Any python number?  A uint8 ?
>>
>
> Seems to me like the most general number type would be a double, as it
> could comfortably support a wide range, does not generally have resolution
> issues like a 32-bit float can and performs well on modern hardware. It
> would also give consistent results compared to a python float, which is
> nice.
>
> I'm not sure what the use-case is for ints or (python) longs, the latter
> would probably gain little by being coded in C compared to pure python. Even
> in sprite-based 2D games, I find integers to be far too coarse for vector
> math, and operations like normalize become basically impossible.
>
> If you support multiple vector numeric types, than you have to confront a
> combinatorial explosion of type conversions and either duplicate, templatize
> or generalize the code in such a way that you trade either performance or
> maintainability or both.
>
> -Casey



Yeah, indeed.  Old numeric used to auto-generate most of its code for
different types.  Also there is vectypes written in python that generates
it's code for all of the different types (
http://code.google.com/p/vectypes/ ).

You want to use ints for precision I guess... and other use cases too.  eg,
using 8bit uints can mean massive memory savings (a vector can fit in one
word)... and you can also use less instructions to process a vector.

Re: [pygame] API draft for vector type

[Casey Duncan]

I have found this to be generally true as well, and storing a large  
number of individual vector objects to be operated on in a batch  
performs poorly regardless of implementation language. As an example,  
for Lepton I coded a controller object which looped over a large  
number of particles to update their velocities. Under the covers the  
particles are stored as a simple array of C structs, but you can  
iterate them and access the individual vectors for position, velocity,  
etc. from python.


To make a long story short, the python version of the code that  
iterated and updated the velocities by manipulating vector objects was  
about 1600x slower than the equivalent C code that did the same using  
inline vector functions. psyco sped up the python code almost 5x, but  
it still was no contest.


This is definitely an extreme case, but one relevant to game coding at  
least 8^)


-Casey

On Apr 27, 2009, at 7:24 PM, Daniel Jo wrote:


I've pretty much abandoned the idea of vector classes in Python.  I've
tested various implementations: pure python classes (with and without
__slots__), C++ exposed through Pyrex/Cython, tuples manipulated
through add/mul/div/etc functions. . .  Of these, C++ turned out to be
the fastest, but faster by far than that was simply not using any
structure at all.  Store the components in tuples for convenience, but
extract them and manipulated them individually for complex equations.
Vector classes work well for convenience and code readability, but
from a performance standpoint they aren't very useful.

On Mon, Apr 27, 2009 at 4:28 PM, Brian Fisher > wrote:
I don't see a 3 element vector type being useful from a pygame  
perspective.
What pygame api anywhere even takes 3 element lists aside from  
colors?

(which already have a special struct type thing)

I'm not saying 3 element vectors don't have their uses - just that  
the seem

to me to be a pretty random thing to have added to pygame, which is
exclusively 2d in every interesting respect. It seems like the sort  
of thing
to add that would add much more to the maintenance and testing cost  
of the
pygame library than it would bring to the users as a whole. To put  
another
way, there is no synergy between a 3 element vector class and  
pygame. Why
would a 3 element vector class be better as part of pygame than  
not? what
existing element of pygame is better or easier to use with a 3  
element

vector also being part of pygame?

...now a 2 element vector being part of pygame... rect could be  
better by
making use of it, it could be used as an argument to the various  
functions

that take 2 element lists, etc. etc

... and a 3 element vector (and quaternions and matrices) being  
part of

pyOpenGL, that sounds great too...



On Mon, Apr 27, 2009 at 2:59 PM, Lorenz Quack  
 wrote:


Hello,

I am interested in the inclusion of a vector and matrix types into  
pygame
as suggested here [4]. In this email I want to propose a API for a  
vector

module.

I will for brevity only present the API for the types in three  
dimensions.

The APIs for two or four dimensions should look analog.

Also I enumerated every API for easier reference in discussions.
Alternatives are denoted by lexical items (e.g. a) or b))
At the end I put together a small comparison to existing  
implementations.


This is only a suggestion to spark discussion and provoke  
feedback. So

throw
in your 2 cents.

sincerely yours
//Lorenz


PS: If this turns out to be of any value I will put something  
similar

together for matrix types and quaternions.




**
* API draft v1.0 *
**

In the following I will use the notation:
  v, v1, v2, ... are vectors
  s, s1, s2, ... are objects implementing the sequences
 protocol (list, tuple, the proposed vector)
  a, a1, a2, ... are scalars (int, float)


§ 1 Vector type


1.1 Class name and constructor
==
1.1.1  a) Vector3
  b) Vector3d
1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3  
respectivly

1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2]
respectivly
1.1.4  V()  # initialize x, y and z with zeros


1.2 numerical behavior
==
1.2.1.1  v1 + s -> v3
1.2.1.2  s + v1 -> v3
1.2.1.3  v += s
1.2.2.1  v1 - s -> v3
1.2.2.2  s - v1 -> v3
1.2.2.3  v -= s
1.2.3.1  v1 * a -> v3
1.2.3.2  a * v1 -> v3
1.2.3.3  v *= a
1.2.4.1  v1 / a -> v3
1.2.4.2  v /= a
1.2.5.1  v1 // a -> v3
1.2.5.2  v //= a
1.2.6.1  v1 % a -> v3
1.2.6.2  v %= a

1.2.7.1  v * s -> a  # dot/scalar/inner product
1.2.7.2  s * v -> a  # dot/scalar/inner product

1.2.8.1  +v1 -> v2   # returns a new vector
1.2.8.2  -v1 -> v2


1.3 sequence behavior
=
1.3.1len(v) -> 3   # fixed length
1.3.2.1  v[0] -> a # 0-based indexing
1.3.2.2  v[0] = a


1.4 attributes
==
1.4.0"x", "y", "z" (and "w" for 4th dimension)
"_epsilon" for comparis

Re: [pygame] API draft for vector type

[Casey Duncan]

On Apr 27, 2009, at 6:16 PM, René Dudfield wrote:

Would be nice if the vectors storage of things could be anything  
underneath.  This would be useful to allow them to use pygame.Rect  
or numpy.array underneath.  This means they can refer to a batch of  
vectors, but also operate only on a single vector at a time.


+1, though there are performance vs. generality tradeoffs to be made.  
On the general side, a vector class could assume the underlying  
storage supports __getitem__, but the performance of this would  
suffer, I think too greatly. On the performance side, it could just  
have a pointer to an array of floats that it wraps with the vector  
api. I used this strategy with Lepton and the performance is great,  
but it is inflexible for the storage, and probably not very practical  
for totally general use across different storages.


Wondering about why only 3 element vectors?  2,3, and 4 element ones  
are common?  Is there a way to make a combined 2,3,4 type?


Most operations can assume the higher dimensions are always zero, or  
the length could just be variable. But in either case the code would  
be slower than it would strictly need to be, since many operations  
would do more work than needed or would require loops where they would  
not be required for single purpose 2D, 3D or better vectors.


What number types are used?  eg, can you have a float vector, a long  
vector, an int vector?  Any python number?  A uint8 ?


Seems to me like the most general number type would be a double, as it  
could comfortably support a wide range, does not generally have  
resolution issues like a 32-bit float can and performs well on modern  
hardware. It would also give consistent results compared to a python  
float, which is nice.


I'm not sure what the use-case is for ints or (python) longs, the  
latter would probably gain little by being coded in C compared to pure  
python. Even in sprite-based 2D games, I find integers to be far too  
coarse for vector math, and operations like normalize become basically  
impossible.


If you support multiple vector numeric types, than you have to  
confront a combinatorial explosion of type conversions and either  
duplicate, templatize or generalize the code in such a way that you  
trade either performance or maintainability or both.


-Casey

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Hi,

lxml parses the html to an xml ElementTree structure. It is also a validating 
parser, so a restrictived DTD could be provided to reject scripts. Or the tree 
could just be searched.

Lenard

Quoting René Dudfield :
> yeah should be mostly simple...
> 
> the website also uses some stuff to filter out things like javascript.
> Hopefully there is something similar available for python now.  Does lxml
> support that?  Failing that, will have to convert one of the ones from php.
> feedparser in python is pretty good for that... however it still has some
> problems.
> 
> It's a must for user submitted website content, no matter the markup
> language.
> 
> cu,
> 
> 
> 
> 
> On Mon, Apr 27, 2009 at 7:28 AM, Lenard Lindstrom  wrote:
> 
> > Sanitising will be simple. I have tried lxml. Of course there is also
> > beautifulsoup. Another issue is maintaining consistently across pages.
> Using
> >  tags doesn't work. Remembering what header level to use when is
> > bothersome. If new, more descriptive, header tags could be added that
> would
> > be great. And a preview function.
> >
> > Lenard
> >
> > René Dudfield wrote:
> >
> >> Hi,
> >>
> >> I suggest using the current one - rewritten in python, and fixing that
> >> bug.  I think that's the only code mangling bug it has?
> >>
> >> Yeah, the code in the wiki is probably best described as non-strict
> >> html... or just html... which is not strict itself.  The wiki does some
> >> sanitising on the html after entry.  It's only a few lines of code to add
> a
> >> gui editor like tinymce... so we could add that for those who don't want
> to
> >> use markup.
> >>
> >> cheers,
> >>
> >>
> >>
> >> On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom
>  >> le...@telus.net>> wrote:
> >>
> >>Hi René,
> >>
> >>I don't know about Trac's tracking system but I find bugzilla
> >>difficult as it requires report generation. How to get a listing
> >>of recent bugs is not obvious.
> >>
> >>The html markup in the current wiki is not strict XHTML. We do
> >>want the new site to generate properly formed XHTML pages, or am I
> >>mistaken. Also Python code gets mangled, '<' replaced with '<'
> >>for  sections. This is probably a data entry problem though.
> >>But whatever wiki engine is chosen it has to handle this properly.
> >>Trac does. Do any of the html tag wikis handle it right? What
> >>alternate wiki do you suggest?
> >>
> >>Lenard
> >>
> >>
> >>
> >>René Dudfield wrote:
> >>
> >>hi,
> >>
> >>the main way we do bugs with pygame is through the mailing
> >>list.  The internet is a bug tracker.
> >>
> >>I wrote a blog post about the reasons why the mailing list is
> >>good, and what 'the internet is a bug tracker' means:
> >>http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html
> >>
> >>I personally think trac is a bit rubbish, and have been happy
> >>with James Paige hosting bugzilla for us.
> >>
> >>
> >>The current pygame wiki just uses simple html.  So should be
> >>fairly straight forward to convert... or we could just leave
> >>it in html.  Since most programmers know html anyway... way
> >>more than trac markup.
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 


-- 
Lenard Lindstrom

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

yeah should be mostly simple...

the website also uses some stuff to filter out things like javascript.
Hopefully there is something similar available for python now.  Does lxml
support that?  Failing that, will have to convert one of the ones from php.
feedparser in python is pretty good for that... however it still has some
problems.

It's a must for user submitted website content, no matter the markup
language.

cu,




On Mon, Apr 27, 2009 at 7:28 AM, Lenard Lindstrom  wrote:

> Sanitising will be simple. I have tried lxml. Of course there is also
> beautifulsoup. Another issue is maintaining consistently across pages. Using
>  tags doesn't work. Remembering what header level to use when is
> bothersome. If new, more descriptive, header tags could be added that would
> be great. And a preview function.
>
> Lenard
>
> René Dudfield wrote:
>
>> Hi,
>>
>> I suggest using the current one - rewritten in python, and fixing that
>> bug.  I think that's the only code mangling bug it has?
>>
>> Yeah, the code in the wiki is probably best described as non-strict
>> html... or just html... which is not strict itself.  The wiki does some
>> sanitising on the html after entry.  It's only a few lines of code to add a
>> gui editor like tinymce... so we could add that for those who don't want to
>> use markup.
>>
>> cheers,
>>
>>
>>
>> On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom > le...@telus.net>> wrote:
>>
>>Hi René,
>>
>>I don't know about Trac's tracking system but I find bugzilla
>>difficult as it requires report generation. How to get a listing
>>of recent bugs is not obvious.
>>
>>The html markup in the current wiki is not strict XHTML. We do
>>want the new site to generate properly formed XHTML pages, or am I
>>mistaken. Also Python code gets mangled, '<' replaced with '<'
>>for  sections. This is probably a data entry problem though.
>>But whatever wiki engine is chosen it has to handle this properly.
>>Trac does. Do any of the html tag wikis handle it right? What
>>alternate wiki do you suggest?
>>
>>Lenard
>>
>>
>>
>>René Dudfield wrote:
>>
>>hi,
>>
>>the main way we do bugs with pygame is through the mailing
>>list.  The internet is a bug tracker.
>>
>>I wrote a blog post about the reasons why the mailing list is
>>good, and what 'the internet is a bug tracker' means:
>>http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html
>>
>>I personally think trac is a bit rubbish, and have been happy
>>with James Paige hosting bugzilla for us.
>>
>>
>>The current pygame wiki just uses simple html.  So should be
>>fairly straight forward to convert... or we could just leave
>>it in html.  Since most programmers know html anyway... way
>>more than trac markup.
>>
>>
>>
>>
>>
>>
>

[pygame] pygame website source code

[René Dudfield]

hellos,

here's the pygame.org website source code...

http://rene.f0o.com/~rene/pygame.tgz
MD5 (pygame.tgz) = 1c90076a4927fed5594b36a4dc8b52e0


The database will be coming once it is cleaned up... to remove any
private/personal information... and it gets double checked by someone else
too.  Maybe a few more days for it to be ready.

Thanks to Phil for preparing the source code, and to Marcus for helping me
to check it for personal/private info.



cheers!

Re: [pygame] API draft for vector type

[Daniel Jo]

I've pretty much abandoned the idea of vector classes in Python.  I've
tested various implementations: pure python classes (with and without
__slots__), C++ exposed through Pyrex/Cython, tuples manipulated
through add/mul/div/etc functions. . .  Of these, C++ turned out to be
the fastest, but faster by far than that was simply not using any
structure at all.  Store the components in tuples for convenience, but
extract them and manipulated them individually for complex equations.
Vector classes work well for convenience and code readability, but
from a performance standpoint they aren't very useful.

On Mon, Apr 27, 2009 at 4:28 PM, Brian Fisher  wrote:
> I don't see a 3 element vector type being useful from a pygame perspective.
> What pygame api anywhere even takes 3 element lists aside from colors?
> (which already have a special struct type thing)
>
> I'm not saying 3 element vectors don't have their uses - just that the seem
> to me to be a pretty random thing to have added to pygame, which is
> exclusively 2d in every interesting respect. It seems like the sort of thing
> to add that would add much more to the maintenance and testing cost of the
> pygame library than it would bring to the users as a whole. To put another
> way, there is no synergy between a 3 element vector class and pygame. Why
> would a 3 element vector class be better as part of pygame than not? what
> existing element of pygame is better or easier to use with a 3 element
> vector also being part of pygame?
>
> ...now a 2 element vector being part of pygame... rect could be better by
> making use of it, it could be used as an argument to the various functions
> that take 2 element lists, etc. etc
>
> ... and a 3 element vector (and quaternions and matrices) being part of
> pyOpenGL, that sounds great too...
>
>
>
> On Mon, Apr 27, 2009 at 2:59 PM, Lorenz Quack  wrote:
>>
>> Hello,
>>
>> I am interested in the inclusion of a vector and matrix types into pygame
>> as suggested here [4]. In this email I want to propose a API for a vector
>> module.
>>
>> I will for brevity only present the API for the types in three dimensions.
>> The APIs for two or four dimensions should look analog.
>>
>> Also I enumerated every API for easier reference in discussions.
>> Alternatives are denoted by lexical items (e.g. a) or b))
>> At the end I put together a small comparison to existing implementations.
>>
>> This is only a suggestion to spark discussion and provoke feedback. So
>> throw
>> in your 2 cents.
>>
>> sincerely yours
>> //Lorenz
>>
>>
>> PS: If this turns out to be of any value I will put something similar
>> together for matrix types and quaternions.
>>
>>
>>
>>
>> **
>> * API draft v1.0 *
>> **
>>
>> In the following I will use the notation:
>>   v, v1, v2, ... are vectors
>>   s, s1, s2, ... are objects implementing the sequences
>>                  protocol (list, tuple, the proposed vector)
>>   a, a1, a2, ... are scalars (int, float)
>>
>>
>> § 1 Vector type
>> 
>>
>> 1.1 Class name and constructor
>> ==
>> 1.1.1  a) Vector3
>>       b) Vector3d
>> 1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3 respectivly
>> 1.1.3  V(s)         # initialize x, y and z with s[0], s[1] and s[2]
>> respectivly
>> 1.1.4  V()          # initialize x, y and z with zeros
>>
>>
>> 1.2 numerical behavior
>> ==
>> 1.2.1.1  v1 + s -> v3
>> 1.2.1.2  s + v1 -> v3
>> 1.2.1.3  v += s
>> 1.2.2.1  v1 - s -> v3
>> 1.2.2.2  s - v1 -> v3
>> 1.2.2.3  v -= s
>> 1.2.3.1  v1 * a -> v3
>> 1.2.3.2  a * v1 -> v3
>> 1.2.3.3  v *= a
>> 1.2.4.1  v1 / a -> v3
>> 1.2.4.2  v /= a
>> 1.2.5.1  v1 // a -> v3
>> 1.2.5.2  v //= a
>> 1.2.6.1  v1 % a -> v3
>> 1.2.6.2  v %= a
>>
>> 1.2.7.1  v * s -> a      # dot/scalar/inner product
>> 1.2.7.2  s * v -> a      # dot/scalar/inner product
>>
>> 1.2.8.1  +v1 -> v2       # returns a new vector
>> 1.2.8.2  -v1 -> v2
>>
>>
>> 1.3 sequence behavior
>> =
>> 1.3.1    len(v) -> 3       # fixed length
>> 1.3.2.1  v[0] -> a         # 0-based indexing
>> 1.3.2.2  v[0] = a
>>
>>
>> 1.4 attributes
>> ==
>> 1.4.0    "x", "y", "z" (and "w" for 4th dimension)
>>         "_epsilon" for comparison operations
>> 1.4.1.1  v.x -> a
>> 1.4.1.2  v.x = a
>>
>>
>> 1.5 methods
>> ===
>> 1.5.1    v.dot(s) -> a     # dot/scalar/inner product
>> 1.5.2    v.cross(s) -> v   # cross/vector product
>>         # in 2 dimensions this returns v.x * s[1] - v.y * s[0]
>>         # this is not defined in 4 dimensions
>> 1.5.3    v.outer(s) -> m   # outer product yielding a matrix
>> 1.5.4.1  v.isNormalized() -> bool
>> 1.5.4.2  v.normalize() -> None    # normalizes inplace
>> 1.5.4.3  v1.normalized() -> v2    # returns normalized vector
>> 1.5.5.1  v1.rotate(s1[, a]) -> None
>>         # rotates around s1 by angle a. if a isn't given it
>>         # rotates around s1 by the magnitude of s1
>>         # this is an inplace o

Re: [pygame] Camera module roadmap

[el lauwer]

Hoi,

I have included a timeline for the implementation of the camera module  
for osx in my gsoc application. You can take a look at that, to get an  
idea of how long it is going to take to implement.


Mzls


On 26-apr-09, at 21:53, Alexandre Quessy wrote:


Hi all,
(esp. Nirav, René and Chelsea)
I am interested in getting involved in the pygame camera module, since
I use it for my stop motion software ToonLoop I am developing with
Tristan Matthews. See http://toonloop.com : and yes, I think ToonLoop
is a great free software to test the pygame.camera module with, if you
don't installing Twisted. Creating a cross-platform application is my
main concern, and I feel like there is a lack of cross-platform C
libraries for having a live camera input. Anyways, Python is the way
to go for such a high-level software like mine. I am not so much of an
expert in C, but I can help with the software architecture.

Mac : So, the Mac version uses the OpenCV wrapper for now ? I have
read on Nirav's blog that py-objective-C wasn't well maintained enough
? Does that mean we will stick with the OpenCV camera wrapper this
summer, Chelsea ? Are there build/install instructions for Mac ? It
seems like the camera API is slightly different between Mac and
GNU/Linux. At the end of this email, I provide two code snippets which
illustrates those differences. It's when we initiate the camera, and
when copying a surface from it to a list of surfaces.

Linux : On GNU/Linux, I am having success with v4l2 inputs. What is
the state of the v4l ones ? Has it been reported to work for some
users ? Any plan to support raw1394 cameras ? (libdc1394) When is it
planned to release a .deb with pygame containing the camera module ?
What is the state of your computer vision tools for Pygame, Nirav ?

Windows : What is the state of the camera module on Windows ? The
vidcap module was reported to be working, (Feb 2009) but will it be
officially part of pygame, or should it be using an other tool/driver
?

Any chances I can make py2app and py2exe applications with
pygame.camera support before the end of the summer ?

Thank you !!
--
 Differences between the pygame.camera in Mac v/s GNU/Linux
--
### Initiating the camera ##
video_device_num = 0
size = (320, 240)
if self.IS_MAC:
   print "Using camera %s" % (video_device_num)
   self.camera = pygame.camera.Camera(video_device_num, size)
else:
   print "Using camera /dev/video%d" % (video_device_num)
   self.camera = pygame.camera.Camera("/dev/video%d" %
(video_device_num), size)
### Grabbing an image ###
if self.IS_MAC:
   self.shot.images.append(self.most_recent_image.copy())
else:
   self.shot.images.append(self.most_recent_image)

--
Alexandre Quessy
http://alexandre.quessy.net/

Re: [pygame] API draft for vector type

[René Dudfield]

very good work.

+1 to the pep8 naming like someone else mentioned.

Would be nice if the vectors storage of things could be anything
underneath.  This would be useful to allow them to use pygame.Rect or
numpy.array underneath.  This means they can refer to a batch of vectors,
but also operate only on a single vector at a time.

Wondering about why only 3 element vectors?  2,3, and 4 element ones are
common?  Is there a way to make a combined 2,3,4 type?

What number types are used?  eg, can you have a float vector, a long vector,
an int vector?  Any python number?  A uint8 ?

cu,




On Tue, Apr 28, 2009 at 7:59 AM, Lorenz Quack  wrote:

> Hello,
>
> I am interested in the inclusion of a vector and matrix types into pygame
> as suggested here [4]. In this email I want to propose a API for a vector
> module.
>
> I will for brevity only present the API for the types in three dimensions.
> The APIs for two or four dimensions should look analog.
>
> Also I enumerated every API for easier reference in discussions.
> Alternatives are denoted by lexical items (e.g. a) or b))
> At the end I put together a small comparison to existing implementations.
>
> This is only a suggestion to spark discussion and provoke feedback. So
> throw
> in your 2 cents.
>
> sincerely yours
> //Lorenz
>
>
> PS: If this turns out to be of any value I will put something similar
> together for matrix types and quaternions.
>
>
>
>
> **
> * API draft v1.0 *
> **
>
> In the following I will use the notation:
>   v, v1, v2, ... are vectors
>   s, s1, s2, ... are objects implementing the sequences
>  protocol (list, tuple, the proposed vector)
>   a, a1, a2, ... are scalars (int, float)
>
>
> § 1 Vector type
> 
>
> 1.1 Class name and constructor
> ==
> 1.1.1  a) Vector3
>   b) Vector3d
> 1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3 respectivly
> 1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2]
> respectivly
> 1.1.4  V()  # initialize x, y and z with zeros
>
>
> 1.2 numerical behavior
> ==
> 1.2.1.1  v1 + s -> v3
> 1.2.1.2  s + v1 -> v3
> 1.2.1.3  v += s
> 1.2.2.1  v1 - s -> v3
> 1.2.2.2  s - v1 -> v3
> 1.2.2.3  v -= s
> 1.2.3.1  v1 * a -> v3
> 1.2.3.2  a * v1 -> v3
> 1.2.3.3  v *= a
> 1.2.4.1  v1 / a -> v3
> 1.2.4.2  v /= a
> 1.2.5.1  v1 // a -> v3
> 1.2.5.2  v //= a
> 1.2.6.1  v1 % a -> v3
> 1.2.6.2  v %= a
>
> 1.2.7.1  v * s -> a  # dot/scalar/inner product
> 1.2.7.2  s * v -> a  # dot/scalar/inner product
>
> 1.2.8.1  +v1 -> v2   # returns a new vector
> 1.2.8.2  -v1 -> v2
>
>
> 1.3 sequence behavior
> =
> 1.3.1len(v) -> 3   # fixed length
> 1.3.2.1  v[0] -> a # 0-based indexing
> 1.3.2.2  v[0] = a
>
>
> 1.4 attributes
> ==
> 1.4.0"x", "y", "z" (and "w" for 4th dimension)
> "_epsilon" for comparison operations
> 1.4.1.1  v.x -> a
> 1.4.1.2  v.x = a
>
>
> 1.5 methods
> ===
> 1.5.1v.dot(s) -> a # dot/scalar/inner product
> 1.5.2v.cross(s) -> v   # cross/vector product
> # in 2 dimensions this returns v.x * s[1] - v.y * s[0]
> # this is not defined in 4 dimensions
> 1.5.3v.outer(s) -> m   # outer product yielding a matrix
> 1.5.4.1  v.isNormalized() -> bool
> 1.5.4.2  v.normalize() -> None# normalizes inplace
> 1.5.4.3  v1.normalized() -> v2# returns normalized vector
> 1.5.5.1  v1.rotate(s1[, a]) -> None
> # rotates around s1 by angle a. if a isn't given it
> # rotates around s1 by the magnitude of s1
> # this is an inplace operation
> 1.5.5.2  v1.rotated(s1[, a]) -> v2
> # same as 1.5.6 but returns a new vector and leaves v1 untouched
> 1.5.6.1  v1.rotateX(a) -> None
> # rotates v1 around the x-axis by the angle a
> 1.5.6.2  v1.rotatedX(a) -> v2
> # same as 1.5.6.1 but returns a new vector and leaves v1 untouched
> 1.5.6.3  # implement 1.5.6.1 and 2 also for Y and Z
> 1.5.7v1.reflect(s) -> v2
> # reflects the vector of a surface with surface normal s
> 1.5.8a) v1.interpolate(s, a) -> generator of vectors
> b) v1.slerp(s, a) -> generator of vectors
> # the distance between "v1" and "s" divided in "a" steps
> 1.5.9v.getAngleTo(s) -> a
> # returns the angle between v and s
> 1.5.10.1 v.getDistanceTo(s) -> a
> # returns the distance between v and s
> 1.5.10.2 v.getDistance2To(s) -> a
> # returns the squared distance between v and s
>
>
> 1.6 properties
> ==
> 1.6.1.1  v.length -> a # gets the magnitude/length of the vector
> 1.6.1.2  v.length = a
> # sets the length of the vector while preserving its direction
> 1.6.2.1  a) v.lengthSquared -> a
> b) v.length2 -> a
> # gets the squared length of the vector. same as v.dot(v) or v * v
> 1.6.2.1  a) v.lengthSquared = a
> b) v.length2 = a
> # sets the squared leng

Re: [pygame] API draft for vector type

[Casey Duncan]

On Apr 27, 2009, at 4:28 PM, Brian Fisher wrote:

I don't see a 3 element vector type being useful from a pygame  
perspective. What pygame api anywhere even takes 3 element lists  
aside from colors? (which already have a special struct type thing)


I'd have to disagree with this myself, since pygame+pyOpenGL is a  
fairly popular combo, it seems like omitting 3d vectors on the grounds  
that most pygames are 2D is too minimalist. OTOH, I don't think it  
needs 4D vectors. 1D vectors, however, would be awesome ;^)


... and a 3 element vector (and quaternions and matrices) being part  
of pyOpenGL, that sounds great too...


I could be wrong, but I don't think pyOpenGL strives to provide such  
tools, which are not strictly part of the OpenGL api. Whereas pygame  
does try to provide such lower-level abstractions.


Of course you could make a slippery slope argument here, where there  
is soon demand for more 3D tools given 3D vectors, like rectangular  
prisms, etc.


-Casey

Re: [pygame] API draft for vector type

[Casey Duncan]

Any reason to not follow the pep-8 naming convention for methods, i.e.:

v.get_distance_to()

instead of:

v.getDistanceTo()

or maybe even (the get seems a little superfluous):

v.distanceto()

Other pygame modules seem to use the pep-8 convention, would be a  
shame to break the nice consistency.


-Casey

On Apr 27, 2009, at 3:59 PM, Lorenz Quack wrote:


Hello,

I am interested in the inclusion of a vector and matrix types into  
pygame
as suggested here [4]. In this email I want to propose a API for a  
vector module.


I will for brevity only present the API for the types in three  
dimensions.

The APIs for two or four dimensions should look analog.

Also I enumerated every API for easier reference in discussions.
Alternatives are denoted by lexical items (e.g. a) or b))
At the end I put together a small comparison to existing  
implementations.


This is only a suggestion to spark discussion and provoke feedback.  
So throw

in your 2 cents.

sincerely yours
//Lorenz


PS: If this turns out to be of any value I will put something  
similar together for matrix types and quaternions.





**
* API draft v1.0 *
**

In the following I will use the notation:
  v, v1, v2, ... are vectors
  s, s1, s2, ... are objects implementing the sequences
 protocol (list, tuple, the proposed vector)
  a, a1, a2, ... are scalars (int, float)


§ 1 Vector type


1.1 Class name and constructor
==
1.1.1  a) Vector3
  b) Vector3d
1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3  
respectivly
1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2]  
respectivly

1.1.4  V()  # initialize x, y and z with zeros


1.2 numerical behavior
==
1.2.1.1  v1 + s -> v3
1.2.1.2  s + v1 -> v3
1.2.1.3  v += s
1.2.2.1  v1 - s -> v3
1.2.2.2  s - v1 -> v3
1.2.2.3  v -= s
1.2.3.1  v1 * a -> v3
1.2.3.2  a * v1 -> v3
1.2.3.3  v *= a
1.2.4.1  v1 / a -> v3
1.2.4.2  v /= a
1.2.5.1  v1 // a -> v3
1.2.5.2  v //= a
1.2.6.1  v1 % a -> v3
1.2.6.2  v %= a

1.2.7.1  v * s -> a  # dot/scalar/inner product
1.2.7.2  s * v -> a  # dot/scalar/inner product

1.2.8.1  +v1 -> v2   # returns a new vector
1.2.8.2  -v1 -> v2


1.3 sequence behavior
=
1.3.1len(v) -> 3   # fixed length
1.3.2.1  v[0] -> a # 0-based indexing
1.3.2.2  v[0] = a


1.4 attributes
==
1.4.0"x", "y", "z" (and "w" for 4th dimension)
"_epsilon" for comparison operations
1.4.1.1  v.x -> a
1.4.1.2  v.x = a


1.5 methods
===
1.5.1v.dot(s) -> a # dot/scalar/inner product
1.5.2v.cross(s) -> v   # cross/vector product
# in 2 dimensions this returns v.x * s[1] - v.y * s[0]
# this is not defined in 4 dimensions
1.5.3v.outer(s) -> m   # outer product yielding a matrix
1.5.4.1  v.isNormalized() -> bool
1.5.4.2  v.normalize() -> None# normalizes inplace
1.5.4.3  v1.normalized() -> v2# returns normalized vector
1.5.5.1  v1.rotate(s1[, a]) -> None
# rotates around s1 by angle a. if a isn't given it
# rotates around s1 by the magnitude of s1
# this is an inplace operation
1.5.5.2  v1.rotated(s1[, a]) -> v2
# same as 1.5.6 but returns a new vector and leaves v1  
untouched

1.5.6.1  v1.rotateX(a) -> None
# rotates v1 around the x-axis by the angle a
1.5.6.2  v1.rotatedX(a) -> v2
# same as 1.5.6.1 but returns a new vector and leaves v1  
untouched

1.5.6.3  # implement 1.5.6.1 and 2 also for Y and Z
1.5.7v1.reflect(s) -> v2
# reflects the vector of a surface with surface normal s
1.5.8a) v1.interpolate(s, a) -> generator of vectors
b) v1.slerp(s, a) -> generator of vectors
# the distance between "v1" and "s" divided in "a" steps
1.5.9v.getAngleTo(s) -> a
# returns the angle between v and s
1.5.10.1 v.getDistanceTo(s) -> a
# returns the distance between v and s
1.5.10.2 v.getDistance2To(s) -> a
# returns the squared distance between v and s


1.6 properties
==
1.6.1.1  v.length -> a # gets the magnitude/length of the vector
1.6.1.2  v.length = a
# sets the length of the vector while preserving its direction
1.6.2.1  a) v.lengthSquared -> a
b) v.length2 -> a
# gets the squared length of the vector. same as v.dot(v) or  
v * v

1.6.2.1  a) v.lengthSquared = a
b) v.length2 = a
# sets the squared length of the vector. preserving its  
direction

# the following only have meaning in 3 dimensions
1.6.3.1  v.r -> a  # returns the "r" coordiante of sherical  
coordinates

  # this is the same as the "length" property
1.6.3.2  v.r = a
1.6.4.1  v.phi -> a # returns the "phi" coordiante of spherical  
coordiantes

1.6.4.2  v.phi = a
1.6.5.1  v.theta -> a # returns the "theta" coordiante of spherical  
coordiantes

1.6.5.2  v.theta = a


1.7 comparison operations
===

Re: [pygame] API draft for vector type

[Brian Fisher]

One aspect of vector class design that I've become more and more a fan of
over time is vector immutability.

So you can't say stuff like:
   vector.x += 2
   vector.x = 5

but instead would have to say stuff like:
   vector += (2, 0)
   vector = vector2d(5, vector.y)

their are a couple reasons to design them that way - first is no one can
ever change your attributes underneath you - which is a bug I've run into
every now and then with mutable vectors, and have had to work around by
having stuff contruct and return new vectors instead of returning the
internal one.

what I mean is code like this is pretty bad (but moderately easy to write)
---
  class Angel(object)
def __init__(self, offset):
  self.offset = offset

  t = new Angel()
  halo_pos = t.offset
  halo_pos.y -= 5
  DrawHalo(halo_pos)
-
and immutability of vectors makes that bug impossible.

the second reason for immutability of vectors is that they can because keys
in dicts (something I've found useful, but have had to use 2 element tuples
instead to make it work)


On Mon, Apr 27, 2009 at 2:59 PM, Lorenz Quack  wrote:

> Hello,
>
> I am interested in the inclusion of a vector and matrix types into pygame
> as suggested here [4]. In this email I want to propose a API for a vector
> module.
>
> I will for brevity only present the API for the types in three dimensions.
> The APIs for two or four dimensions should look analog.
>
> Also I enumerated every API for easier reference in discussions.
> Alternatives are denoted by lexical items (e.g. a) or b))
> At the end I put together a small comparison to existing implementations.
>
> This is only a suggestion to spark discussion and provoke feedback. So
> throw
> in your 2 cents.
>
> sincerely yours
> //Lorenz
>
>
> PS: If this turns out to be of any value I will put something similar
> together for matrix types and quaternions.
>
>
>
>
> **
> * API draft v1.0 *
> **
>
> In the following I will use the notation:
>   v, v1, v2, ... are vectors
>   s, s1, s2, ... are objects implementing the sequences
>  protocol (list, tuple, the proposed vector)
>   a, a1, a2, ... are scalars (int, float)
>
>
> § 1 Vector type
> 
>
> 1.1 Class name and constructor
> ==
> 1.1.1  a) Vector3
>   b) Vector3d
> 1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3 respectivly
> 1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2]
> respectivly
> 1.1.4  V()  # initialize x, y and z with zeros
>
>
> 1.2 numerical behavior
> ==
> 1.2.1.1  v1 + s -> v3
> 1.2.1.2  s + v1 -> v3
> 1.2.1.3  v += s
> 1.2.2.1  v1 - s -> v3
> 1.2.2.2  s - v1 -> v3
> 1.2.2.3  v -= s
> 1.2.3.1  v1 * a -> v3
> 1.2.3.2  a * v1 -> v3
> 1.2.3.3  v *= a
> 1.2.4.1  v1 / a -> v3
> 1.2.4.2  v /= a
> 1.2.5.1  v1 // a -> v3
> 1.2.5.2  v //= a
> 1.2.6.1  v1 % a -> v3
> 1.2.6.2  v %= a
>
> 1.2.7.1  v * s -> a  # dot/scalar/inner product
> 1.2.7.2  s * v -> a  # dot/scalar/inner product
>
> 1.2.8.1  +v1 -> v2   # returns a new vector
> 1.2.8.2  -v1 -> v2
>
>
> 1.3 sequence behavior
> =
> 1.3.1len(v) -> 3   # fixed length
> 1.3.2.1  v[0] -> a # 0-based indexing
> 1.3.2.2  v[0] = a
>
>
> 1.4 attributes
> ==
> 1.4.0"x", "y", "z" (and "w" for 4th dimension)
> "_epsilon" for comparison operations
> 1.4.1.1  v.x -> a
> 1.4.1.2  v.x = a
>
>
> 1.5 methods
> ===
> 1.5.1v.dot(s) -> a # dot/scalar/inner product
> 1.5.2v.cross(s) -> v   # cross/vector product
> # in 2 dimensions this returns v.x * s[1] - v.y * s[0]
> # this is not defined in 4 dimensions
> 1.5.3v.outer(s) -> m   # outer product yielding a matrix
> 1.5.4.1  v.isNormalized() -> bool
> 1.5.4.2  v.normalize() -> None# normalizes inplace
> 1.5.4.3  v1.normalized() -> v2# returns normalized vector
> 1.5.5.1  v1.rotate(s1[, a]) -> None
> # rotates around s1 by angle a. if a isn't given it
> # rotates around s1 by the magnitude of s1
> # this is an inplace operation
> 1.5.5.2  v1.rotated(s1[, a]) -> v2
> # same as 1.5.6 but returns a new vector and leaves v1 untouched
> 1.5.6.1  v1.rotateX(a) -> None
> # rotates v1 around the x-axis by the angle a
> 1.5.6.2  v1.rotatedX(a) -> v2
> # same as 1.5.6.1 but returns a new vector and leaves v1 untouched
> 1.5.6.3  # implement 1.5.6.1 and 2 also for Y and Z
> 1.5.7v1.reflect(s) -> v2
> # reflects the vector of a surface with surface normal s
> 1.5.8a) v1.interpolate(s, a) -> generator of vectors
> b) v1.slerp(s, a) -> generator of vectors
> # the distance between "v1" and "s" divided in "a" steps
> 1.5.9v.getAngleTo(s) -> a
> # returns the angle between v and s
> 1.5.10.1 v.getDistanceTo(s) -> a
> # returns the distance between v and s
> 1.5.10.2 v.getDistance2To(s) -> a
> # returns the

Re: [pygame] API draft for vector type

[Brian Fisher]

I don't see a 3 element vector type being useful from a pygame perspective.
What pygame api anywhere even takes 3 element lists aside from colors?
(which already have a special struct type thing)

I'm not saying 3 element vectors don't have their uses - just that the seem
to me to be a pretty random thing to have added to pygame, which is
exclusively 2d in every interesting respect. It seems like the sort of thing
to add that would add much more to the maintenance and testing cost of the
pygame library than it would bring to the users as a whole. To put another
way, there is no synergy between a 3 element vector class and pygame. Why
would a 3 element vector class be better as part of pygame than not? what
existing element of pygame is better or easier to use with a 3 element
vector also being part of pygame?

...now a 2 element vector being part of pygame... rect could be better by
making use of it, it could be used as an argument to the various functions
that take 2 element lists, etc. etc

... and a 3 element vector (and quaternions and matrices) being part of
pyOpenGL, that sounds great too...



On Mon, Apr 27, 2009 at 2:59 PM, Lorenz Quack  wrote:

> Hello,
>
> I am interested in the inclusion of a vector and matrix types into pygame
> as suggested here [4]. In this email I want to propose a API for a vector
> module.
>
> I will for brevity only present the API for the types in three dimensions.
> The APIs for two or four dimensions should look analog.
>
> Also I enumerated every API for easier reference in discussions.
> Alternatives are denoted by lexical items (e.g. a) or b))
> At the end I put together a small comparison to existing implementations.
>
> This is only a suggestion to spark discussion and provoke feedback. So
> throw
> in your 2 cents.
>
> sincerely yours
> //Lorenz
>
>
> PS: If this turns out to be of any value I will put something similar
> together for matrix types and quaternions.
>
>
>
>
> **
> * API draft v1.0 *
> **
>
> In the following I will use the notation:
>   v, v1, v2, ... are vectors
>   s, s1, s2, ... are objects implementing the sequences
>  protocol (list, tuple, the proposed vector)
>   a, a1, a2, ... are scalars (int, float)
>
>
> § 1 Vector type
> 
>
> 1.1 Class name and constructor
> ==
> 1.1.1  a) Vector3
>   b) Vector3d
> 1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3 respectivly
> 1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2]
> respectivly
> 1.1.4  V()  # initialize x, y and z with zeros
>
>
> 1.2 numerical behavior
> ==
> 1.2.1.1  v1 + s -> v3
> 1.2.1.2  s + v1 -> v3
> 1.2.1.3  v += s
> 1.2.2.1  v1 - s -> v3
> 1.2.2.2  s - v1 -> v3
> 1.2.2.3  v -= s
> 1.2.3.1  v1 * a -> v3
> 1.2.3.2  a * v1 -> v3
> 1.2.3.3  v *= a
> 1.2.4.1  v1 / a -> v3
> 1.2.4.2  v /= a
> 1.2.5.1  v1 // a -> v3
> 1.2.5.2  v //= a
> 1.2.6.1  v1 % a -> v3
> 1.2.6.2  v %= a
>
> 1.2.7.1  v * s -> a  # dot/scalar/inner product
> 1.2.7.2  s * v -> a  # dot/scalar/inner product
>
> 1.2.8.1  +v1 -> v2   # returns a new vector
> 1.2.8.2  -v1 -> v2
>
>
> 1.3 sequence behavior
> =
> 1.3.1len(v) -> 3   # fixed length
> 1.3.2.1  v[0] -> a # 0-based indexing
> 1.3.2.2  v[0] = a
>
>
> 1.4 attributes
> ==
> 1.4.0"x", "y", "z" (and "w" for 4th dimension)
> "_epsilon" for comparison operations
> 1.4.1.1  v.x -> a
> 1.4.1.2  v.x = a
>
>
> 1.5 methods
> ===
> 1.5.1v.dot(s) -> a # dot/scalar/inner product
> 1.5.2v.cross(s) -> v   # cross/vector product
> # in 2 dimensions this returns v.x * s[1] - v.y * s[0]
> # this is not defined in 4 dimensions
> 1.5.3v.outer(s) -> m   # outer product yielding a matrix
> 1.5.4.1  v.isNormalized() -> bool
> 1.5.4.2  v.normalize() -> None# normalizes inplace
> 1.5.4.3  v1.normalized() -> v2# returns normalized vector
> 1.5.5.1  v1.rotate(s1[, a]) -> None
> # rotates around s1 by angle a. if a isn't given it
> # rotates around s1 by the magnitude of s1
> # this is an inplace operation
> 1.5.5.2  v1.rotated(s1[, a]) -> v2
> # same as 1.5.6 but returns a new vector and leaves v1 untouched
> 1.5.6.1  v1.rotateX(a) -> None
> # rotates v1 around the x-axis by the angle a
> 1.5.6.2  v1.rotatedX(a) -> v2
> # same as 1.5.6.1 but returns a new vector and leaves v1 untouched
> 1.5.6.3  # implement 1.5.6.1 and 2 also for Y and Z
> 1.5.7v1.reflect(s) -> v2
> # reflects the vector of a surface with surface normal s
> 1.5.8a) v1.interpolate(s, a) -> generator of vectors
> b) v1.slerp(s, a) -> generator of vectors
> # the distance between "v1" and "s" divided in "a" steps
> 1.5.9v.getAngleTo(s) -> a
> # returns the angle between v and s
> 1.5.10.1 v.getDistanceTo(s) -> a
> # returns the distance between v and s

[pygame] API draft for vector type

[Lorenz Quack]

Hello,

I am interested in the inclusion of a vector and matrix types into pygame
as suggested here [4]. In this email I want to propose a API for a vector 
module.

I will for brevity only present the API for the types in three dimensions.
The APIs for two or four dimensions should look analog.

Also I enumerated every API for easier reference in discussions.
Alternatives are denoted by lexical items (e.g. a) or b))
At the end I put together a small comparison to existing implementations.

This is only a suggestion to spark discussion and provoke feedback. So throw
in your 2 cents.

sincerely yours
//Lorenz


PS: If this turns out to be of any value I will put something similar together 
for matrix types and quaternions.





**
* API draft v1.0 *
**

In the following I will use the notation:
   v, v1, v2, ... are vectors
   s, s1, s2, ... are objects implementing the sequences
  protocol (list, tuple, the proposed vector)
   a, a1, a2, ... are scalars (int, float)


§ 1 Vector type


1.1 Class name and constructor
==
1.1.1  a) Vector3
   b) Vector3d
1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3 respectivly
1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2] respectivly
1.1.4  V()  # initialize x, y and z with zeros


1.2 numerical behavior
==
1.2.1.1  v1 + s -> v3
1.2.1.2  s + v1 -> v3
1.2.1.3  v += s
1.2.2.1  v1 - s -> v3
1.2.2.2  s - v1 -> v3
1.2.2.3  v -= s
1.2.3.1  v1 * a -> v3
1.2.3.2  a * v1 -> v3
1.2.3.3  v *= a
1.2.4.1  v1 / a -> v3
1.2.4.2  v /= a
1.2.5.1  v1 // a -> v3
1.2.5.2  v //= a
1.2.6.1  v1 % a -> v3
1.2.6.2  v %= a

1.2.7.1  v * s -> a  # dot/scalar/inner product
1.2.7.2  s * v -> a  # dot/scalar/inner product

1.2.8.1  +v1 -> v2   # returns a new vector
1.2.8.2  -v1 -> v2


1.3 sequence behavior
=
1.3.1len(v) -> 3   # fixed length
1.3.2.1  v[0] -> a # 0-based indexing
1.3.2.2  v[0] = a


1.4 attributes
==
1.4.0"x", "y", "z" (and "w" for 4th dimension)
 "_epsilon" for comparison operations
1.4.1.1  v.x -> a
1.4.1.2  v.x = a


1.5 methods
===
1.5.1v.dot(s) -> a # dot/scalar/inner product
1.5.2v.cross(s) -> v   # cross/vector product
 # in 2 dimensions this returns v.x * s[1] - v.y * s[0]
 # this is not defined in 4 dimensions
1.5.3v.outer(s) -> m   # outer product yielding a matrix
1.5.4.1  v.isNormalized() -> bool
1.5.4.2  v.normalize() -> None# normalizes inplace
1.5.4.3  v1.normalized() -> v2# returns normalized vector
1.5.5.1  v1.rotate(s1[, a]) -> None
 # rotates around s1 by angle a. if a isn't given it
 # rotates around s1 by the magnitude of s1
 # this is an inplace operation
1.5.5.2  v1.rotated(s1[, a]) -> v2
 # same as 1.5.6 but returns a new vector and leaves v1 untouched
1.5.6.1  v1.rotateX(a) -> None
 # rotates v1 around the x-axis by the angle a
1.5.6.2  v1.rotatedX(a) -> v2
 # same as 1.5.6.1 but returns a new vector and leaves v1 untouched
1.5.6.3  # implement 1.5.6.1 and 2 also for Y and Z
1.5.7v1.reflect(s) -> v2
 # reflects the vector of a surface with surface normal s
1.5.8a) v1.interpolate(s, a) -> generator of vectors
 b) v1.slerp(s, a) -> generator of vectors
 # the distance between "v1" and "s" divided in "a" steps
1.5.9v.getAngleTo(s) -> a
 # returns the angle between v and s
1.5.10.1 v.getDistanceTo(s) -> a
 # returns the distance between v and s
1.5.10.2 v.getDistance2To(s) -> a
 # returns the squared distance between v and s


1.6 properties
==
1.6.1.1  v.length -> a # gets the magnitude/length of the vector
1.6.1.2  v.length = a
 # sets the length of the vector while preserving its direction
1.6.2.1  a) v.lengthSquared -> a
 b) v.length2 -> a
 # gets the squared length of the vector. same as v.dot(v) or v * v
1.6.2.1  a) v.lengthSquared = a
 b) v.length2 = a
 # sets the squared length of the vector. preserving its direction
# the following only have meaning in 3 dimensions
1.6.3.1  v.r -> a  # returns the "r" coordiante of sherical coordinates
   # this is the same as the "length" property
1.6.3.2  v.r = a
1.6.4.1  v.phi -> a # returns the "phi" coordiante of spherical coordiantes
1.6.4.2  v.phi = a
1.6.5.1  v.theta -> a # returns the "theta" coordiante of spherical coordiantes
1.6.5.2  v.theta = a


1.7 comparison operations
=
1.7.0the "==" and "!=" and "bool" operater compare the differences against
 the attribute v._epsilon. this way the user can adjust the accuracy.
1.7.1.1  v == s -> bool
 # true if all component differ at most by v._epsilon
1.7.1.2  s == v -> bool
1.7.2.1  v != s -> bool
 # true unless all component differ at most by v._epsilon
1.7.2.2  s 

Re: [pygame] Movie module information

[Lenard Lindstrom]

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

Re: [pygame] Movie module information

[Tyler Laing]

Thank you all whom have posted. Very useful information. Brian, I can only
support whatever formats ffmpeg supports. My project is not to add support
myself for formats, but just to wrap ffmpeg. The version of ffmpeg on my
computer has some issues with Theora encoded videos, which isn't much beyond
an anecdote.

But I will definitely do my best to provide everything you guys have asked
for.

What kind of construct would be best for letting the programmer know the
video has finished playing? A callback, an event on the event queue?

-Tyler

On Mon, Apr 27, 2009 at 9:35 AM, Brian Fisher wrote:

> On Mon, Apr 27, 2009 at 1:42 AM, Marcus von Appen wrote:
>
>> On, Sun Apr 26, 2009, Tyler Laing wrote:
>> > One of the first steps I need to take for the GSoC project is to get
>> user
>> > stories so I can build acceptance tests.
>> >
>>
> Well the conventional and simple story would be simply playing movies as
> part of a game. Specifically playing a logo movie before a game or while it
> loads (like say the xbox logo when it boots, or thq thing for movies, or
> whatever animated little game logo the developer made), meaning the api
> would let the programmer kick of playing of a movie, and know when it's
> done, and I think that's an absolute minimum. The other common conventional
> thing is cut scenes - so inbetween levels of a game playing a movie. Same
> fundamental requirements as above, but also In this case, it's highly
> desirable to have the transition in and out of the movie be as seamless as
> possible - specifically popping up additional windows and changing screen
> resolution is much much worse than it playing in the same window without
> changing resolutions - also for openGL using games, it's very important that
> the end result on stuff in video memory is predictable and well known for a
> particular set of code - on windows for instance, resolution swaps usually
> wipe your textures - meaning the video module should not decide to change
> resolutions based on local conditions, but if it does, it ought to let the
> programmer know somehow if it did so.
>
>
>
>
>
>
> > 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?
>
> Here's my wish list:
>>
>>  * format support (avi, mpeg, etc...)
>>  * seperate stream manipulation and handling, if possible
>>   - mute, play, stop, rewind for audio and video streams
>> within the main stream of the video file.
>>  * simple(!) video handling
>>
>> stories and acceptance tests sounds like extreme programming terms, and in
> the spirit of extreme programming, I think that list wish list would get
> changed quite a lot. (in particular, who's the customer, and what features
> would actually get used by that customer)
>
> format support is great of course - but which ones are important? AVI is a
> bitch to support because it's just a container for any crazy stream
> encoding. I would think that a better way to define format support would be
> to say what particular program's outputs should be supported (i.e. what
> formats is the customer going to get their content actually created in).
> Given the open-source focus of pygame and such, I imagine supporting the
> most popular output formats of Blender would be great (I don't know what
> they). Supporting the latest Theora encoded files would also be a good thing
> (it's what I'd want to use)
>
> For separate streams, I can see selectively picking streams and having
> streams well synchronized as useful things for games, but rewind seems like
> not something a game would ever actually want to do. Seek to a specific
> point in the video however, would be something that could be quite useful.
>
> So what's simple video handling? How would whatever that is be used in a
> game, sepcifically.
>



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

Re: [pygame] Movie module information

[Brian Fisher]

On Mon, Apr 27, 2009 at 1:42 AM, Marcus von Appen  wrote:

> On, Sun Apr 26, 2009, Tyler Laing wrote:
> > One of the first steps I need to take for the GSoC project is to get user
> > stories so I can build acceptance tests.
> >
>
Well the conventional and simple story would be simply playing movies as
part of a game. Specifically playing a logo movie before a game or while it
loads (like say the xbox logo when it boots, or thq thing for movies, or
whatever animated little game logo the developer made), meaning the api
would let the programmer kick of playing of a movie, and know when it's
done, and I think that's an absolute minimum. The other common conventional
thing is cut scenes - so inbetween levels of a game playing a movie. Same
fundamental requirements as above, but also In this case, it's highly
desirable to have the transition in and out of the movie be as seamless as
possible - specifically popping up additional windows and changing screen
resolution is much much worse than it playing in the same window without
changing resolutions - also for openGL using games, it's very important that
the end result on stuff in video memory is predictable and well known for a
particular set of code - on windows for instance, resolution swaps usually
wipe your textures - meaning the video module should not decide to change
resolutions based on local conditions, but if it does, it ought to let the
programmer know somehow if it did so.






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

Here's my wish list:
>
>  * format support (avi, mpeg, etc...)
>  * seperate stream manipulation and handling, if possible
>   - mute, play, stop, rewind for audio and video streams
> within the main stream of the video file.
>  * simple(!) video handling
>
> stories and acceptance tests sounds like extreme programming terms, and in
the spirit of extreme programming, I think that list wish list would get
changed quite a lot. (in particular, who's the customer, and what features
would actually get used by that customer)

format support is great of course - but which ones are important? AVI is a
bitch to support because it's just a container for any crazy stream
encoding. I would think that a better way to define format support would be
to say what particular program's outputs should be supported (i.e. what
formats is the customer going to get their content actually created in).
Given the open-source focus of pygame and such, I imagine supporting the
most popular output formats of Blender would be great (I don't know what
they). Supporting the latest Theora encoded files would also be a good thing
(it's what I'd want to use)

For separate streams, I can see selectively picking streams and having
streams well synchronized as useful things for games, but rewind seems like
not something a game would ever actually want to do. Seek to a specific
point in the video however, would be something that could be quite useful.

So what's simple video handling? How would whatever that is be used in a
game, sepcifically.

Re: [pygame] Python 3.0 and Pygame Reloaded questions

[Marcus von Appen]

On, Mon Apr 27, 2009, dan...@dungeon-games.com wrote:

> 
> > You can check out the pgreloaded SVN branch using 
> > 
> >     svn co
> > svn://seul.org/svn/pygame/branches/pgreloaded
> 
> 
> Thanks, but that's the same URL I got from the Pygame site.  Which I already 
> said isn't working for me.

It is perfectly working fine, if you are using an SVN client, not a web
browser. If you just want to look around within SVN,

http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/?root=PyGame 

would be the best to use.

Regards
Marcus


pgp6R67yjZvbF.pgp
Description: PGP signature

Re: [pygame] Python 3.0 and Pygame Reloaded questions

[daniel]

> You can check out the pgreloaded SVN branch using 
> 
>     svn co
> svn://seul.org/svn/pygame/branches/pgreloaded


Thanks, but that's the same URL I got from the Pygame site.  Which I already 
said isn't working for me.

Although, more rooting around just turned up this: 
http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/?rev=2043&root=PyGame

I assume that's another copy of what I'm looking for.  I'm providing the URL 
here in case anyone else has as hard a time finding it as I did.

Re: [pygame] Python 3.0 and Pygame Reloaded questions

[Marcus von Appen]

On, Mon Apr 27, 2009, Daniel McNeese wrote:

> 
> Okay, one more question: where can I find it?  Plugging in the URL given at 
> the Pygame site isn't working, and I can't reach it via Google either.  Can 
> someone provide me with a direct link, or tell me what I'm doing wrong here?

pgreloaded is currently only available via SVN. I'm working on making an
early alpha release available, but this will take some more days.

You can check out the pgreloaded SVN branch using 

svn co svn://seul.org/svn/pygame/branches/pgreloaded

Regards
Marcus


pgpG1UiRlweF9.pgp
Description: PGP signature

Re: [pygame] Python 3.0 and Pygame Reloaded questions

[Daniel McNeese]

Okay, one more question: where can I find it?  Plugging in the URL given at the 
Pygame site isn't working, and I can't reach it via Google either.  Can someone 
provide me with a direct link, or tell me what I'm doing wrong here?

Re: [pygame] Movie module information

[Marcus von Appen]

On, Sun Apr 26, 2009, 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?

Here's my wish list:

 * format support (avi, mpeg, etc...)
 * seperate stream manipulation and handling, if possible
   - mute, play, stop, rewind for audio and video streams
 within the main stream of the video file.
 * simple(!) video handling

How might that look like? 

  # Create a new movie instance.
  video = pygame.movie.Video ("video.avi")

  # Bind the surface on which the video stream will be rendered.
  video.surface = outputsurface

  # Bind a handler for updates of the video output surface, so we can
  # handle changed frames and update anything accordingly.
  # 
  # This is optional for specialised/optimised update loops.
  video.cb_update = update_callback

  # Start async. playback of the video.
  video.play ()

  # Stop/pause/... playback
  video.stop()
  video.pause()
  video.rewind(time_pos)

  # Play only a seperate stream, e.g. one of the audio streams of the video.
  video.streams[streamid].play()
  
  # This heavily depends on the video (P/I-Frames, etc.):
  raw_buffer = video.get_frame (streamid, time_pos)
  raw_buffer = video.streams[streamid].get_frame (time_pos)
  ...

  video.streams[streamid].cb_update = update_callback
  video.streams[streamid].outobj = outputobject

So what I'd basically would like to have is some video container object
that gives me access to the available streams and lets me handle them
seperately on demand. If I do not want ot make use of those, generic
video object methods should take care of dealing with play, pause,
etc. and update all streams accordingly.

This would mean, there are two types of classes, a 'VideoStream' class (or
whatever) that allows one to bind callbacks and objects for updated
buffers (so we can move the raw data around in the pipes or let them be
movied automatically). And a container class 'Video' that contains
multiple 'VideoStream' objects and keeps them in sync. on playback.

Regards
Marcus


pgpuGUVEYA68g.pgp
Description: PGP signature