Re: [pygame] State of the math branch
Hi,
sweet :) Nice work.
Feel free to merge it into the trunk. It'll be easier for other
people to try it out(binaries, and other things hooked up with trunk),
and you can also use the build bot to check for errors on other
platforms(like compilation/testing).
Sorry, I haven't had a chance to review it much. Hopefully will get a
chance to have a play, and a read of the code later this weekend some
time.
ps, here's the svn link for anyone else who would like to read over it
http://www.seul.org/viewcvs/viewcvs.cgi/branches/math_module/?root=PyGamesortby=date
The (s)lerp idea with the iterator seems a good one. I've been
thinking about doing something like that with line drawing
functions... that instead of drawing return the (x,y) coords of where
it would draw pixels. I wonder if it still might be useful to let
people supply a t argument, just because people are used to it...
However, they could just supply one step.
Having them share implementations is probably a good thing to reduce
the complexity of the code.
I guess there is going to be a 4 element quaternion? What about a
Vector4? Which matrix sizes are you thinking of doing? I guess 3x3,
3x4 and 4x4? Or just 4x4?
I noticed one commit log said there was trouble with the buffer
interface? Is this part still a trouble?
Functions like vector_elementwiseproxy_mul,
vector_elementwiseproxy_sub etc, could probably share a lot of code,
and then for the different part use a switch statement to do the
different function. Something like this:
static PyObject *
vector_elementwiseproxy_mul(PyObject *o1, PyObject *o2) {
return vector_elementwiseproxy_generic(o1, o2, VECT_OPS_MUL);
}
Where the vector_elementwiseproxy_generic function would have the
switch statement on the various flags passed in.
cheers,
On Thu, Nov 12, 2009 at 10:31 AM, d...@amberfisharts.com wrote:
Hi List,
I just wanted to give you a short summery of the development in the math
branch.
The goal of the math branch is the inclusion of several math related types
like vectors, matrices and quaternions.
Right now I consider the implementation of vectors in 2 and 3 dimensions as
feature complete.
What this means is that I can't think of more functionality that I want to
implement and all methods pass their unit tests.
I encourage everyone interested to take a look and make suggestions if they
find functionality missing.
The current version is not written for maximum performance.
For example Vector2 and Vector3 share many functions so no dimension specific
optimizations are implemented. So the current implementation should be
considered a baseline for future optimizations.
To gauge future improvements I intend to write a rudimentary performance
benchmark.
I don't consider the API to be set in stone. Especially concerning
mutability. Currently vectors are mutable.
If however it turns out that there is no significant performance hit in
making them immutable I tend to do so.
Obviously this will only happen once I have some performance results.
After that Matrices will be up next.
thanks for your time and suggestions.
//Lorenz
PS: I feel that I should briefly comment on the slerp() method.
I did not follow the default implementation that seems to be prevalent on
the Internet. There you repeatedly call the slerp method with a varying
parameter t. I felt this is unpythonic. In my implementation you pass the
number of steps you want into the method which then returns an iterator
yielding the interpolating vectors. Same applies to the lerp() method.
Also the algorithm for slerp() is a bit different as to support
interpolation to a vector of different length.
Re: [pygame] BUG: Windows - Pygame 1.9.1 with Python 2.6.4 doesn't install correctly
On Tue, Nov 10, 2009 at 8:01 PM, Thomas Ibbotson thomas.ibbot...@gmail.com wrote: René Dudfield wrote: one more question... are you on 32bit windows? Yes it is 32-bit windows. I guess another question would be, if it works for other packages? eg, does the numpy msi work for you ok? There only appears to be an amd64 numpy msi. I've had a look for other python packages that use msi's but haven't found any yet (I looked at wxpython, pyOpenGL, PIL and then gave up). FWIW the PIL installer works fine as an unpriveleged user. Tom ok, thanks. The PIL one uses the .exe installer still it seems. I think a bug should be reported to bugs.python.org. cheers,
Re: [pygame] State of the math branch
Hi René,
René Dudfield wrote:
Feel free to merge it into the trunk. It'll be easier for other
people to try it out(binaries, and other things hooked up with trunk),
and you can also use the build bot to check for errors on other
platforms(like compilation/testing).
Ok. I'll see if I can make it this weekend.
The (s)lerp idea with the iterator seems a good one. I've been
thinking about doing something like that with line drawing
functions... that instead of drawing return the (x,y) coords of where
it would draw pixels. I wonder if it still might be useful to let
people supply a t argument, just because people are used to it...
My hope is that the iterator is intuitive enough so nobody will miss the
t-version. also my version should perform better because it only
calculates a rotation-matrix once while otherwise you would have to
recalculate it on every call for the new t-value.
So for now I would stay with:
There should be one-- and preferably only one --obvious way to do it.
and wait and see if there is strong demand for a t-argument version.
However, they could just supply one step.
unfortunately I don't think it's that easy to convert from the iterator
interface to the t-arg interface. you would have to something like this:
def slerp_t(start_vec, end_vec, t):
idx, steps = t.as_integer_ratio() # new in python 2.6
return list(start_vec.slerp(end_vec, steps))[idx]
which is pretty ugly.
I guess there is going to be a 4 element quaternion? What about a
Vector4? Which matrix sizes are you thinking of doing? I guess 3x3,
3x4 and 4x4? Or just 4x4?
I was planing on implementing quaternions and only square matrices.
Is there a use for Vector4? Implementing it would be quite easy but
do we need it?
Also, what would be a use case for non-square matrices?
I noticed one commit log said there was trouble with the buffer
interface? Is this part still a trouble?
Yea. I didn't really understand which parts of the buffer protocol belong
to the 2.x protocol and which belong to 3.x and what should be supported.
In general I found this topic a bit confusing and the docs didn't help.
I have to look into that some other time when I've got the nerve for it.
Functions like vector_elementwiseproxy_mul,
vector_elementwiseproxy_sub etc, could probably share a lot of code,
and then for the different part use a switch statement to do the
different function. Something like this:
static PyObject *
vector_elementwiseproxy_mul(PyObject *o1, PyObject *o2) {
return vector_elementwiseproxy_generic(o1, o2, VECT_OPS_MUL);
}
Where the vector_elementwiseproxy_generic function would have the
switch statement on the various flags passed in.
I'll take a look at it.
thanks for the feedback. looking forward to more of it :)
yours
//Lorenz
On Thu, Nov 12, 2009 at 10:31 AM, d...@amberfisharts.com wrote:
Hi List,
I just wanted to give you a short summery of the development in the math branch.
The goal of the math branch is the inclusion of several math related types
like vectors, matrices and quaternions.
Right now I consider the implementation of vectors in 2 and 3 dimensions as
feature complete.
What this means is that I can't think of more functionality that I want to
implement and all methods pass their unit tests.
I encourage everyone interested to take a look and make suggestions if they
find functionality missing.
The current version is not written for maximum performance.
For example Vector2 and Vector3 share many functions so no dimension specific
optimizations are implemented. So the current implementation should be
considered a baseline for future optimizations.
To gauge future improvements I intend to write a rudimentary performance
benchmark.
I don't consider the API to be set in stone. Especially concerning
mutability. Currently vectors are mutable.
If however it turns out that there is no significant performance hit in
making them immutable I tend to do so.
Obviously this will only happen once I have some performance results.
After that Matrices will be up next.
thanks for your time and suggestions.
//Lorenz
PS: I feel that I should briefly comment on the slerp() method.
I did not follow the default implementation that seems to be prevalent on
the Internet. There you repeatedly call the slerp method with a varying
parameter t. I felt this is unpythonic. In my implementation you pass the
number of steps you want into the method which then returns an iterator
yielding the interpolating vectors. Same applies to the lerp() method.
Also the algorithm for slerp() is a bit different as to support
interpolation to a vector of different length.
Re: [pygame] Need names and nationalities for AI playes in new sport-game
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Quildreen Motta / Brazil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK/xShWXawpW3FlQoRAtaRAKDVQREcQQcP/QGNs2ULbkYuynZUxgCeM60S 1vXJGXxdtA1WYH+yiF0Hlo4= =5gvi -END PGP SIGNATURE-
Re: [pygame] State of the math branch
I think there are many cases where one might want, say, the halfway
rotated quat between two, or due to varying framerates with things
like network code, (or even just for animation purposes) you might
want to have varying rates, or skip to a different t value. I don't
see how an iterator would be useful in these cases. You would have to
do a 2 step rotation once to get the midway rotation, iterating an
iterator once is pretty unintuitive; and for varying speeds during a
rotation, you would need to recalculate a new iterator every frame.
I haven't looked at it, but intuitively it seems to be trying to wedge
one concept into a very different one. If there were only one
implementation, I would much prefer the t version.
On Sat, Nov 14, 2009 at 11:06 AM, Lorenz Quack d...@amberfisharts.com wrote:
Hi René,
René Dudfield wrote:
Feel free to merge it into the trunk. It'll be easier for other
people to try it out(binaries, and other things hooked up with trunk),
and you can also use the build bot to check for errors on other
platforms(like compilation/testing).
Ok. I'll see if I can make it this weekend.
The (s)lerp idea with the iterator seems a good one. I've been
thinking about doing something like that with line drawing
functions... that instead of drawing return the (x,y) coords of where
it would draw pixels. I wonder if it still might be useful to let
people supply a t argument, just because people are used to it...
My hope is that the iterator is intuitive enough so nobody will miss the
t-version. also my version should perform better because it only
calculates a rotation-matrix once while otherwise you would have to
recalculate it on every call for the new t-value.
So for now I would stay with:
There should be one-- and preferably only one --obvious way to do it.
and wait and see if there is strong demand for a t-argument version.
However, they could just supply one step.
unfortunately I don't think it's that easy to convert from the iterator
interface to the t-arg interface. you would have to something like this:
def slerp_t(start_vec, end_vec, t):
idx, steps = t.as_integer_ratio() # new in python 2.6
return list(start_vec.slerp(end_vec, steps))[idx]
which is pretty ugly.
I guess there is going to be a 4 element quaternion? What about a
Vector4? Which matrix sizes are you thinking of doing? I guess 3x3,
3x4 and 4x4? Or just 4x4?
I was planing on implementing quaternions and only square matrices.
Is there a use for Vector4? Implementing it would be quite easy but
do we need it?
Also, what would be a use case for non-square matrices?
I noticed one commit log said there was trouble with the buffer
interface? Is this part still a trouble?
Yea. I didn't really understand which parts of the buffer protocol belong
to the 2.x protocol and which belong to 3.x and what should be supported.
In general I found this topic a bit confusing and the docs didn't help.
I have to look into that some other time when I've got the nerve for it.
Functions like vector_elementwiseproxy_mul,
vector_elementwiseproxy_sub etc, could probably share a lot of code,
and then for the different part use a switch statement to do the
different function. Something like this:
static PyObject *
vector_elementwiseproxy_mul(PyObject *o1, PyObject *o2) {
return vector_elementwiseproxy_generic(o1, o2, VECT_OPS_MUL);
}
Where the vector_elementwiseproxy_generic function would have the
switch statement on the various flags passed in.
I'll take a look at it.
thanks for the feedback. looking forward to more of it :)
yours
//Lorenz
On Thu, Nov 12, 2009 at 10:31 AM, d...@amberfisharts.com wrote:
Hi List,
I just wanted to give you a short summery of the development in the math
branch.
The goal of the math branch is the inclusion of several math related
types
like vectors, matrices and quaternions.
Right now I consider the implementation of vectors in 2 and 3 dimensions
as
feature complete.
What this means is that I can't think of more functionality that I want
to
implement and all methods pass their unit tests.
I encourage everyone interested to take a look and make suggestions if
they
find functionality missing.
The current version is not written for maximum performance.
For example Vector2 and Vector3 share many functions so no dimension
specific
optimizations are implemented. So the current implementation should be
considered a baseline for future optimizations.
To gauge future improvements I intend to write a rudimentary performance
benchmark.
I don't consider the API to be set in stone. Especially concerning
mutability. Currently vectors are mutable.
If however it turns out that there is no significant performance hit in
making them immutable I tend to do so.
Obviously this will only happen once I have some performance results.
After that Matrices will be up next.
thanks for your time and suggestions.
//Lorenz
PS:
Re: [pygame] Need names and nationalities for AI playes in new sport-game
Jason Marshall, Iowa, USA 2009/11/12 John Eriksson j...@arainyday.se Hi fellow pygame developers! I'm developing a sports game. It's a fictive sport played one-on-one, on ice against another human player or against a rather advanced AI. As part of the game it is possible to create a career in the World Series against 40 (or so) AI controlled players. I started to search the net to find inspiration for names and nationalities to the AI-players. But then I thought it would be much nicer to use the names and nationalities of pygame developers instead of just using fictive names. All AI-players will have different skill levels wich is randomly set in the begining of a new World Series career. In one career your named character will be the best in the world, and in another it might be a rookie in Division 4. The game will be released as Freeware for both Linux and Windows. The source code will (as allways for my projects) be available once the game is done. If you wan't your name to apear as a AI-player in the game, please send me your name (first + last) and your nationality. Best Regards /John Eriksson http://arainyday.se
Re: [pygame] Need names and nationalities for AI playes in new sport-game
Hi John, Curling, eh. Well, I guess you won't want too many Canadians. I mean, you do want the player to have some chance of winning. Lenard John Eriksson wrote: Hello every one! What a tremendous response! :-D I realized I was a little vague in my description of the game. This was partly because I didn't want to spoile the release of the game. But since you all will be a part of the game it's only fair that you know what you lend your name to. The game is called Power Play (right know anyway. It's changed name several times over the last week). It's somewhat inspierd by curling (Sorry Toni, no Hattrick killer. I really loved that game too!). It will be possible to play a singel game, 2-player game or to create a career in the Power Play World Series (this is where your name will occure).
Re: [pygame] Spam problem with joystick module
Hi rouiller, Somehow the joystick extension module is being compiled with the debug switch set (DEBUG macro defined). Try getting the most recent build from SVN at http://thorbrian.com/pygame/builds.php. I think this problem should be fixed. Lenard Lindstrom rouiller olivier wrote: Thanks for the file, they work well but I still have the spam. I guess I will have to deal with it til next release and hope the game will still be playable. 2009/11/13 Thiago Chaves shundr...@gmail.com mailto:shundr...@gmail.com Rouiller, check if these work for you. Teste1.py controls a circle (and a line, if you have 2 or more directional pads) on the window. Teste2.py outputs button numbers and directional axes information (it's a bit spammy when you're dealing with analog directional buttons, it's just because there's so many different values the axes can take in that case). -Thiago On Fri, Nov 13, 2009 at 2:15 AM, rouiller olivier o.rouil...@gmail.com mailto:o.rouil...@gmail.com wrote: ok thank's let's try to build it, should be a good exercise after all. 2009/11/13 Lorenz Quack d...@amberfisharts.com mailto:d...@amberfisharts.com Hi, rouiller olivier wrote: The calls to get_axis and get_button cause these outputs... Maybee there is another way of getting the values?.. Not sure if there is another way. Note that this is already fixed in svn trunk. So I guess you can either try to build pygame from source from the svn version or wait for the next release. regards //Lorenz -- Rouiller Olivier 06 79 66 89 63 Résidence Léonard de Vinci App. A008 59650 Villeneuve d'Ascq -- Rouiller Olivier 06 79 66 89 63 Résidence Léonard de Vinci App. A008 59650 Villeneuve d'Ascq
